Ressources numériques en sciences humaines et sociales OpenEdition Nos plateformes OpenEdition Books OpenEdition Journals Hypothèses Calenda Bibliothèques OpenEdition Freemium Suivez-nous

Le traitement de textes (odt) pour produire des documents structurés (XML/TEI) — Odette

Le traitement de textes est à peu près universellement employé comme outil de création de textes. Ce succès auprès du grand public a surtout été obtenu par Microsoft, au début des années 1990, avec un Word WYSIWYG (What You See Is What You Get). Ce qu’on voit, c’est ce qu’on aura… sur l’imprimante ; l’ordinateur est réduit à une machine à écrire avancée. La victoire de Word a été un tournant visuel, et une régression de la structuration intellectuelle du texte, ré-attaché au format contingent d’une page de papier. Le concurrent principal, WordPerfect, avait un modèle de texte plus précis, et plus fluide, à une époque où les formats d’impression étaient beaucoup moins normalisés. Pour le vaincre, il fallait, au moins en apparence, satisfaire ses utilisateurs. Le vaincu survit encore à l’état de traces dans MS.Word, par des fonctionnalités avancées, reprises par les logiciels libres qui l’ont imité par la suite (OpenOffice.org, LibreOffice). Cet article détaille les structures textuelles qu’un logiciel bureautique permet de produire, et qu’un programme peut extraire (conversion automatique vers un XML sémantique). Ces pratiques ne servent pas seulement à augmenter la qualité invisible des documents produits, elles accroissent aussi l’efficacité et la qualité du visible. Espérons qu’il est encore temps, car ces bonnes pratiques sont en train de disparaître « dans les nuages » (Cloud). Le succès attendu des éditeurs connectés, type Google.docs ou Apple.Pages, annonce une nouvelle régression dans la structuration du texte, et la perte voulue par les grandes compagnie de la compatibilité entre les formats.


Odette, pour extraire le XML sémantique d’un traitement de textes

L’usage du traitement de textes qui est expliqué ici n’est pas une pure potentialité théorique, mais des pratiques qui sont maintenant quotidiennes au sein du labex obvil. Des dizaines d’étudiants, de doctorants, de vacataires et même de chercheurs expérimentés en littérature, sont entrés dans une chaîne de production éditoriale XML/TEI, avec leur logiciel de traitement de textes. Nos bibliothèques électroniques comportent plusieurs centaines de livres, nous allons vers les milliers. J’ai programmé et maintiens depuis plus de dix ans un programme de conversion qui prend en entrée un fichier traitement de textes (format ODT, Open Document Text, produit aussi bien par OpenOffice, LibreOffice et même MS.Word depuis la version 2010) pour rendre le XML le plus propre possible : Odette. Cette expérience donne une vue fine du modèle textuel interne au traitement de textes, et des contournements possibles pour adapter l’outil à d’autres visions philologiques.

1. Un texte selon la bureautique

Un fichier informatique est une ligne de chiffres. Un texte est une suite de caractères, qui peuvent correspondre à des chiffres lorsque l’on convient d’un encodage, mais ce sont aussi beaucoup de conventions pour grouper et structurer ces caractères (italique, paragraphes, chapitres…). Les logiciels, et leurs formats, proposent implicitement une pensée du texte par ce qu’ils permettent, ou par ce qu’ils ne rendent pas possible. Le format interne au traitement de texte articule principalement deux niveaux : caractères, et paragraphes. Cette modélisation semble suffire à de la correspondance commerciale, elle est trop limitée pour un livre, d’autres niveaux sont nécessaires, par-dessus et par-dessous les paragraphes.

Prenons l’exemple du chapitrage. Le traitement de textes n’a pas de structure interne pour représenter l’emboîtement logique d’un ouvrage, par exemple des parties, qui contiennent des chapitres, qui contiennent des sections ; les paragraphes se suivent, sans hiérarchie. Il est cependant possible de simuler de la hiérarchie en donnant un statut particulier à certains blocs : les titres de parties, chapitres et sections. Ces blocs sont stylés avec des étiquettes prédéfinies, “Titre 1”, “Titre 2”, “Titre 3” ; chaque niveau à une présentation normalisée et automatisé, par exemple centré avec saut de page avant pour un titre de partie, plus petit et sans saut de page pour les chapitres, aligné à gauche pour les sections. Le document reste une série plate de paragraphes, mais certains blocs sont étiquetés avec un niveau de titre. Cette information permet de générer automatiquement une table des matières. L’impression de hiérarchie est donnée à l’utilisateur par l’indentation des titres, mais elle n’est pas inscrite dans le code informatique du document.

