[fr-discuss] [discuss] Générer un ODT from scratch à partir de texte brut : démonstration technique de la dérive XML (sans éditeur XML)

Bonjour,

Ce message vise à documenter **de manière strictement technique et reproductible** la génération 
d’un document ODT *from scratch* à partir de données textuelles simples, **sans utiliser 
LibreOffice Writer**, **sans éditeur XML dédié**, et à montrer ce qui se produit ensuite lorsque le 
moteur de mise en forme intervient.

L’objectif n’est ni polémique ni idéologique :
il s’agit de **rendre observable** la différence entre *document source* et *document rendu*, et 
d’illustrer concrètement la dérive structurelle du XML ODF lorsqu’il est utilisé comme format 
source.

---

## 1. Point de départ : texte brut correctement rédigé

Fichier `source.txt` :

```
Titre du document

Sous-titre

Premier paragraphe de texte.
Deuxième phrase du même paragraphe.

Deuxième paragraphe.

Liste :
- élément A
- élément B
```

Hypothèse volontairement simple :

* texte propre,
* structure humaine évidente,
* aucune information de style.

---

## 2. Construction manuelle d’un ODT minimal (sans Writer)

Un document ODT est un **conteneur ZIP** contenant du XML.
Pour produire un ODT valide, **trois fichiers suffisent**.

### Arborescence minimale

```
demo.odt
├── mimetype
├── content.xml
└── META-INF/
    └── manifest.xml
```

### 2.1 mimetype (fichier texte brut)

```
application/vnd.oasis.opendocument.text
```

Contraintes importantes :

* doit être le **premier fichier** de l’archive,
* doit être **non compressé**.

---

### 2.2 content.xml (structure saine, volontairement minimale)

```xml
<?xml version="1.0" encoding="UTF-8"?>
<office:document-content
 xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0"
 xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0"
 office:version="1.2">

 <office:body>
  <office:text>

   <text:h text:outline-level="1">Titre du document</text:h>
   <text:h text:outline-level="2">Sous-titre</text:h>

   <text:p>Premier paragraphe de texte. Deuxième phrase du même paragraphe.</text:p>
   <text:p>Deuxième paragraphe.</text:p>

   <text:p>Liste :</text:p>
   <text:list>
    <text:list-item><text:p>élément A</text:p></text:list-item>
    <text:list-item><text:p>élément B</text:p></text:list-item>
   </text:list>

  </office:text>
 </office:body>
</office:document-content>
```

Remarques :

* aucune section `<office:automatic-styles>`,
* aucun style explicite,
* aucune information de mise en page,
* structure lisible à l’œil humain.

---

### 2.3 META-INF/manifest.xml

```xml
<?xml version="1.0" encoding="UTF-8"?>
<manifest:manifest
 xmlns:manifest="urn:oasis:names:tc:opendocument:xmlns:manifest:1.0"
 manifest:version="1.2">

 <manifest:file-entry
  manifest:full-path="/"
  manifest:media-type="application/vnd.oasis.opendocument.text"/>

 <manifest:file-entry
  manifest:full-path="content.xml"
  manifest:media-type="text/xml"/>

</manifest:manifest>
```

---

### 2.4 Création de l’archive ODT

```bash
zip -0X demo.odt mimetype
zip -r9 demo.odt content.xml META-INF
zip -T demo.odt
```

Résultat :

* le fichier `demo.odt` s’ouvre dans LibreOffice Writer,
* le document est valide,
* le XML est minimal, stable, lisible.

---

## 3. Intervention du moteur de mise en forme

Étape volontairement simple :

* ouvrir `demo.odt` dans Writer,
* **ne rien modifier**,
* enregistrer,
* fermer.

Puis réextraire `content.xml`.

```bash
unzip demo.odt content.xml
wc -l content.xml
grep 'style:name' content.xml | wc -l
```

Constats observables :

* apparition automatique de `<office:automatic-styles>`,
* génération de styles `P1`, `P2`, `T1`, etc.,
* héritages implicites,
* augmentation significative du volume XML,
* aucune correspondance directe avec l’intention initiale du texte.

Conclusion intermédiaire :

> le XML produit après passage par le moteur n’est plus une représentation directe du texte, mais 
> une **trace d’exécution du rendu**.

---

## 4. Cas particulier : duplication des images identiques

Cas fréquent :

* insertion d’un même logo ou cartouche à plusieurs endroits,
* copier/coller dans Writer.

Après sauvegarde :

```bash
unzip demo.odt | grep Pictures/
```

Résultat typique :

```
Pictures/10000000000001F4000000A8326EAA3F.png
Pictures/10000000000001F4000000A8326EAA3F_1.png
Pictures/10000000000001F4000000A8326EAA3F_2.png
```

Observations :

* images identiques dupliquées physiquement,
* aucun mécanisme de mutualisation,
* gonflement inutile de l’archive,
* maintenance impossible à grande échelle.

---

## 5. Conclusion technique

Cette démonstration montre que :

1. Il est possible de générer un ODT valide **sans éditeur**, à partir de texte brut.
2. Tant que le document reste à l’état minimal, le XML est :

   * lisible,
   * stable,
   * structurellement sain.
3. Le passage par le moteur de mise en forme :

   * introduit des styles automatiques,
   * mélange structure et rendu,
   * transforme le XML en format d’exécution.
4. Le style et le layout interfèrent alors directement avec la source.

Conclusion générale :

> **Le problème n’est pas l’interface utilisateur,
> mais le fait que le style modifie aujourd’hui la source du document.**

Ce message ne propose pas de solution logicielle,
il documente un état de fait observable et reproductible.

Cordialement,

Bernard Schoenacker
Rédaction technique / analyse documentaire

-- 
Envoyez un mail à discuss+unsubscribe@fr.libreoffice.org pour vous désinscrire
Les archives de la liste sont disponibles à https://listarchives.libreoffice.org/fr/discuss/
Privacy Policy: https://www.documentfoundation.org/privacy