Dans la mesure ou la norme fait 6000 pages, ( pour comparer "perl en action en fait 900, et c'est le plus gros bouquin d'info que j'ai trouvé, donc, pour visualiser, tu prends le plus gros bouquin d'info que tu as , et tu en prends 6 ou 7 ), je pense que oui, ç'est long.
De plus, la norme définit un format qu'on ne peut pas valider complétement via des moyens normaux ( ie, les bitfields, on ne peut pas dire en xml ce champ doit pas dépasser XX car c'est un bitfield de 3 bit" ), ou justement les bitfields ne sont pas des constantes nommés ( encore une fois, expliqué ici http://www.robweir.com/blog/2006/10/bit-about-bit-with-bits.(...) ). Le manque de validation fait que tu ne sait pas si le fichier entrant est correct ou pas, et pire, tu ne peut pas savoir si tu produit un document correct en sortie à 100%
Et pour finir, les bitfields poseront des problémes certains lors du portage sur des archis ou l'ordre des octets ( endianess : http://fr.wikipedia.org/wiki/Endianness ) différente du i386, comme le ppc, ce qui bien sur va générer des bugs et faire perdre du temps aux developpeurs soucieux de la portabilité ( cad, tout ceux de distributions comme debian, fedora, gentoo, et qui vont faire des rapports de bugs ), et je suis sur à parier qu'il faudra un certains temps avant que tout les problémes soient corrigés et découvert de maniére empirique avec des corrections sans doute différentes ( et générant des fichiers non validés à 100% ).
Et ça, c'est juste sur la base des bitfields, peut être que les 6000 pages du standard cachent d'autres problémes du même genre .
Et de toute façon, novell, dans le cadre de l'accord avec MS, bosse sur le support en question. Les gens ont fait du reverse engineering pour comprendre le format word, qui est quand compliqué, avec la quasi-réimplementation d'un systéme de fichier ( http://sc.openoffice.org/compdocfileformat.pdf ), comme souvent dans les systémes d'archives ( genre le .pak de quake, etc ), en plus de la nécessité de comprendre le format des informations, donc bon, avoir 6000 pages de documentations ne peut pas vraiment être pire.
Bien sur, il ne reste plus qu'à la communauté du libre que de mettre en avant le fait que l'odf, c'est quand même plus facile à supporter, et d'installer autant que possible le convertisseur sur word, http://odf-converter.sourceforge.net/download.html chez les autres.
[^] # Re: Question
Posté par Misc (site web personnel) . En réponse à la dépêche Normalisation des formats de fichiers des suites bureautiques. Évalué à 10.
De plus, la norme définit un format qu'on ne peut pas valider complétement via des moyens normaux ( ie, les bitfields, on ne peut pas dire en xml ce champ doit pas dépasser XX car c'est un bitfield de 3 bit" ), ou justement les bitfields ne sont pas des constantes nommés ( encore une fois, expliqué ici http://www.robweir.com/blog/2006/10/bit-about-bit-with-bits.(...) ). Le manque de validation fait que tu ne sait pas si le fichier entrant est correct ou pas, et pire, tu ne peut pas savoir si tu produit un document correct en sortie à 100%
Et pour finir, les bitfields poseront des problémes certains lors du portage sur des archis ou l'ordre des octets ( endianess : http://fr.wikipedia.org/wiki/Endianness ) différente du i386, comme le ppc, ce qui bien sur va générer des bugs et faire perdre du temps aux developpeurs soucieux de la portabilité ( cad, tout ceux de distributions comme debian, fedora, gentoo, et qui vont faire des rapports de bugs ), et je suis sur à parier qu'il faudra un certains temps avant que tout les problémes soient corrigés et découvert de maniére empirique avec des corrections sans doute différentes ( et générant des fichiers non validés à 100% ).
Et ça, c'est juste sur la base des bitfields, peut être que les 6000 pages du standard cachent d'autres problémes du même genre .
Et de toute façon, novell, dans le cadre de l'accord avec MS, bosse sur le support en question. Les gens ont fait du reverse engineering pour comprendre le format word, qui est quand compliqué, avec la quasi-réimplementation d'un systéme de fichier ( http://sc.openoffice.org/compdocfileformat.pdf ), comme souvent dans les systémes d'archives ( genre le .pak de quake, etc ), en plus de la nécessité de comprendre le format des informations, donc bon, avoir 6000 pages de documentations ne peut pas vraiment être pire.
Bien sur, il ne reste plus qu'à la communauté du libre que de mettre en avant le fait que l'odf, c'est quand même plus facile à supporter, et d'installer autant que possible le convertisseur sur word, http://odf-converter.sourceforge.net/download.html chez les autres.