word-titresMais ce modèle impose des contraintes éditoriales très discutables. Soit par exemple un roman avec une citation en épigraphe en tête de chapitre, avant le titre. Si c’est le titre qui porte le style “Titre 1”, alors l’épigraphe n’est pas contenue logiquement dans le chapitre. Pour l’impression, il est possible de trouver des astuces, les problèmes commenceront lorsque l’on voudra exporter ce livre automatiquement en site web ou en livre électronique (epub), les chapitres commenceront avec le titre, l’épigraphe sera à la fin du chapitre précédent. Si c’est l’épigraphe qui porte le style “Titre 1”, alors la table des matières aura les citations pour titres. Le seul bricolage possible serait de marquer le début de chapitre avec un titre invisible (par exemple en blanc sur blanc), contenant l’intitulé du titre, reporté dans la table des matières, et ensuite suivraient l’épigraphe et un titre visible (selon l’ordre voulu par l’auteur). Cet exemple d’acrobatie montre bien comment le problème initial d’un logiciel, ici le document d’entreprise, influence très longtemps le modèle et les interfaces. Il existe d’autres fonctionnalités et structures de contenus relevant de procédés similaires, rangés ici en ordre de taille.

 1.1. Niveau caractère

Le format natif d’un traitement de textes, afin de réagir vite à l’utilisateur, est surtout un enregistrement d’événements de saisie. Ceci suffit à l’apparence mais conduit à bien des inconvénients logiques. Si par exemple dans un mot en italique je mets une lettre en droit, puis je la remets en italique, le segment peut être logiquement interrompu avant et après cette lettre, même si en apparence, les lettres restent collées.

<!-- pseudo-code xml où l’italique est interprété comme un titre d’œuvre -->
<title>Le Bourge</title><title>o</title><title>is gentilhomme</title>

Ce type d’artefacts est typique de ce que produit une conversion du traitement de textes qui ne s’occupe que d’apparence et pas de sémantique. Cet encodage ne permet pas d’extraire facilement une liste de titres cités. La liste des éléments <title> donnera les valeurs suivantes :

  • Le Bourge
  • o
  • is gentilhomme

Toutefois, on imagine que l’on puisse aisément rétablir la continuité de la balise <title>. Le problème se complique à la rencontre de deux propriétés. Soit par exemple des lettres en exposant dans un terme en italique

les hôtels 1ère classe ne sont pas des 4 étoiles

Parce que le traitement de textes ne permet pas l’enchâssement au niveau caractères, le texte est segmenté à chaque changement d’apparence, d’abord italique, puis italique+exposant, et de nouveau italique [1].

<!-- modèle interne au logiciel -->
 [1] les hôtels <c rend=”i”>1</c><c rend=”i sup”>ère</c> <c rend=”i”>classe</c>
 <!-- structure XML souhaitée -->
 [2] les hôtels <i>1<sup>ère</sup> classe</i>

Un automate en plusieurs étapes peut cependant résoudre ces cas en décidant d’une liste de priorité entre les mises en forme. S’il est décidé que l’italique peut contenir de l’exposant, alors si de l’italique touche de l’italique+exposant, l’exposant sera contenu dans l’italique. Entre les erreurs invisibles, et les besoins parfois très exigeants d’une édition électronique (bibliographie, dictionnaires), une récupération optimale d’un texte mise en forme doit résoudre les cas qui suivent.

  • Segment italique interrompu par des espaces droits
  • Petites Capitales Interrompues Par Des Majuscules
  • Stupide xixe siècle (titre en italique contenant petites capitales et exposant)
  • le Quichotte des romantiques (souligné regroupant différentes mises en formes locales)
  • Surlignage utilisé pour regrouper des champs d’information : Auteur, titre, référenceC […]

Les conventions typographiques (exposant, petites capitales, italique, souligné, couleurs…) ne sont pas juste décoratives, l’auteur leur prête un sens, que le lecteur décode plus ou moins consciemment pour grouper et étiqueter sémantiquement des mots comme : personnes, titres d’œuvres citées, concepts importants… Le langage du caractère est équivoque. L’italique, notamment, a des usages très variés, il sert par exemple à distinguer les expressions en langues étrangères, les mots en mention, où les paroles rapportées ; tandis qu’une même fonction textuelle, comme une citation en cours de paragraphe, pourra être en italique si elle est en prose, ou en droit avec saut de ligne pour un vers. Si un projet éditorial exige de définir de l’information précise au sein d’un paragraphe, on conseillera d’utiliser des styles de niveau caractères, dont l’étiquetage sera plus précis. Afin de stimuler leur emploi par les auteurs, il faut y attacher des mises en forme complexes, par exemple un fond coloré avec une autre police, plus difficile à reproduire manuellement. Avec un tel modèle de document, l’utilisateur est engagé dans un autre usage du traitement de textes, où ce qu’il voit n’est pas ce qu’il veut imprimer, mais un état du texte optimisé pour la production.

1.2. Niveau paragraphe

