tibibs a écrit :



Mais au passage si quelqu’un sait : J’ai cru comprendre que la documentation sur les docx et compagnie était disponible. D’où la question : la documentation est-elle limitée ou les problèmes de compatibilité viennent de la manière de retranscrire l’architecture d’un document office dans le moteur de LO ou autres?







C’est plus subtil que ça.



Microsoft a effectivement publié un standard, ouvert et librement disponible : OOXML Strict, utilisé par les documents aux formats docx, xlsx, etc. Ce standard est donc implémenté dans Open Office, Libre Office et d’autres suites bureautiques : ces suites peuvent parfaitement lire et produire des documents en OOXML Strict. C’est un standard ouvert au même titre que l’ODF, si on veut.



Malheureusement il existe un autre format, bien moins documenté : le OOXML Transitional. En gros c’est la même chose que le OOXML Strict, mais avec des blobs binaires en plus, des fonctions non documentées et non-ouvertes, du genre « Formater ce document à la façon de Word 95 ». Ce format n’est pas ouvert, pas documenté, et ces blobs binaires ne peuvent pas être interprétés par Libre Office et consors. Seulement par MS-Office. L’extension de ces fichiers ? docx, xlsx… Oui ça utilise les mêmes extensions que le format Strict, pour ajouter à la complexité de la chose.



Maintenant la question à 1000 Francs : quel est le format par défaut utilisé par MS-Office ? Vous croyez qu’il s’agit du OOXML Strict, que Microsoft a tenu coûte que coûte à ériger en standard et a promu comme étant interopérable partout ? Et bien non, raté, les suites MS-Office utilisent… le OOXML Transitional ! Ce qui garantit qu’un document créé par MS-Office (en OOXML Transitional donc) sera mal rendu dans une autre suite bureautique.



Regardez le tableau de cet article :

MS-Office 2007 et 2010 supportent parfaitement le OOXML Strict. Pourtant si vous enregistrez un document en docx, il sera enregistré en OOXML Transitional par défaut. Il faut aller dans le menu Enregistrer sous, et explicitement choisir le format « Strict Open XML Document ». Bref autant dire que quasiment personne ne se soucie de ça. Pour MS-Office 2013 je ne suis pas sûr, mais je ne serais pas étonné que le format par défaut soit toujours le Transitional.



Mais ça ne s’arrête pas là ! Il y a bien entendu d’autres astuces que Microsoft utilise pour s’assurer que les documents produits par MS-Office poseront des problèmes sur les autres suites bureautiques. L’une de ces techniques est l’utilisation des « C-fonts » par défaut depuis MS-Office 2007, ainsi nommées car elles commencent toutes par un C : Calibri, Cambria, Cadara, Consolas, Constancia… Le point commun de toutes ces polices de caractères ? Elles sont fermées, copyrightées, il faut payer une licence pour les utiliser. Comprendre donc : elles sont fournies et utilisables gratuitement sous Windows, mais ne sont pas disponibles sous Mac OS X ni sous Linux. Donc quand tu ouvre un fichier docx avec Libre Office sous Linux, il ne trouvera pas le police Cambria par exemple, et la remplacera par une autre police, ce qui va péter toute la mise en page. Il existe un certain nombre de « core fonts », des polices disponibles sur toutes les plates-formes (Arial, Georgia…). Il existe plein de polices libres de droits, ou au moins gratuites à télécharger, y compris les fameuses polices Microsoft True Type qui sont aujourd’hui installables partout… Mais non. Avec la main droite Microsoft a standardisé le format OOXML, et avec la main gauche ils ont créé les C-fonts et les ont imposées par défaut dans MS-Office.



Au final avec ce genre de pratiques, il est toujours aussi compliqué d’avoir une vraie interopérabilité avec le OOXML. Dans la plupart des cas, un document créé avec MS-Office sous Windows, sera difficile à ouvrir avec autre chose, sans avoir plein de problèmes. Même MS-Office sous Mac peut avoir des problèmes, c’est dire…



D’un autre côté, le format ODF 1.2 est quant à lui parfaitement standardisé, documenté, et il est supporté aussi bien par MS-Office, Libre Office, Open Office, et ainsi de suite. C’est sans aucun doute le format qui permet la meilleure interopérabilité aujourd’hui.