Journal : Peut-on virer OOXML d'OOo ?
Posté par fleny68 () le 04 avril 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).
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).
> Lire le journal (24 commentaires, moyenne: 3,1).
Vous avez demandé le commentaire #920053.
Run by 
Cette page a été générée par Templeet en 0.0607s (dont 0.0087 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Re:
> 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 ColorOOXML 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:
> 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:
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:
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:
> la reponse est la : http://www.linuxfr.org/comments/920072.html#920072
La réponse n'y est pas.
[^]Re: Re:
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
Tous ensemble contre l'esclavitude des logiciels privateurs !
[^]Re: Re:
> 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:
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:
> 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.