La présentation par défaut d’un paragraphe dans un traitement de texte est un bloc séparé du suivant par une ligne vide. Au sens strict, cette interprétation est juste, mais en conséquence, les alinéas (bloc avec indentation de première ligne) sont au même niveau hiérarchique qu’un paragraphe, alors que dans la prose classique, un paragraphe peut contenir plusieurs alinéas. D’emblée, le modèle intrinsèque du logiciel retire un niveau d’articulation de la pensée. Les utilisateurs de traitement de textes ont de plus la mauvaise habitude de cacher les sauts de paragraphes ¶ (Entrée, <p>), ne voulant pas voir à l’écran les caractères non-imprimables, si bien qu’ils risquent des erreurs de segmentation.

word-p

Ainsi, les utilisateurs abusent souvent des paragraphes vides, il n’est pas possible de décider automatiquement s’ils sont significatifs ou pas. Ils peuvent servir à séparer des alinéas, des strophes de vers, mais beaucoup d’éditeurs les utilisent aussi pour l’espacement vertical, par exemple entre un titre et un paragraphe de texte. Plutôt que cette mauvaise pratique, on conseillera de configurer des styles avec marge par-dessus et par dessous, par exemple des titres de chapitre normalisés avec saut de page avant, 5 lignes vides au-dessus, et 2 en-dessous. Si la taille du papier ou le colonage changeait, il suffirait de modifier les styles pour ajuster automatiquement tout l’équilibre de la mise en page (au lieu d’aller reprendre les paragraphes vides à chaque tête de chapitre).

Le niveau paragraphe accepte des nuances sémantiques plus claires que le niveau caractère et des conventions typographiques plus libres (centré : titre ? intertitre ? personnage de théâtre ? aligné droit : date ? signature ? polices, espacements ?). Sauf projet spécifique, pour l’interprétation automatique des blocs, il vaut mieux se fier à des noms explicites de style. Les logiciels viennent ainsi souvent avec une liste de styles par défaut (citations, signature…), qui conviennent à beaucoup d’utilisateurs, mais pas à l’édition électronique. Un projet éditorial ou de recherche aura intérêt à définir sa feuille de style. La présentation des éléments textuels importe moins que le nom qui leur est donné, qui sera reconnu par un programme d’extraction sémantique, par exemple pour distinguer les citations, les vers, les personnages d’une pièce de théâtre, les didascalies… Afin de ne pas entrer dans des querelles terminologiques, on conseillera de se fier à un vocabulaire externe, avec des mots clés fixés. En contexte XML/TEI, ces éléments ont un nom, avec une définition, et des explications en ligne. Ils peuvent être transposé comme nom de style, on conseillera d’ailleurs de les encadrer de chevrons, ce qui permettra de les repérer rapidement au début de la palette des styles d’un logiciel (<quote>, <l>, <speaker>, <stage>…).

Les styles de blocs permettent de varier visuellement le flot textuel, mais ils souffrent d’une limitation importante, chaque bloc est séparé du suivant, sans lien logique explicite, à part, comme nous le verrons ci-dessous, les listes et les tableaux. Or, il existe des structures textuelles pourtant très classiques qui ne relèvent pas des listes et tableaux, comme les strophes de vers, ou la titraille d’un article de presse (avec surtitre et chapeau). Quelques ruses avec le modèle restent possibles. Un programme peut par exemple regrouper des paragraphes de même style, c’est fréquent pour reconstituer des blocs préformatés (<pre>, pour les exemples de code informatique). Il est aussi possible de reconnaître des séquences régulières, par exemple des listes alternant des termes et leur définition (dl: (dt+, dd)+). On peut considérer que plusieurs paragraphes en style citation (<quote>) appartiennent à la même citation. Pour les strophes de vers, on obtient les résultats les plus fiables avec un style vers (<l>), avec un paragraphe par ver, et un “vers vide” pour séparer les strophes. Pour le théâtre, un tour de parole peut être commencé par une didascalie de personnage (<speaker>), et s’arrêter au nom de personnage suivant, ou au début d’une scène (“Titre 2”).

Il reste cependant des séquences non déterministes qui ne peuvent pas être reconnues sur la seule série des noms de styles, par exemple, une lettre citée dans un roman, une chanson à strophes dans du théâtre en vers, du théâtre cité par un critique littéraire… Entrer dans cette précision ne relève pas de la manie, il y a un intérêt scientifique à distinguer informatiquement ce qu’un auteur dit et ce qu’il cite. Voyons cet exemple tirés du Moliérana, une suite d’anecdotes, de prétendus facts à propos de Molière, reprises par Cousin d’Avallon en 1801 (anecdote 93, p. 136-138).

La scène d’un pauvre avec D. Juan, dans laquelle Molière avait peint, avec trop d’énergie peut-être, la scélératesse raisonnée de son héros, éleva les clameurs des hypocrites et des faux dévots. Elle fut supprimée à la deuxième représentation.Voici cette scène très courte que Voltaire nous a donnée, après l’avoir vue écrite de la main de Molière, entre les mains du fils de l’un des amis de notre auteur.

Dom Juan rencontre un pauvre dans la forêt, et lui demande à quoi il y passe sa vie.

