Journal Peut-on virer OOXML d'OOo ?

Posté par  .
Étiquettes : aucune
0
5
avr.
2008
OOo 3.0 devrait supporter OOXML, a-t-il été anoncé.

Je trouve que c'est une mauvaise idée. Très.

Est-il possible d'écrire un plugin OOo qui supprime les formats MS d'OOo? Ou une macro ?

J'imagine très bien un ODP viral plein de pingouins et de pingouinnes nus et de blagues moyennement rigolotes, incorporant une macro virant ces formats.

(Après l'OOXML il va y avoir le XPS à l'ISO pour virer le déjà ISOïfié PDF).
  • # pas forcement une mauvaise idee

    Posté par  . Évalué à 0.

    Si c'est uniquement un filtre import! Il ne faut surtout pas de filtre d'export car la ce serait se tirer une balle dans le pied.

    En gros tu ouvres, tu bosses dessus et tu renvois en ODF (avec un lien vers ta suite prefere supportant ODF et il y a en pas mal!)
    • [^] # Re: pas forcement une mauvaise idee

      Posté par  . Évalué à 1.

      L'idéal est que la suite office de MS produise du ODF (c'est déjà le cas je pense via un plugin). L'interopérabilité doit se faire via le format ODF, pas par le format OOXML (qui n'est pas interopérable).
    • [^] # Re: pas forcement une mauvaise idee

      Posté par  . Évalué à 10.

      >Si c'est uniquement un filtre import! Il ne faut surtout pas de filtre d'export

      C'est moi, ou ça devient n'importe quoi ici ?
      Tu veux priver les utilisateurs d'une fonction qui peut leur être utile ? Tu peux pousser le raisonnement encore plus loin : y'a qu'à ne pas diffuser le source comme ça les utilisateurs ne pourront pas ajouter de filtre d'export. Ça nous permettra de mieux contrôler les utilisateurs ( par contre la liberté de choix de l'utilisateur, c'est pas notre problème ).
      • [^] # Re: pas forcement une mauvaise idee

        Posté par  . Évalué à 2.

        L'import est malheureusement necesaire et va demander enormement de boulot vu le bousin a installer. Si en plus il faut un filtre d'export cela va etre pire.

        Combien d'annees a t'il fallu pour avoir un support a peu pres correct du format binaire? Combien d'annee il va falloir pour trouver les trucs non documentes et/ou decrypter les blobs binaires qui vont etre present dans les fichiers microsoft oxml? Combien de versions differentes il va falloir prendre en compte (aujourd'hui il y en a deja 2 au minimum version microsoft office 12 et la "norme")? De l'autre cote il y a ODF 1.2 qui arrive et qui n'est pas encore totalement implemente dans OOo (ni dans aucune autre suite). Je trouve qu'il est passablement dommage de passer du temps a implementer un bousin tel que microsoft oxml.

        J'ose esperer que koffice2 sortent bientot et que les promesses entrevues soient respecte. Vu que koffice a clairement dit qu'ils n'ont pas le "manpower" pour faire le filtre pour le bousin, si cette suite plait cela va peut etre rendre ODF indispensable.
        • [^] # Re: pas forcement une mauvaise idee

          Posté par  . Évalué à 2.

          > Je trouve qu'il est passablement dommage de passer du temps a implementer un bousin tel que microsoft oxml.

          Oui et non.
          Oui, car on ne veut pas d'un format pseudo standard pseudo ouvert.
          Et non car il y a des utilisations de MS-OOXML.
          Qu'ils aient tord d'utiliser MS-OOXML, qu'il le fasse ou non malgré eux, ce sont des utilisateurs.

          Et notes bien que ceci n'a rien à voir avec la ratification ou non de MS-OOXML. C'est seulement la prise en compte du "marché".
  • # et non ...

    Posté par  (site web personnel) . Évalué à 10.

    Car le libre c'est aussi l'ouverture d'esprit,

    et quand bien même OO-XML ne restera PAS une norme ISO vu les irrégularités de procédure et la mauvaise qualité intrinsèque du format (on peut toujours rêver ...), il restera LE format de Microsoft pour sa suite bureautique.

    J'en déduis qu'il FAUT que Openoffice le gère en import ET en export. C'est un de ses buts : permette à chacun d'interopérer avec tous les logiciels de bureautique possible (works, clarisworks, word 6.0, word 2007 etc.)

    Je suis toujours étonné de la vitesse à laquelle les libristes peuvent devenir intolérants ;)

    Bises les pingouins,

    B.
  • # Trop tard...

    Posté par  . Évalué à 2.

    Comme pour les OGM, il ne fallait pas grand chose pour éviter la contamination - un peu de bon sens -, mais maintenant que nos "instances" v/ont légalisé la chose, c'est pas quelques arracheurs de formats OOXML qui vont empêcher les abeilles de butiner...
  • # Moi je suis pour

    Posté par  . Évalué à 5.

    Vraiment c'est une super idee.

    Quel meilleur moyen pour couler OO que l'empecher d'ouvrir un format qui se repand rapidement ? (Office 2007 se vend comme des petits pains en ce moment).

    Des fois je me dit que les meilleurs atouts de MS sont sur linuxfr, pas a Redmond...
    • [^] # Re: Moi je suis pour

      Posté par  (site web personnel) . Évalué à 3.

      Quel meilleur moyen pour couler OO que l'empecher d'ouvrir un format qui se repand rapidement ? (Office 2007 se vend comme des petits pains en ce moment).
      Je croyais qu'on parlait du OOXML version "iso". Ceci dit, je pense que son support dans OOo est hélas indispensable.

      Sinon on ne dit pas "des fois" mais "parfois".
      • [^] # Re: Moi je suis pour

        Posté par  . Évalué à 1.

        MS a deja annonce qu'Office 2007 allait etre mis en conformite avec le format ISO (ca sera problablement le prochain service pack), et les gens vont forcement migrer sur le service pack a un certain point, resultat a ce moment la, Office 2007 sortira le format ISO.
        • [^] # Re: Moi je suis pour

          Posté par  . Évalué à 7.

          Comment on va faire pour différencer un format vieux MS-Office 2007 et un format MS-Office 2007 vaguement ISO ?

          On sait déjà...
          <application>Microsoft Office Word</application>
          <appversion>12.0000</appversion>


          Le 12.0000 va devenir 12.1000.
          Et comme il y a plein de "implementation-defined" (not really) :
          http://www.robweir.com/blog/2008/03/implementation-defined-n(...)
          tout le monde devra se "conformer" à MS-Office 2007 et non à l'ISO. Bref, on retrouve la même situation qu'avec les vieux formats binaires...

          Malheur à ODF qui va mettre "<application>OpenOffice.org</application>.
    • [^] # Re: Moi je suis pour

      Posté par  . Évalué à 3.

      Quel meilleur moyen pour couler OO que l'empecher d'ouvrir un format qui se repand rapidement ?
      Clair : la meilleure façon de couler MS est que OOo supporte OOXML : plus besoin de payer un bloatware infâme pour créer les formats microsoft... et dans la foulée, les gens découvrirons une partie du monde libre : les formats, les logiciels, l'idéologie ...
  • # Re:

    Posté par  . Évalué à 4.

    > OOo 3.0 devrait supporter OOXML, a-t-il été anoncé.

    Comme il importe les fichiers .doc. Rien de plus.
    OOo support ODF. Lorsqu'il y a une nouvelle fonctionnalité dans ODF, OOo l'a supporte (ou va la supporter). Ce n'est pas le cas pour MS-OOXML.
    Dans MS-OOXML on peut mettre des annotations dans les formules. Ben OOo ne va pas le supporter (sachant qu'en plus c'est sans intérêt).

    Ce qui peut être "mappé" vers ODF sera fait. Et rien de plus (sauf cas très très spécifique).

    Voyons ceci :
    http://www.robweir.com/blog/2008/03/disharmony-of-ooxml.html
    Text Color
    OOXML Text <w:color w:val="FF0000"/>
    OOXML Sheet <color rgb="FFFF0000"/>
    OOXML Presentation <a:srgbClr val="FF0000"/>
    ODF Text         <style:text-properties fo:color="#FF0000"/>
    ODF Sheet        <style:text-properties fo:color="#FF0000"/>
    ODF Presentation <style:text-properties fo:color="#FF0000"/>


    Dans OOo la couleur est toujours représentée de la même façon puisque c'est ainsi que c'est fait dans ODF. OOo ne va pas importer les merdes de MS-OOXML, il va les mapper vers le clean ODF.

    Évidemment on peut dire que OOo 3.0 sera pollué par MS-OOXML. Mais il le sera que dans un coin. Dans le filtre d'import/export et pas ailleurs.

    Sinon OOo est un projet libre, propose un patch pour "./configure --without-ms-ooxml".

    OOo sera toujours plus adapté pour ODF (puisqu'il est conçu pour implémenter ODF) qu'il sera adapté pour MS-OOXML. Et sans rappeler les merdes de MS-OOXML, il faudra être con pour utilise MS-OOXML avec OOo. Sauf si on veut lire un fichier MS-OOXML...
    • [^] # Re: Re:

      Posté par  . Évalué à 3.

      > OOo ne va pas importer les merdes de MS-OOXML, il va les mapper vers le clean ODF.

      Et donc OOo ne va pas *implémenter* tout ce qui est juridiquement risqué dans MS-OOXML.
    • [^] # Re: Re:

      Posté par  . Évalué à 1.

      ca doit bien faire 5 ou 6 fois que l'on fait reference a ce probleme dans microsoft oxml et c'est rigolo comme il est silencieux sur le sujet le chevalier microsftien :)

      Je voudrais bien voir quel argument foireux il va pouvoir trouver pour "justifier" des incoherences de ce style.
      • [^] # Re: Re:

        Posté par  . Évalué à 2.

        C'est clair qu'avec 4 ou 5 journaux/news ca devient dur de suivre hein, la reponse est la : http://www.linuxfr.org/comments/920072.html#920072
        • [^] # Re: Re:

          Posté par  . Évalué à 0.

          > la reponse est la : http://www.linuxfr.org/comments/920072.html#920072

          La réponse n'y est pas.
          • [^] # Re: Re:

            Posté par  . Évalué à 2.

            si, il a dit (à juste titre), qu'il ne trouvait pas cela très "beau" (je dirais surtout ; pas très heureux) :

            Quand aux divergences, je n'ai rien dit car je trouves ca effectivement pas beau

            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: Re:

              Posté par  . Évalué à 5.

              > si, il a dit (à juste titre), qu'il ne trouvait pas cela très "beau"

              Certes.
              Mais le truc n'est pas vraiment la. Il veut dire que les "entrailles" de OOo ne sont pas que l'implémentation d'ODF et qu'il doit y avoir d'autres fonctionnalités qu'on ne trouvent pas dans ODF.
              Techniquement, c'est assurément le cas.
              Tous ceux qui développent savent que parfois ils vont plus loins que la spec. Par exemple, si la spec dit qu'il n'y a que 10 styles, le bon développeur ne va pas faire "style tab_style[10]" mais faire une liste chainée car un jour il y aura peut-être plus de 10 styles.

              Mais l'argument de pasBill pasGates dans la conduite du projets OOo est foireux. Pourquoi OOo déciderait d'ajouter une fonctionnalité que ODF ne supporte pas ? Il est stupide d'ajouter une fonctionnalité alors qu'on ne peut pas la sauvegarder.
              Et pouquoi OOo partirait développer une fonctionnalité sans en premier en discuter avec ceux qui participent à ODF ? OOo ne va pas développer un truc tant qu'il n'est pas sûr qu'il pourra le sauvegarder dans ODF. De plus la discution avec le groupe ODF peut être très profitable avant de commencer les développements. Pourquoi, si OOo trouve une fonctionnalité intéressante, il ne chercherait pas en premier à la mettre dans ODF ?

              Pourquoi OOo développerait une fonctionnalité qui ne peut être, par exemple, que sauvegardé dans MS-OOXML ? Ça poserait des problèmes de migration vers ODF et ça verrouillerait les utilisateurs dans MS-OOXML. Bref, c'est stupide.
              Quand on y réfléchit 2 secondes, on constate rapidement que c'est totalement stupide. M'enfin, pasBill pasGates va continué de répéter l'inverse.

              Notons que pasBill pasGates va répéter à l'envi que supporter complètement MS-OOXML par OOo n'est pas un problème. Mais que MS-Office supporte complètement ODF est un gros problème...
              Ses incohérences sont à mourrir de rire. Mais maintenant elles me fatiguent trop.
              • [^] # Re: Re:

                Posté par  . Évalué à 1.

                Mais l'argument de pasBill pasGates dans la conduite du projets OOo est foireux. Pourquoi OOo déciderait d'ajouter une fonctionnalité que ODF ne supporte pas ? Il est stupide d'ajouter une fonctionnalité alors qu'on ne peut pas la sauvegarder.

                Il y a un truc genial (ok, moyen pour l'interop mais quand meme) dans OOXML et ODF, c'est les extensions.

                OO peut sauver ce qu'il veut dans ODF, si ODF lui-meme le supporte pas, il peut le mettre dans les extensions, et le jour ou ODF le supportera, passer au format lui-meme.

                Bref, c'est stupide.
                Quand on y réfléchit 2 secondes, on constate rapidement que c'est totalement stupide. M'enfin, pasBill pasGates va continué de répéter l'inverse.


                Justement non, car le but d'OO c'est pas de pousser un format au detriment d'un autre, c'est de repondre aux besoins des utilisateurs, et il y a un moyen de le faire, en sauvant les additions dans ODF si necessaire.
                • [^] # Re: Re:

                  Posté par  . Évalué à 4.

                  > OO peut sauver ce qu'il veut dans ODF, si ODF lui-meme le supporte pas, il peut le mettre dans les extensions, et le jour ou ODF le supportera, passer au format lui-meme.

                  Oui, il peut le faire. Mais il ne le fait pas.
                  OOo peut violer le format ODF, peut chier sur les standards comme MS le fait. Mais voila, OOo ne le fait pas. Fin.

                  > Justement non, car le but d'OO c'est pas de pousser un format au detriment d'un autre, c'est de repondre aux besoins des utilisateurs, et il y a un moyen de le faire, en sauvant les additions dans ODF si necessaire.

                  Ça c'est ton raisonnement à la Microsoft qui en a rien à foutre des standards.
                  Si c'est utile pour l'utilisateur, alors en premier on demande une modification/ajout/adaptation du standard (et il n'y a pas de raison que le standard refuse l'idée dans le fond si c'est utile), puis on implémente.

                  Faire ainsi n'est pas au mépris de l'utilisateur, c'est au bénéfice de l'utilisateur. Certes la réactivité est plus faible pour une demande précise. Mais in fine c'est au bénéfice de l'utilisateur. Html, le w3c, etc le démontre sans l'ombre d'un doute.

                  Tu démontres encore une fois que tu ne comprends pas l'intérêt des standards et que t'en as rien à foutre.
  • # Le blog Sun de l'annonce de l'écriture d'un filtre MS-OOXML

    Posté par  . Évalué à 3.

    http://blogs.sun.com/GullFOSS/entry/office_open_xml_ooxml_fi(...)

    Remarquons que c'est "vieux". Bien avant que MS-OOXML soit certifié ISO.

    First of all, why is Sun's OpenOffice.org team developing OOOXML filters, respectively participating in their development? Well, it has always been in our strong interest that OpenOffice.org users can seamlessly interact with multiple file formats, including the binary formats of MS Office. So it is only natural that we care about OOXML now, too.

    OOXML is the file format of Microsoft Office 2007. That means, sooner or later, people that use Microsoft Office 2007 and want to migrate to OpenOffice.org will look for ways to get existing OOXML documents into OpenOffice.org. And at some point in time, OpenOffice.org users will receive OOXML documents, because Microsoft Office 2007 users will start sending them out, assuming that everyone can read them.

    ...

    How far have we got with the development of OOXML filters? First of all, Sun's OpenOffice.org developers are only working on import filters, that is, filters that read OOXML documents into OpenOffice.org. We are not working on export filters, that is, filters that save OOXML documents. Simple reason is that the both situations I've described above only require OOXML import filters. For saving documents, we have ODF. I will come back to ODF later.

    ...

    But let's go back to the OOXML filters. Does the development of OOXML import filters mean that we have changed our mind regarding ODF? A clear, a very, if not to say a crystal clear: No. We strongly believe, ODF is the only file format that provides the level of interoperability and choice of products that our customers want. ODF is the file format whose development and standardization we are actively supporting at OASIS, and it remains the native file format of OpenOffice.org. And with the Sun ODF Converter software [ http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=8&am(...) ], we make ODF available even to Microsoft Office users. So, nothing is changed here.


    Bien que ODF soit un standard, ben MS n'a toujours pas fait de filtre d'import d'ODF satisfaisant et Sun l'a donc fait.
  • # ODF format natif !

    Posté par  (site web personnel) . Évalué à 1.

    Ce qui est regrettable, c'est d'avoir ajouté l'option de "sauvegarder" automatiquement en .doc :( Si vous installé OOo, ne faite jamais cela !

    Ce qui est regrettable aussi, c'est qu'OpenOffice.org soit associé aux fichiers de MS Office (.doc) alors même que ce dernier est présent sur le système (Windows donc). Si vous installé OOo, ne faite jamais cela !

    Ce sera pareil pour "Open XML" (le nom de ce format me révolte...)

    Il faut mettre l'accent sur le format natif de chaque logiciel, et ODF est celui de OpenOffice.org ! même s'il "doit" être ou est capable d'importer et/ou d'exporter un maximum de formats ! Ces fonctions devraient toujours être présenté comme telles, comme des exportation "avec perte" et des exportation "avec perte".
  • # Mouais

    Posté par  (site web personnel) . Évalué à 2.

    On peut discuter de la pertinence du temps passé à implémenter OOXML, mais explique quelle est le bénéfice d'installer chez toi un tel plugin ?

    Si tu ne veux pas ouvrir de OOXML n'en ouvres pas. Quel intérêt de retirer des possibilités ?

    Il y a des fois ....

Suivre le flux des commentaires

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