Journal Abiword et ODF (troll inside)

Posté par (page perso) .
Tags : aucun
0
23
mai
2008
Une interview intéressante de l'équipe de développement d'Abiword (en anglais), dans le Red Hat Magazine au début du mois. On y trouve entre autres le savoureux passage suivant :

Any comments on ODF as the default format? There was a 2004 discussion, but has anything changed after that?

No. We will not make it our default file format. Our internal model does not map 100% to ODT and visa versa (basically because ODT is nothing more than a dump of OpenOffice.org’s internal format).


[http://www.redhatmagazine.com/2008/05/08/abiword-team-interv(...)]

Soit en français :
Des commentaires sur le choix d'ODF en tant que format par défaut [pour Abiword] ? Il y a eu une discussion en 2004 à ce sujet, mais les choses ont-elles changé depuis ?

Non. Nous n'en ferons notre format par défaut. Notre modèle interne ne se traduit pas à 100% dans ODT et vice-versa (fondamentalement parce qu'ODT n'est rien d'autre qu'une transcription du format interne d'OpenOffice.org).


Suivent quelques exemples de trucs "moches" dans ODT. C'est vendredi, tout est permis !

(Et puis ça nous changera des trolls sur OOXML qui deviennent lassant, je trouve).
  • # Payé

    Posté par (page perso) . Évalué à  3 .

    Encore une preuve que l'équipe d'Abiword ne se laisse pas corrompre par les équipes d'open office qui veulent imposer leurs formats.
    Honte à eux.
    Dès que je serais chez moi, ma première commande sera un
    urpme `rpm -qa |grep -i openoffice`
    • [^] # Re: Payé

      Posté par . Évalué à  10 .

      D'un autre côté, ils ont été invité à participer à l'élaboration de la spec ODF, ils ont refusé parce que ça ne les intéressait pas trop et parce qu'ils pensaient être "trop petit", et maintenant, ils semblent regretter un peu : All that said, if we had been on the committe we might have prevented a couple of silly things being part of the spec.

      Regrets sur quoi l'enfer se fonde...
      • [^] # Re: Payé

        Posté par (page perso) . Évalué à  6 .

        pour arbitrer, on attend donc la réaction d'Albert , roi du troll des format de fichiers bureautique
    • [^] # Re: Payé

      Posté par . Évalué à  1 .

      urpme `rpm -qa |grep -i openoffice`

      Soit c'est ironique et c'est moyennement drôle, soit ça ne l'est pas et c'est complètement stupide ;)


      Indice : Les devs d'OOo pourront encore dormir sur leur deux oreilles mêmes s'ils apprennent que ΠαζαΠατα fait la tête et décide de boycotter dans son coin.


      Allez c'est vendredi, soyons optimiste, on va considérer que c'était du second degré juste pour troller ;)
    • [^] # Re: Payé

      Posté par (page perso) . Évalué à  4 .

      urpme -a openoffice

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Re: Payé

        Posté par (page perso) . Évalué à  1 .

        ça desinstalle pas les libs :-)
        Et bien sûr que j'étais ironique...
        J'imiitais certains lors du "combat" ooxml vs rien
  • # ODT, transcription d'OpenOffice.org ?

    Posté par . Évalué à  10 .

    Fichtre...
    C'est vraiment surprenant, je bouffe de l'OpenDocument presque tous les jours pour KOffice, et je vois pas ce qui le lie à OpenOffice.org.
    Ne prendraient-ils pas le problème dans le mauvais sens ? Le problème de l'OpenDocument pour Abiword ne serait-il pas plutôt qu'il ne soit pas une transcription du format interne d'Abiword ?
    • [^] # Re: ODT, transcription d'OpenOffice.org ?

      Posté par . Évalué à  8 .

      D'ailleurs KOffice n'a pas été le premier a implémenter l'ODT dans une version stable de sa suite devant OpenOffice ?

      Quand a la soit disant impossibilité d'implémenter ODT dans autre-chose Qu'OpenOffice Microsoft disait la même chose, résultat l'ODT va arriver dans Microsoft Office avant l'OXML.
      • [^] # Re: ODT, transcription d'OpenOffice.org ?

        Posté par . Évalué à  7 .

        Faut pas non plus oublier que le développement de la norme se fait en prenant en compte les remarques des développeurs d'OpenOffice, mais aussi de KOffice (et aussi d'autres, mais j'ai la flemme de chercher)
        Y'a pas longtemps, on a pu envoyer nos dernières remarques et commentaires pour la production de la version 1.2 de la norme ODF. Et tout au long de la production de cette nouvelle version, nous avons pu participer, signaler des trucs qui nous gênent actuellement...
  • # Pragmatique

    Posté par . Évalué à  5 .

    Bah faut les comprendre, je trouve que c'est normal de leur part : ils font comme les gens de Gnumeric, qui trouvent le format OOXML meilleur et surtout assez proche de l'ancien format binaire pour ne pas avoir à tout réécrire.
    C'est assez pragmatique de leur part, finalement.

    Par contre, il trolle quand il affirme que c'est trop lié à OOo, alors qu'OOo lui-même n'a pas implémenté toute la norme... Et surtout ils ont refusé d'y participer alors qu'ils étaient invités à travailler dessus avant

    Maintenant, en l'état actuel des choses, leur équipe est trop petite pour tout faire, mais il suffirait que quelqu'un d'autre s'y colle pour développer le format ODT chez eux, et ça leur fera peut-être changer d'avis.
    C'est l'avantage du libre, pourquoi ne pas en tirer parti ?

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Pragmatique

      Posté par (page perso) . Évalué à  7 .

      Attention, le format ODT est supporté par Abiword. Il n'est simplement pas le format par défaut.
  • # C'est un des gros point noir de abiword

    Posté par . Évalué à  8 .

    C'est dommage, abiword est bien mieux intégré aux environnements GTK que OpenOffice et bien plus dans l'esprit simple de ceux-ci (le deuxième point noir étant sa gestion des styles [1]).

    Ensuite, vient le problème des format comme l'ODF (ont va se baser sur le plus simple, l'ODT).
    Faire que toutes les suites bureautiques l'utilisent par défaut, ça ne me semble pas insurmontable. l'ODF permet de faire plein de chose, il peut subvenir à je pense presque tout les besoins.

    Après, il y a de choses :
    — Utiliser le format ODT pour structurer les fichiers
    — Interpréter l'ensemble de la norme ODT

    Et sur ce deuxième point, cela devient beaucoup plus dur et c'est là que cela doit coincer au niveau d'abiword (je dis ça avec un œil externe, je ne sais rien du tout du développement d'abiword).
    Abiword possède, et ceci volontairement, beaucoup moins de fonctions que OpenOffice Writer. L'un est apparut avec comme but d'avoir une sorte de clone de Word, et l'autre d'avoir un éditeur de texte simple mais performant.
    Le problème est là : comment interprété tout ce qui peut être présent dans un document créé avec OpenOffice ou Kword dans Abiword ?
    et surtout comment faire en sorte que de retour chez l'expéditeur, ces informations ne soient pas altérée ?

    Quand on voit le mal qu'il y a eu pour que tout les navigateurs (enfin presque tous…) affichent correctement des pages en XHTML (ont va prendre le format le plus simple), on voit de la difficulté que ça va être avec l'ODF.

    Un exemple : en effet, quand je travaille sous OpenOffice, je l'ouvre, je l'envoie à quelque d'autre, qui va l'ouvrir aussi avec OpenOffice, pas de problème (ou peu si on a les même polices).
    Sur Kword même chose, on rédige, on envoie le document ODT à un autre qui à Kword et quand il l'ouvre, c'est pareil.

    Mais les échanges OpenOffice / Kword ? et bien c'est tout de suite moins top (ce n'est peut-être que provisoire, je n'en sait rien). Alors que ces deux logiciels sont du même niveau (Kword à pour but d'être aussi fonctionnel que OpenOffice).
    Alors un logiciel comme abiword qui se veut bien plus léger…

    Alors quelle solution ? Une autre norme plus simplifier ?
    Une protection dans le format pour que les logiciels plus simple puissent facilement éditer les documents même si elle ne gère pas tout ?

    Voilà, dire que l'on va avoir un format unique est facile, je pense que la mise en place va être beaucoup plus dur, à moins d'avoir des suites bureautiques qui se ressemblent toutes.




    [1] http://linuxfr.org/comments/919037.html#919037
    • [^] # Re: C'est un des gros point noir de abiword

      Posté par (page perso) . Évalué à  5 .

      Je pense que le but d'un format unique est d'être interopérable, pas d'obtenir exactement la même chose à l'impression : pour cela, il y a PDF. C'est le seul format qui permette ça, grâce à l'intégration des polices dans le document.

      Mon but avec ODF est de récupérer l'essentiel (l'information) avec un format standard. Même un document traité exclusivement sous OpenOffice sous des plateformes différentes a un rendu différent...

      ⚓ À g'Auch TOUTE! http://agauch.fr

      • [^] # Re: C'est un des gros point noir de abiword

        Posté par . Évalué à  2 .

        Mon but avec ODF est de récupérer l'essentiel (l'information) avec un format standard.

        oui bonne remarque. Parce que c'est vrai que je dois trop en attendre à ce niveau, à chaque fois que j'essaye d'ouvrir un odt généré par ooo dans koffice, je suis désolé par le résultat. En tout cas c'est bien que koffice propose odf par défaut, et un peu dommage qu'abiword ne fasse pas de même, car cela risque d'embrouiller les utilisateurs novices.

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: C'est un des gros point noir de abiword

      Posté par . Évalué à  -2 .

      Ce type de commentaire m'énerve.

      Il y a des bugs dans OOo, KWord, etc.
      Ben oui.
      Mais en quoi ça demande un nouveau format (même simplifié) ?

      Les pages html ne s'affichent pas à l'identique sur IE, FF, Opera, etc.
      On ne demande pas alors un nouveau html, mais simplement que les navigateurs respectent le standard. Ce qui est un boulot énorme.

      Es-ce que le format ODF n'est pas assez bien spécifié ?
      Dans ce cas il faut le corriger, pas en créer un autre.
      En créer un autre c'est la "bombe atomique", c'est la dernière chose à faire.
      • [^] # Re: C'est un des gros point noir de abiword

        Posté par (page perso) . Évalué à  1 .

        La différence avec l'html, c'est que tu corriges ton bug dans ton navigateur, ça marche direct. Mais quand tu produits des documents ODF avec une appli boguée, t'es obligé de garder l'historique des bugs pour pouvoir les ouvrir correctement. C'est encore plus dur.
      • [^] # Re: C'est un des gros point noir de abiword

        Posté par . Évalué à  7 .

        Il n'y a pas de quoi s'énervé, je n'ai pas dit « il faut faire un nouveau format » je pose juste la question de savoir si l'ODF est utilisable pour un petit projet.
        J'ai pas critiqué le format ODF, j'en serais incapable, je ne sais pas comment il est structuré. Les questions que je me pose ont dont peut-être déjà été prise en compte.

        Ensuite, bonne chose ou pas, je n'en sais rien, c'est pour ça que je demande.

        Qu'est-ce qui est le plus simple ? avoir un deuxième standard, plus proche dans les fonctionnalité du html ? d'ailleurs, pourquoi ne pas utilisé le format html pour des projet comme abiword ? il existe je crois tout ce qui faut de dans, même pour la mise en page.

        Donc autant multiplier les formats n'est pas bon quand ils font la même chose, autant il faut des fois aussi si demander si un format est bon dans tout les cas.

        Implémenter une spécification très grosse pour un petit logiciel, c'est comme demandé de lire toutes les spécifications de tout les modules en python pour coder une calculatrice.

        Je précise que je n'ai pas dit que abiword était l'équivalent de notepad, ni que ODF n'est une grosse bouse trop lourde, juste que les deux ne visent peut-être tout simplement pas la même chose.

        Voilà, ça ne sert à rien de s'énerver si on ne dit pas que l'ODF c'est la merveille des merveille, surtout que j'ai en rien critiqué le format, juste demandé si il est adapté à tout les cas.

        Avoir un deuxième format plus léger de traitement de texte qui serait lisible et éditable sur les autres suites bureautiques qui pourraient même éventuellement brider leur fonction (griser dans les menus tout ce qui ne sera pas pris en compte par le format) ne me semble pas une « bombe atomique » qui va tout casser.
        • [^] # Re: C'est un des gros point noir de abiword

          Posté par (page perso) . Évalué à  2 .

          Pour ce qui est du html, je ne crois pas qu'il soit adapté à la bureautique, ne serait-ce que par l'absence de notion de page (pour autant que je sache en tout cas).
          • [^] # Re: C'est un des gros point noir de abiword

            Posté par . Évalué à  6 .

            Justement, les css persmettent pas mal de contrôle dessus, comme les marges, les saut de pages etc.

            Voici plus de détail :
            http://fr.selfhtml.org/css/proprietes/printlayouts.htm
            • [^] # Re: C'est un des gros point noir de abiword

              Posté par . Évalué à  2 .

              Mouais...
              Entre ce que permet (sur le papier) de faire le CSS et ce qu'il permet (concrètement) de faire, il y a un sacré gouffre...
              Et je ne dis pas que tout ceci est en très grande partie dû à un certain navigateur Web aux PdM majoritaires mais au développement oublié pendant 5-6 ans et qui a ralenti l'évolution du Web au point de presque le mettre au point mort !
              Non, jamais je n'oserais lancer un tel troll, il manquerait plus qu'on soit vendredi...


              Ah, on me dit dans mon oreillette que "oui on est vendredi, mais que non ça n'a rien d'un troll". Soit.
              • [^] # Re: C'est un des gros point noir de abiword

                Posté par . Évalué à  3 .

                Ce que permet de faire actuellement les navigateurs quand à la gestion des caractéristiques des css (et il me semble que ce n'est pas si mauvais) est ici sans importance.
                On ne va pas faire imprimer un document conçu avec abiword par exemple sous un navigateur (bien que cela devrait être possible).
                Mais si « sur le papier », le html combiné au css le permet, rien n'empêche un éditeur de texte de le traîter correctement vu que c'est lui qui va gérer l'impression.
                De la même façon, il n'est pas utile pour le traitement de texte de gêrer tout ce qui est dans les spécifications du css et du html, mais juste ce qui lui sert. un attribut position : fixed sur un document texte n'a que peu d'intérêt en effet.

                Donc à moins de me dire ce qu'il manque vraiment au format html + css pour faire un traitement de texte comme abiword, je pense que ce fomat reste adapté. Et le fait de savoir si les navigateurs sont au point pour ça n'a aucune importance, c'est juste le format qui compte.
                • [^] # Re: C'est un des gros point noir de abiword

                  Posté par . Évalué à  2 .

                  {Au temps|Autant|OTAN} pour moi, j'étais resté dans l'optique "du CSS pour de la mise en page HTML", et non pas comme cela était évoqué plus haut, pour de la mise en page dans une suite bureautique.
                  Dans ce cas, c'est en effet différent : on n'a pas à tenir compte des particularités des différents moteurs de rendu HTML.

                  Et d'ailleurs, Kopete et la librairie Qt ont déjà recours au CSS pour définir le rendu graphique de certains éléments : pour Kopete, c'est pour le rendu de la zone de discussion, pour Qt c'est au moins pour le rendu de l'interface graphique, mais peut-être aussi pour le rendu du contenu de certaines zones de texte.
  • # Souvenez-vous !

    Posté par . Évalué à  3 .

    Au début de ce siècle, il était de bon ton de comparer les performance d'abiword, Staroffice et koffice sans compter d'autres logiciciels propriétaires ou non comme Applix ou Siag etc....

    A l'époque si abiword manquait encore de beaucoup de fonctionalité (bon nombre de sous-menus vous retournez le dialogue " pas encore implémenté..."
    sa fonction d'import-export de documents au format .doc (MS-Word pour ceux qui ne le saurait pas) était considéré comme la "meilleure" du monde libre....

    Visiblement les gens d'abisource se sont endormis et n'ont pas su prendre le virage d'ODT. Ce qui les rend de plus en plus exotiques....
    • [^] # Re: Souvenez-vous !

      Posté par (page perso) . Évalué à  5 .

      Visiblement les gens d'abisource se sont endormis et n'ont pas su prendre le virage d'ODT. Ce qui les rend de plus en plus exotiques....

      Certes. Présenté comme ça, ça sonne comme une faute.
      Et si tout simplement les gens d'Abiword avaient décidé de suivre une voie différente, de cesser de passer un temps considérable pour obtenir une compatibilité avec MS Word, ou passer du temps pour obtenir une bonne compatibilité avec ODT?

      On peut leur reprocher de ne pas avoir choisi cette voie, mais leur reprocher de s'être endormis, ce serait négliger toutes les améliorations qui ont été apportées à Abiword, tel que le travail collaboratif, par exemple!

      Ils se sont concentrés sur d'autres fonctionalités! On ne peut pas non plus leur reprocher de ne pas s'être intéressés à ODT autant que KOffice, comme il a été dit plus haut, OOo et KOffice se veulent être les plus "complets", Abiword cherche à rester simple et léger.
      Je ne suis pas expert en formats ni en fonctionnement de traitements de textes, mais si avoir une bonne compatibilité ODT et .doc signifie alourdir d'autant Abiword, on peut comprendre leur manque de motivation.
      • [^] # Re: Souvenez-vous !

        Posté par . Évalué à  2 .

        Je ne suis pas expert en formats ni en fonctionnement de traitements de textes, mais si avoir une bonne compatibilité ODT et .doc signifie alourdir d'autant Abiword, on peut comprendre leur manque de motivation.

        C'est donc se reduire a une toute petite niche de passionne du logiciel chose qui a decrut de facon continu depuis des annees vu le manque de nouvelles versions.
        • [^] # Re: Souvenez-vous !

          Posté par (page perso) . Évalué à  3 .

          Possible, je n'en suis pas sûr.
          Tous les projets libres ne visent pas "un marché" aussi large que possible.

          Il n'y a pas si longtemps, et encore un peu aujourd'hui, développer une application linux destinée aux particuliers plutôt qu'aux professionnels, c'est également "se réduire à une toute petite niche de passionnéS du logiciel".
          Et pourtant qui se plaint de telles initiatives?
  • # norme et implémentation

    Posté par (page perso) . Évalué à  4 .

    J'interviens ici à titre personnel, et mon opinion peut différer de celles des autres membres de Gnome Office. Le principal souci avec tous les formats, ODF ou ceux de M$ est que la norme est une chose, et l'implémentation qui en est faite en est une autre. Pourquoi investir plein d'énergie pour changer de format si on va devoir mettre en place une implémentation du format qui ne serait pas forcément compatible avec celle mise en place par les autres projets, propriétaires ou non.

    Pour me limiter à ce que je connais bien, les graphiques utilisés dans Gnome Office possèdent de nombreuses fonctionnalités qui nécessiteraient un nouveau vocabulaire par rapport à la norme OpenDocument. En résumé, on pourrait faire des documents conformes à la normes, mais peu compatibles avec les autres projets.

    Notre choix est différent. Nous gardons nos formats simples et nous traitons tous les autres formats comme des formats externes dans lesquels nous essayons d'importer et d'exporter tout ce qui est possible.

    Maintenant, l'avenir sera peut-être différent. Si quelqu'un se porte volontaire pour développer une implémentation d'ODF pour Gnome Office, pourquoi pas ? Il y aura sûrement des résistances, mais si ça fonctionne...
    • [^] # Re: norme et implémentation

      Posté par . Évalué à  2 .

      Je vais poser une question bete mais pourquoi ne pas avoir ou meme mieux participer a la conception de ODF dans ce cas la?
      • [^] # Re: norme et implémentation

        Posté par (page perso) . Évalué à  2 .

        Personnellement, je ne crois pas qu'un format de fichier universel soit tout simplement faisable et, de plus, je n'ai ni les compétences ni le temps pour participer à ce genre de choses.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.