Le Pauvre
À prier Dieu pour les honnêtes gens qui me donnent l’aumône.
Dom Juan
Tu passes ta vie à prier Dieu ? Si cela est, tu dois être fort à ton aise.
Le Pauvre
Hélas ! Monsieur, je n’ai pas souvent de quoi manger ?
Dom Juan
Cela ne se peut pas ; Dieu ne saurait laisser mourir de faim ceux qui le prient du soir au matin : tiens, voilà un louis d’or, mais je te le donne pour l’amour de l’humanité.

 

Un auteur, Cousin d’Avallon, cite un passage du théâtre de Molière. Un éditeur électronique souhaitera que le paragraphe “Dom Juan” apparaissent comme dans une pièce de théâtre, mais que l’on sache aussi que c’est une citation. Il faudrait pouvoir lui appliquer deux propriétés (par exemple les styles <quote> et <speaker>), ce n’est pas permis par le modèle interne au traitement de textes. On pourrait créer de nouveaux styles pour ces cas (<quote.speaker> qui signifierait un nom de personnage dans une citation), mais cela compliquerait beaucoup la palette de styles parce qu’il faudrait aussi distinguer les vers et les vers cité, la signature d’un article, ou une signature dans une lettre citée… Plus il y a de choix, plus il y a risque d’erreurs.

Ces structures semblent exceptionnelles, mais dès lors que le reste peut se régler avec le traitement de textes, les équipes beaucoup moins nombreuses qui savent éditer du XML sont engorgées par ces cas épineux, qui demandent à revenir dans le texte pour être interprétés avec justesse. Le traitement de textes simule visuellement ces regroupements lorsque plusieurs paragraphes stylés sont entourés d’une bordure. À l’OBVIL, nous avons convenu que les blocs entourés de bordures seront sémantiquement considérés comme des citations complexes. Il faut ensuite qu’un programme retrouve cette propriété dans le labyrinthe du format natif au traitement de textes, et que les blocs avec bordures soient regroupés. Non seulement le programme fonctionne, mais nous pouvons aussi dire que la consigne est comprise et bien appliquée.

1.3. Listes et tableaux

La liste, à puces ou à numéros, groupe une série de paragraphes. Les items ne peuvent pas contenir plusieurs paragraphes, la touche Entrée produit un nouvel item, mais un item peut contenir une liste (jusque 10 niveaux d’imbrication). Les listes permettent de représenter un arbre. Beaucoup de compositions textuelles imprimées ou manuscrites qui par le passé ont été présentées en tableau sont structurellement des listes. Ainsi par exemple, le terme table des matières insiste sur la colonne des numéros de page aligné à droite, mais il s’agit surtout d’un arbre hiérarchique de sections imbriquées. Dans les textes scientifiques anciens, des alignements complexes, avec des accolades, se ramènent assez souvent à des listes. On préfèrera largement des structures linéarisées, qui peuvent beaucoup mieux s’écouler sur des écrans de largeurs différentes.

beauzee_superlativSystème figuré des sens graduels.

  • ABSOLUS.
    • Positif, sage.
    • Ampliatif, très-sage.
    • Diminutif, un peu sage.
  • COMPARATIFS.
    • d’égalité, aussi sage.
    • de supériorité, plus sage.
    • d’infériorité, moins sage.

Beauzée, Encyclopédie, article « SUPERLATIF »

Les tableaux peuvent être des structures à une dimension (une ligne ou une colonne), à deux, et même plus, puisque chaque cellule peut contenir plusieurs paragraphes, des listes, et même des tableaux. Il faut d’abord décourager tout usage des tableaux à des fins de composition (ruse pour assurer la disposition de textes ou d’images). Le traitement de textes n’est pas un logiciel de composition, il ne faut pas tout lui demander. Il est conseillé de limiter l’usage des tableaux aux données qui ne peuvent pas être mises en listes, et de se rappeler que les écrans ne seront pas tous de la même largeur.

1.4. Notes (bas, fin)

Les notes, de bas de page ou de fin de document, permettent d’accrocher un groupe de paragraphes au flux principal de texte. Il est ainsi possible d’utiliser des styles de blocs (citations, etc…) à l’intérieur d’une note, mais pas de mettre une note dans une note (de bas ou de fin). Il n’est pas possible de numéroter soi-même les notes selon l’ordre de son choix, par exemple pour reprendre la même note 1 à plusieurs endroits du texte. Les contournements ne sont pas compatibles entre les logiciels et ne seront pas possible à extraire. Une édition académique peut nécessiter des conventions supplémentaires : conserver la numérotation d’une édition originale, attribuer la note (auteur, éditeur…), la typer (établissement du texte, vocabulaire, noms propres, histoire critique…)… Ces besoins ne sont pas prévus par les logiciels, il vaut mieux alors établir une convention textuelle qui sera comprise par un programme.

