Guten Tag zusammen, im Anschluss an die jüngsten Diskussionen über Wartbarkeit, Konvertierung und Langzeitpflege von ODT-Dokumenten möchte ich einen **rein technischen, dokumentierten und reproduzierbaren Erfahrungsbericht** teilen, basierend auf einem realen Fall.
Ziel ist ausdrücklich **keine Polemik**, sondern die **klare Dokumentation einer Situation**, in der ein ODT-Dokument in LibreOffice Writer korrekt dargestellt wird, jedoch **strukturell nicht als Dokumentationsquelle geeignet ist** (Konvertierung, Versionierung, Analyse). --- ## 1. Kontext Analysiertes Dokument: * *LibOBasic_01_IDE_Flat_A4_FR_v200.odt* * LibreOffice-Basic-Spickzettel (reales, verbreitetes Dokument) * Visuell korrekt und problemlos in Writer nutzbar Beobachtetes Problem: * Fehlgeschlagene Konvertierung nach Markdown mit Pandoc * Dokument nicht als strukturierte Textquelle nutzbar --- ## 2. Prüfung des Containers (ZIP / ODT-Ebene) Ein ODT ist ein ZIP-Container. Erste Analyse daher **außerhalb des Editors**. ```bash zip -T LibOBasic_01_IDE_Flat_A4_FR_v200.odt ``` Ergebnis: **OK** Prüfung der ODT-Mindestkonformität: ```bash unzip -lv LibOBasic_01_IDE_Flat_A4_FR_v200.odt | head ``` Geprüfte Punkte: * `mimetype` vorhanden * `mimetype` an erster Position * `mimetype` unkomprimiert (`Stored`) ➡️ Das Dokument ist **auf Containerebene korrekt**. Das Problem liegt **nicht** im ZIP, nicht im Umbenennen und nicht im Testwerkzeug. --- ## 3. Strukturtest mit Pandoc ```bash pandoc -f odt -t native LibOBasic_01_IDE_Flat_A4_FR_v200.odt --verbose ``` Ausgabe: ``` [ Para [] , Para [] ] ``` Bedeutung: * Pandoc kann den Container lesen * findet jedoch **praktisch keinen verwertbaren Textinhalt** * das Dokument ist aus Sicht eines strikten Parsers **strukturell leer** --- ## 4. Analyse der XML-Struktur (content.xml) Extraktion: ```bash unzip LibOBasic_01_IDE_Flat_A4_FR_v200.odt content.xml ``` Suche nach Textboxen: ```bash grep -n "<draw:text-box" content.xml | head ``` Suche nach Rahmen: ```bash grep -n '<draw:frame' content.xml | head grep -n 'draw:name="CadrePage' content.xml ``` Feststellung: * Der Text befindet sich überwiegend in **`draw:frame / draw:text-box`** * Rahmen sind seitenverankert (`text:anchor-type="page"`) * Rahmen sind **verkettet** (`draw:chain-next-name`) * Es existiert **kein logischer Textfluss** (`office:text` mit `text:p`, `text:h`) ➡️ Es handelt sich um eine **grafische Seitenkomposition**, nicht um ein logisch strukturiertes Textdokument. --- ## 5. Low-Level-Extraktion des Inhalts Extraktion des Textes aus den Rahmen: ```bash xmlstarlet sel -t \ -m '//draw:frame[draw:text-box]' \ -o '--- ' -v '@draw:name' -o ' (Seite ' -v '@text:anchor-page-number' -o ')' -n \ -m './/draw:text-box//text:p' -v 'normalize-space(.)' -n \ -n \ content.xml > extracted.txt ``` Ergebnis: * Vollständiger Textinhalt extrahierbar * jedoch **außerhalb einer dokumentarischen Struktur** --- ## 6. Technische Schlussfolgerung Das Dokument ist: * ✔️ in LibreOffice Writer darstellbar * ✔️ auf ODT-Containerebene korrekt * ❌ nicht als Dokumentationsquelle geeignet * ❌ nicht sauber konvertierbar * ❌ nicht fein versionierbar * ❌ nicht automatisiert übersetzbar **Ursache**: > Der Hauptinhalt ist in grafischen Objekten (`draw:text-box`) abgelegt und > nicht im ODF-Textfluss. --- ## 7. Allgemeine Schlussfolgerung > Ein Dokument kann in einem Editor vollständig lesbar sein und dennoch > strukturell ungeeignet als Quelle. Diese Problematik: * ist keine Kritik an LibreOffice, * ist keine Meinungsfrage, * ist in der grafischen Oberfläche nicht sichtbar, * wird **nur auf XML-Strukturebene erkennbar**. Gerade bei Fragen der Langzeitpflege, Konvertierung und Dokumentationsqualität ist diese Ebene entscheidend. Mit freundlichen Grüßen Bernard Schoenacker Technische Dokumentation / Strukturanalyse -- Envoyez un mail à [email protected] pour vous désinscrire Les archives de la liste sont disponibles à https://listarchives.libreoffice.org/fr/users/ Privacy Policy: https://www.documentfoundation.org/privacy
