informations complémentaires

De l’utilisation des formats bureautiques comme pivots de production de contenus accessibles à usages multiples

Ce document a été initié avec MS-WORD puis compléter avec LibreOffice afin de démontrer l’interopérabilité des systèmes.

L’objectif de ce document est d’être à la fois l’explication du sujet et un élément de réalisation des tests. La première partie est consacrée aux explications du concept, la seconde au support de tests.

Quelques explications

Les principaux outils de rédactions de textes bureautiques tels que MS-Word ou LibreOffice utilisent un format basé sur un schéma XML (Open Document pour le monde libre et LibreOffice – fichiers ODF – et Open Office XML pour la solution propriétaire de Microsoft – fichiers DOCX). Quel que soit le format choisi, la passerelle entre les deux est simple et élégante. Nous sommes loin des sauvegardes sous forme binaire.

L’accès au contenu est évident puisque ces différents formats sont des compressions au format ZIP de l’arborescence des dossiers et des fichiers, du contenu et des propriétés du contenu. C’est l’ensemble contenu + propriétés + habillage graphique qui est nommé document.

Le premier intérêt de ces formats et de ces fichiers est leur facilité de lecture. Nous sommes dans le cadre fichiers accessibles et lisibles directement et simplement sans interprétation.

Le second intérêt vient du choix d’une structure XML. Ce choix signifie que nous travaillons avec des contenus qui sont par définition structurés et ainsi faciles à traiter ou à analyser. Mais, cela cache une autre caractéristique fondamentale : la séparation stricte du fond et de la forme. Nous ne sommes pas en présence d’un amas de décorations typographiques ou positionnement spatiaux de textes (comme dans le cas du format descriptif PDF – Portable Document Format) mais bien dans un contenu structuré.

La structure de ces contenus n’est pas le fruit du hasard ou de l’application technique d’un schéma XML, c’est simplement l’expression des styles utilisés au travers des interfaces utilisateurs. L’ensemble de la chaîne, du rédacteur au stockage technique, est donc directe et élégante.

Ne reste plus qu’à définir un modèle de document (donc un modèle de structure documentaire) qui fasse sens pour les rédacteurs et les lecteurs. Ce modèle documentaire va ainsi apporter une structure sémantique au contenu en complément de la structure technique directement issue du format XML.

Mais en quoi tout ceci permet-il de proposer (voire garantir) un contenu in fine accessible et utilisable sur l’ensemble des canaux pour la bonne distribution du contenu ?

En premier lieu, l’utilisation de styles prédéfinis dans un modèle de document (et en verrouillant les styles) contraint de manière évidente le rédacteur à ne plus utiliser son outil de traitement de texte comme une simple machine à écrire (avec du simple texte décoré afin de reproduire une pseudo structure du contenu) mais, comme un outil de contenu sémantique. En effet, si l’utilisateur refuse d’utiliser les styles mis à sa disposition, le résultat à la diffusion du contenu ne serait d’une longue chaîne de caractères sans aucune structure ni indication sémantique. La séparation du fond et de la forme entraîne de fait un non-traitement des éléments de décoration.

En second lieu, le fait que le format produit soit une structure XML permet également de réaliser des contrôles de cohérence. Ces contrôles de cohérence peuvent être structurels (par exemple, un titre de niveau 4 ne peut pas être le fils d’un titre de niveau 2), mais ces contrôles peuvent également traiter des éléments liés à la nature du contenu (soit en volumétrie, soit en qualité de structure).

Nous voici donc avec un contenu structuré et validé produit simplement avec un outil courant de traitement de texte disponible sur la grande majorité des ordinateurs (Les suites MS-Office et LibreOffice doivent couvrir un périmètre proche des 100?% des producteurs de contenus).

Mais nous avons plus que cela.

La diffusion des contenus se fait majoritairement au travers de quelques formats :

  • Natif, les fichiers issus de la sauvegarde à partir du traitement de texte au format DOCX ou ODF. C’est le plus simple.
  • PDF, certains considèrent que cela représente soit une solution universelle et sécurité de diffuser des documents accessibles. La portabilité était un argument au début du XXIe siècle, mais plus aujourd’hui. Pour le reste, c’est une légende tenace.
  • HTML (Hyper Texte Markup Language), très pratique pour une diffusion Web des contenus.

Et, il existe également d’autres besoins ou possibilités :

  • XML DAISY (Digital Accessible Information System), très pratique pour une conversion en braille ou une lecture audio du contenu.
  • EPUB (electronic publication), le format standardisé des livres numériques.

La multiplicité des cibles de publication peut représenter un travail conséquent et de fait représenter un frein à la bonne mise en pratique de la diffusion universelle (et donc accessible des contenus). Mais, pas si l’ensemble de ces cibles peut être adressés sans effort complémentaire et en garantissant à la fois la qualité du contenu et son adaptabilité au contexte de la cible.

Le contexte de la cible ?
Chaque format porte ses contraintes ou besoins. Dans le cadre du HTML, la forme graphique est spécifique au site Web (ou espace numérique) où le contenu doit être présenté. Pour le format EPUB, des métadonnées doivent être présentent et la présentation peut être spécifique. Le format XML DAISY ne réclame aucune mise en forme. Ce sont là quelques exemples de contextes de la cible.

Cela peut sembler représenter une difficulté de plus, pas un élément de facilité ! Aucunement.

Reprenons. Nous avons un contenu au format XML qui a été validé dans sa structure technique et sémantique. Nous devons proposer ce contenu dans différents formats qui sont tous (sauf un spécifique) basé sur une structure proche du XML (et même du XML pour certains). Et nous venons de format et de contenus édités facilement et disponible nativement au format XML. Une simple transformation élégante d’un schéma XML vers un autre schéma XML répond à la question. Simple et évident.

Le seul format spécifique (encore une fois) et le format PDF, mais dans ce cas, le plus simple est de directement utiliser les options d’enregistrement direct du contenu au format PDF à partir des outils de traitement de texte. Même si les puristes pourraient considérer que produire un fichier PDF à partir du XML source est finalement assez facile. C’est vrai, des outils permettent de le faire assez simplement et c’est d’ailleurs une excellente solution lorsque l’on souhaite diffuser au format PDF sous des formes différentes. Mais, dans la grande majorité des cas, le « sauver sous PDF » est le plus évident et pratique.

Pour les autres formats :

  • HTML, est une structure très proche du XML, il suffira de prévoir d’ajouter quelques éléments de spécifications CSS (Cascading Style Sheet) de base afin de permettre l’application de n’importe quel charte graphique ou présentation sur les sites Web cibles.
  • XML DAISY, XML vers XML. Pas de problème particulier.
  • EPUB, basé sur HTML5, la production d’un EPUB devra respecter quelques éléments de structure, le fichier EPUB étant lui-même un ensemble de dossiers et contenus compressés au format ZIP. Les contenus étant au format HTML composé – le plus souvent – par un fichier HTML par chapitre de contenu.

Autre élément pratique dans cette démarche, les propriétés du document (titre, sujet, auteur et toutes les autres) sont disponibles dans quelques fichiers XML stockés dans l’arborescence du document. Donc, normalement pas d’édition supplémentaire des propriétés.

Pour les curieux

L’arborescence d’un document DOCX est la suivante :

  • docProps qui contient les éléments de propriétés du contenu (core.xml en particulier)

  • _rels

  • word qui contient le contenu dans le fichier document.xml

  • La racine contient le fichier : [Content_Types].xml

Références

Quelques références liées aux différents formats cités :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.