[NdA] Exemple de note d’auteur.
[NdE] Exemple de note d’éditeur.
Le cœur troué par un son, ses idées partent(1)  au pays où les racines marchent.
(1) Dans le manuscrit, remplace : Chacun a un son qui lui troue le cœur

Le modèle bureautique d’une note est un point (l’appel en exposant), mais l’édition électronique permet d’être plus précis. La note ne porte pas toujours sur le mot auquel elle est accrochée, elle peut concerner un segment plus long. C’est d’usage fréquent dans une édition critique de manuscrit où l’on signale des passages omis ou ajoutés entre les différents témoins consultés. Si un projet éditorial le nécessite, il est possible de marquer ce segment avec un code typographique, par exemple un surlignage (qu’un programme saura reprendre).

1.5. Index ou liens

La composition d’index est une fonctionnalité avancée du traitement de textes, elle demande un peu de familiarisation. La structure souffre d’un premier inconvénient, elle n’est pas toujours très visible selon les logiciels et les configurations. Le principe consiste à insérer une entrée d’indexation à un point du texte, le logiciel propose un formulaire où l’on peut entrer 1, 2 ou 3 termes. Un autre bouton permet d’insérer l’index en fin de livre.

Les index peuvent être utilement complétés par un code couleur de surlignage, permettant non seulement le repérage visuel, mais aussi le balisage des formes dans le texte qui sont rapportées à un terme contrôlé.

Albert Thibaudet, Réflexions sur la littérature, « 16. Mallarmé et Rimbaud »

Mallarmé{ XE “Sujet:Auteur:Mallarmé, Stéphane (1842-1898)” } et Rimbaud{ XE “Sujet:Auteur:Rimbaud, Arthur (1854-1891)” }

Il m’est arrivé d’écrire qu’on pouvait discerner, à la pointe extrême de la littérature actuelle, une influence de Mallarmé et de Rimbaud. C’était à propos de la Suzanne de M Giraudoux{ XE “Œuvre citée:Giraudoux, Jean (1882-1944):1921, Suzanne” }, dans l’île de laquelle se trouvait un rocher Rimbaud, et qui, en nageant une ou deux heures, eût pu découvrir, non loin de cette île, le pays de la prose pour Des Esseintes{ XE “Œuvre citée:Mallarmé, Stéphane (1842-1898):1899, Poésies” }. […]

  • Œuvre citée
    • Giraudoux, Jean (1882-1944)
      • 1921, Suzanne, 8
    • Mallarmé, Stéphane (1842-1898)
      • 1899, Poésies, 8
  • Sujet
    • Auteur
      • Mallarmé, Stéphane (1842-1898), 8
      • Rimbaud, Arthur (1854-1891), 8
< !-- Indexation sous forme de liens -->
<h1>16. <a class="author" href="http://fr.wikipedia.org/wiki/Stéphane_Mallarmé"
>Mallarmé</a>
et <a class="author" href="http://fr.wikipedia.org/wiki/Arthur_Rimbaud"
>Rimbaud</a></h1>

Il est aussi possible de simuler une fonctionnalité similaire avec des liens dans le texte qui renvoient à un glossaire en ligne. La portée de la clé d’indexation est clairement visible, par contre, les erreurs de destination ne sont pas détectables sans aller suivre chaque lien.

1.6. Structures à éviter

Les traitements de textes permettent quelques autres structures que l’on ne conseillera pas pour la production de texte structuré.

Les cadres (frames, à distinguer des bordures) permettent de positionner des objets (textes, images…) avec des coordonnées relatives aux dimensions de la page. On notera d’abord que les utilisateurs se plaignent souvent du manque de stabilité de ces objets au fur et à mesure de la rédaction (exemple : grosse image passant d’une page à l’autre). De plus, il est rare de conserver parfaitement une disposition entre MS.Word et OO ou LibreO. Même si les utilisateurs ont pris l’habitude de tout lui demander, un traitement de texte n’est pas un logiciel de composition de maquettes, son modèle est fondé sur le flux du texte avec une pagination dynamique, difficile à concilier avec le positionnement des cadres. Leur conversion dans un autre format sera généralement décevante, d’autant plus si l’utilisateur maîtrise mal l’ancrage. Un cadre apparaissant à l’écran dans le premier paragraphe d’une page peut être en réalité être accroché au troisième, rompant la logique voulue par l’auteur.

Entêtes et pieds de page courants ne sont pas facilement récupérables, et portent généralement une information spécifique de l’imprimé.

On déconseillera de s’appuyer sur les sections. Elles seraient potentiellement très puissantes, mais plusieurs mises en forme uniquement visuelles en génèrent automatiquement, comme l’insertion d’un index, ou le colonage, si bien qu’une structure voulue par un auteur serait perturbée.

1.7. À partir de quand faut-il sortir du traitement de textes ?

Le traitement de textes est un compromis entre la puissance des ordinateurs personnels des années 1990 et le goût du public pour les polices et les couleurs. L’énorme communauté autour de ces limites à produit des contournements, et des interfaces maintenant très connues, qui rendent productif. Il manque cependant 3 volets décisifs qui justifient le passage des documents dans un format structuré comme XML/TEI : voir le code source, un langage de script pour modifier ce code source, et la validation contre un schéma pour contrôler la structure. Les fichiers traitement de textes seront rapidement illisibles, par contre la philologie numérique continuera encore longtemps.

2. Solutions courantes de conversion

Convertir un document traitement de textes en XML semble un problème aussi trivial qu’un “Enregistrer Sous”. Ça peut l’être pour des utilisations occasionnelles, mais pour une chaîne éditoriale, le moindre jeu dans la transmission de l’information peut faire perdre des heures de travail. Un état de l’art des outils existants permet d’observer finement les structures textuelles qui se conservent bien, ou qui posent problème.

Un premier indice permet de se figurer ce que contiennent ces fichiers, la taille (en ko). Afin de mesurer ce qui est fixe pour chaque fichier, on comparera un fichier vide, et un livre sans images d’environ 250 pages imprimées (~400 000 signes, Jeannel, La morale de Molière). Comme les formats bureautiques natifs sont des dossiers de fichiers zippés, les tailles sont indiquées avec ou sans compression. Sur la colonne de droite, le txt est le texte brut unicode, sans aucune information de présentation (pas d’italique) ou de structure (pas de titres ou de citations).

odt docx MS.word,
html
OO, LibreO
xhtml
MS.word
htm filtré
OO, LibreO
html
XML/TEI txt
vide zippé 9 18 6 2 3 ~1 ~0 0
vide 25 80 36 3 16 1 ~0 0
livre zippé 349 295 251 241 205 200 156 143
livre 3010 1770 1760 1313 977 865 529 419

Odt est le format natif d’OpenOffice et LibreOffice, docx est le format natif de MS.Word, ils sont très verbeux, multipliant jusqu’à 7 fois la taille du texte. Les différents parfums de html sont compatibles avec un XML sémantique mais portent aussi beaucoup d’information de présentation. XML/TEI est le format le plus optimisé, sans perte d’information sémantique, destiné à pouvoir être modifié par un être humain.

2.1 MS.Word HTML

MS.Word a très tôt offert un enregistrement en HTML 3.0 (1997), avec l’intention d’intégrer le navigateur Internet Explorer à la suite bureautique. L’utilisateur devait avoir l’impression que l’Internet était un simple périphérique de lecture et d’écriture pour la suite MS.Office. La captation a heureusement échoué, mais elle a lourdement orienté l’emploi que MS.Word a fait de HTML. Ce format n’est pas à proprement parler du XML, mais les balises sont récupérables. Le problème essentiel, pour un usage sémantique, découle de l’objectif poursuivi par l’éditeur : il ne s’agit pas seulement d’un export, mais d’un “enregistrer sous”, qui doit permettre au logiciel de retrouver toute l’information qu’il possède dans son format natif. Sur des tests avec la version Word 2010, il en résulte un préambule de 4500 lignes de code sans information sémantique. Il est théoriquement proposé un export « Page Web filtrée (*.htm, *.html) », une fenêtre surgissante et inquiétante signale que des informations seront perdues, on notera que le préambule descend à 1500 lignes, le fichier est presque deux fois moins lourd, mais le code reste “sale”, inutilement bruité par de l’information non sémantique. Il faut toutefois constater et saluer la bonne qualité de ce que l’on peut extraire.

les hôtels <i>1<sup>ère</sup> classe</i> ne sont pas des quatre étoiles

Avantages

  • facile d’emploi
  • conservation des noms de style
  • mise en formes locales (italique, petites capitales, couleurs…)
  • unicode
  • hiérarchie des mises en forme de niveau caractère (exposant dans l’italique, italique dans le souligné)
  • entrée d’index récupérables

Inconvénients

  • payant et commercial, code fermé impossible à modifier
  • non conforme XML
  • nettoyage requis (manuel ou programmé)
  • pas de sections enveloppantes
  • pas de notes de bas de page normalisées
  • pas de listes hiérarchiques (ul/li), juste des paragraphes avec puces et indentation
  • pas de regroupements de paragraphes (préformaté, citations complexes…)

Pour des programmeurs agiles, le HTML Microsoft produit du texte avec une structuration de bonne qualité, mais il vaut mieux en rester à un usage occasionnel. Pour un usage plus industriel, il faut inévitablement compter avec 5 ou 6 versions de Word avec leurs fantaisies, fausses bonnes idées et déclinaisons selon les systèmes (la version pour Apple.MacOS est volontairement limitée pour faire préférer Microsoft.Windows). Un logiciel libre peut se mettre à jour gratuitement et automatiquement, contrairement à un logiciel payant.

2.2 OpenOffice.org et LibreOffice, HTML

Face à l’hégémonie de MS.Office, Sun a racheté StarOffice au début des années 2000, pour le distribuer gratuitement avec ses stations UNIX, mais aussi, pour MS.Windows. Ne pouvant pas assumer seul le développement d’un logiciel aussi gros, il a offert la base de code à la communauté logiciel libre (et financé plusieurs développeurs décisifs), c’est donc grâce à Sun, contre Microsoft, qu’est apparu une suite bureautique logiciel libre : OpenOffice.org, avec pour format natif, odt. OpenOffice.org peut aussi ouvrir et modifier presque sans perte les fichiers de MS.Word dans son format natif (doc, et docx). En 2010, Oracle a racheté Sun, et donc la marque OpenOffice.org ; ils avaient l’intention de décliner une version commerciale d’OOo. La communauté libre a “fourché” le code pour fonder LibreOffice. Oracle ayant raté son coup de force, le projet commercial était sans avenir, ils ont abandonné OpenOffice à la fondation Apache, un solide consortium protégeant les droits du libre.

Les deux logiciels libres proposent, comme MS.Word, une fonction “enregistrer sous” HTML. Le fichier peut être rouvert par le logiciel qui l’a produit, sans perte fonctionnelle comparé au format d’enregistrement natif. Cependant, HTML ne spécifie pas tout ce qu’un traitement de textes peut produire (ex : notes), si bien que les fichiers sont truffés d’extensions propriétaires et ne sont pas compatibles sans perte entre les logiciels.

Il est intéressant de comparer le HTML produit par OpenOffice et LibreOffice, en 2015, 5 ans après la séparation des deux communautés. Par dessous les noms et couleurs de l’interface, l’inertie du code logiciel engage les bateaux sur 10 à 15 ans de route encore très similaire. OpenOffice.org ne semble pas avoir touché à cette fonctionnalité depuis la définition du format OpenDocument (2005), c’est du “vieux” HTML, noms de balises en majuscules, pas d’unicode, lettres accentuées sous formes d’entités (é = &eacute;). LibreOffice semble au premier abord plus moderne, mais la structure est globalement la même. Un programmeur a pris le temps de comprendre le code, il a placé des lignes intelligentes qui ont ajouté sans rien casser, mais la fonctionnalité n’a pas été repensée et réécrite dans sa globalité, des comportements astucieux ont été perdus (regroupement des blocs préformatés <pre>), des fausses bonnes idées produisent du bruit (les titres hiérarchique <h1>, <h2>… sont emballés dans des listes ol/li pour générer automatiquement la numérotation du chapitrage), mais des faiblesses notoires ont été corrigées (conserver les petites capitales). Pour cette raison, on conseillera donc plutôt LibreOffice à OpenOffice, les évaluations qui suivent concernent LibreOffice.

les hôtels <i>1</i><sup><i>ère</i></sup><i> classe</i>…

Avantages

  • facile d’emploi
  • logiciel libre
  • correspondance exacte entre éléments HTML et styles prédéfinis
  • pas strictement xhtml mais assez rapide à rendre conforme

Inconvénients

  • perte de tous les noms de styles qui n’ont pas de correspondance directe avec un élément HTML
  • pas de forme normalisée pour les notes en HTML
  • code natif au logiciel, difficile à modifier sans recompiler l’application

Il est désagréable d’en convenir, mais la perte des styles utilisateur exclut définitivement LibreOffice, il vaut mieux utiliser MS.Word pour des conversions occasionnelles.

2.3 OpenOffice.org et LibreOffice, export xhtml

OpenOffice et LibreOffice peuvent être complétés avec des filtres XML (transformations XSLT), en import et/ou en export. Cette fonctionnalité déçoit généralement les utilisateurs, car ce n’est pas un “enregistrer sous”, il y a inévitablement des pertes dans les conversions ; mais une fois ces réserves connues, avec des modèles de document strictement définis, la fonctionnalité peut être utile. Le filtre xhtml fait correctement ce que demande habituellement le public, une conservation de l’apparence. Il retransmet aussi très strictement tous les artefacts des traitements de texte, notamment la segmentation à chaque événement typographique. Le grand secret de ce filtre est d’interprétation tous les styles automatiques sous forme de règles CSS (langage réglant l’apparence des balises), donnant belle allure à l’écran, du moins, tant qu’on ne s’avise pas de regarder la source.

les hôtels <span 
class="Police_20_par_20_défaut"><span 
class="T1">1</span></span><span 
class="Police_20_par_20_défaut"><span 
class="T11">ère</span></span><span 
class="Police_20_par_20_défaut"><span 
class="T1"> classe</span></span> ne sont pas des 4 étoiles

 /* italique */
 .T1 { font-style:italic; }
 /* italique + exposant */
 .T11 { vertical-align:super; font-size:64%;font-style:italic; }

Ici aussi, on préfèrera LibreOffice, qui conserve les petites capitales.

Avantages

  • natif dans le logiciel
  • xhtml facile à transformer vers TEI ou autre XML
  • base de code modifiable

Inconvénients

  • les mises en forme locales produisent des styles automatiques où se perdent les styles sémantiques
  • pas de forme normalisée pour les notes en xhtml
  • pas de régularisation de la segmentation
  • pas de regroupements hiérarchiques, même pour des éléments xhtml connus (<pre>, <dl>)

Le code xhtml produit semble au départ très propre et facilement utilisable, en réalité les styles automatiques créent un labyrinthe de références qui ne peut pas être résolu avec un automate simple (expressions régulières), il faut un programme plus complexe avec en mémoire une table de correspondance pour chaque style. Ce sont les mêmes problèmes que pour le format natif du traitement de texte, en ce cas il vaut mieux aller à la source et investir de la programmation sur docx ou odt.

2.4 OxGarage (docx vers XML/TEI)

Le consortium TEI distribue librement les transformations de Sebastian Rahtz depuis les formats bureautiques vers TEI, sous forme d’un client Web, OxGarage. Contrairement à HTML, TEI standardise des éléments pour plus de composants textuels que ce que peut produire un traitement de textes, et notamment, les notes de bas de page ou les points d’indexation. Le consortium TEI a une très haute exigence de qualité XML, le TEI produit par OxGarage a progressé ces dernières années, notamment sur la résolution des styles automatiques et la conservation des mises en forme locales, rejoignant ce qu’Odette faisait. La solution de Sebastian Rahtz présente des avantages uniques, notamment une large matrice de formats d’import et d’export, les inconvénients concernent moins la qualité que des problèmes d’ingénierie et d’administration.

les hôtels <hi 
rend="italic">1</hi><hi 
rend="italic superscript">ère</hi><hi 
rend="italic"> classe</hi> ne sont pas des 4 étoiles

Avantages

  • officiellement supporté par le consortium TEI
  • XML sémantique de grande qualité
  • sections enveloppantes
  • sources libres
  • paramétrable

Inconvénients

  • transformation XSLT 2 (un seul processeur libre, beaucoup moins déployé que XSLT 1)
  • service Java (hébergement plus difficile que du PHP)
  • pas de version en ligne de commande
  • perte des marques d’index
  • pas de regroupement de niveau bloc (citations complexes) ou de niveau caractère (exposant dans l’italique…)
  • perte des mises en forme de bloc (droite, centré, encadré)

Les limitations XML constatées en mars 2015 pourraient très bien disparaître dans les mois à venir, il ne resterait que les inconvénients d’ingénierie : administration Java et communication par service web. Si cela ne pose pas de problème à l’utilisateur, OxGarage est une excellente solution.

2.5 Odette

Odette a été développé pour exporter le XML/TEI de la qualité la plus élevée possible, il corrige tous les inconvénients énumérés plus haut. Le logiciel est activement développé et maintenu dans un contexte éditorial exigeant, tout en devant coordonner de nombreux contributeurs, de compétence informatique très variable. Il en résulte un compromis optimal entre les possibilités des formats et celles des humains. La conversion permet par exemple d’éditer des pièces de théâtre classique, avec numérotation des vers, paratexte, index ou glossaire, sans perte d’information XML et très peu de reprise dans les balises, sauf ce qu’apporte la validation (ex : vérification des tours de parole, de la distribution des rôles, des liens entre termes et glossaire…). La librairie est à base de transformation XSLT et d’automates, elle fonctionne en ligne de commande et en client web, elle est disponible en PHP, Bash, Python (Java possible si demandé).

les hôtels <hi rend="i">1<hi rend="sup">ère</hi> classe</hi> ne sont pas…

Conclusion

Les logiciels bureautiques souffrent de limites intrinsèques à leur modèle mais restent très confortables. L’exploration systématique des fonctionnalités permet de définir des modèles de documents pour des projets éditoriaux complexes. Toutefois, quelles que soient la conscience des auteurs, ou la finesse des filtres de conversion, il faut admettre et faire comprendre que le seul format pérenne et fiable de cette structure, c’est le texte balisé (XML, par exemple TEI), que l’on pourra précisément nettoyer et valider contre un schéma.

Frédéric Glorieux

Ingénieur informatique

More Posts - Twitter - Flickr


OpenEdition vous propose de citer ce billet de la manière suivante :
Frédéric Glorieux (8 avril 2015). Le traitement de textes (odt) pour produire des documents structurés (XML/TEI) — Odette. J’attends des résultats. Consulté le 2 décembre 2024 à l’adresse https://doi.org/10.58079/tocx


Publié par Frédéric Glorieux

Ingénieur informatique

Rejoindre la conversation

6 commentaires

    1. Merci. Le monde de la recherche est exigent, il vaut mieux avoir les idées claires pour être efficace, reste à trouver le temps de les écrire. En tous cas, ça sert aussi à les clarifier.

  1. Bonjour,
    Au fait vraiment j’ai trouvé le document très intéressant et riche dans le domaine du traitement de texte.
    cordialement ,
    SIDIBE Modibo.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.