Bug 170478 - Feature Migrate from XML to Markdown
Summary: Feature Migrate from XML to Markdown
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-01-26 05:39 UTC by Bernard Schœnacker
Modified: 2026-01-26 05:39 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernard Schœnacker 2026-01-26 05:39:05 UTC
Description:
Sehr geehrte Damen und Herren,

ich wende mich an Sie mit einer technischen Anregung, die aus meiner Sicht für die zukünftige Weiterentwicklung von LibreOffice von grundlegender Bedeutung ist.

Beim Arbeiten mit ODT und DOCX zeigt sich seit Jahren ein strukturelles Problem:
Die XML-basierten Container mischen Inhalt, Layout, Styles und Logik in einer Weise, die sowohl die Wartbarkeit als auch die Interoperabilität nachhaltig erschwert. Jede Änderung des XML-Interpreters führt zwangsläufig zu Seiteneffekten, Regressionen oder Darstellungsfehlern. Für eine langfristige Archivierung sind diese Formate nur eingeschränkt geeignet.

Aus Sicht der technischen Dokumentation und der industriellen Qualitätssicherung ist ein anderer Ansatz notwendig:

1. Einführung eines textbasierten Quellformats (Markdown)
Ein sauberes, diff-fähiges, menschenlesbares Format wie Markdown bietet klare Vorteile:

vollständige Trennung von Inhalt und Darstellung

robuste Versionierbarkeit (Git)

reproduzierbare Ausgabe (PDF/ODT über Pandoc/LaTeX)

langfristige Lesbarkeit ohne proprietären Interpreter

2. Strukturierter Container anstelle komplexer XML-Pakete
Statt ODT/DOCX-Komplexität wäre ein transparenter Container denkbar:

markdown
Copier le code
dokument.mdz
├── dokument.md
├── metadata.yaml
└── bilder/
    ├── grafik01.png
    └── diagramm.svg
YAML eignet sich für Metadaten wesentlich besser als JSON, insbesondere hinsichtlich Stabilität, Klarheit und Zukunftssicherheit.

3. Grafische Inhalte strikt extern halten
Einbettete Grafik-Editoren erhöhen die Komplexität erheblich.
Externe SVG/PNG-Dateien sind für Wartung und Archivierung eindeutig überlegen.

4. Perspektive über dem Tabellenkalkulations-Bereich
Viele Probleme mit Calc resultieren aus der Vermischung von Daten, Logik und Darstellung.
Ein modernes Konzept trennt diese Schichten:

Daten: CSV / TSV / Parquet

Parametrisierung: YAML

Logik: externe Skripte (Python, Lua …)

Darstellung: ODS/PDF als Endprodukt

Das entspricht bewährten industriellen Prinzipien (Trennung der Verantwortlichkeiten, Nachvollziehbarkeit, Langzeitarchivierung).

Qualität trifft den Nagel.
Ein solcher Schritt würde LibreOffice nicht nur technisch stabiler machen, sondern auch als Werkzeug für professionelle Dokumentation und langfristige Archivierung deutlich aufwerten.

Ich würde mich freuen, wenn diese Überlegungen in zukünftige Architekturentscheidungen einfließen könnten.
Für Rückfragen oder einen technischen Austausch stehe ich gerne zur Verfügung.

Mit freundlichen Grüßen

Bernard Schœnacker
Verfahrenstechniker
Industrieller technischer Redakteur
Fénétrange (Moselle)
France
	
		
	


Actual Results:
nothink

Expected Results:
output in Markdown or PDF


Reproducible: Always


User Profile Reset: No

Additional Info:
Sehr geehrte Damen und Herren,

ich wende mich an Sie mit einer technischen Anregung, die aus meiner Sicht für die zukünftige Weiterentwicklung von LibreOffice von grundlegender Bedeutung ist.

Beim Arbeiten mit ODT und DOCX zeigt sich seit Jahren ein strukturelles Problem:
Die XML-basierten Container mischen Inhalt, Layout, Styles und Logik in einer Weise, die sowohl die Wartbarkeit als auch die Interoperabilität nachhaltig erschwert. Jede Änderung des XML-Interpreters führt zwangsläufig zu Seiteneffekten, Regressionen oder Darstellungsfehlern. Für eine langfristige Archivierung sind diese Formate nur eingeschränkt geeignet.

Aus Sicht der technischen Dokumentation und der industriellen Qualitätssicherung ist ein anderer Ansatz notwendig:

1. Einführung eines textbasierten Quellformats (Markdown)
Ein sauberes, diff-fähiges, menschenlesbares Format wie Markdown bietet klare Vorteile:

vollständige Trennung von Inhalt und Darstellung

robuste Versionierbarkeit (Git)

reproduzierbare Ausgabe (PDF/ODT über Pandoc/LaTeX)

langfristige Lesbarkeit ohne proprietären Interpreter

2. Strukturierter Container anstelle komplexer XML-Pakete
Statt ODT/DOCX-Komplexität wäre ein transparenter Container denkbar:

markdown
Copier le code
dokument.mdz
├── dokument.md
├── metadata.yaml
└── bilder/
    ├── grafik01.png
    └── diagramm.svg
YAML eignet sich für Metadaten wesentlich besser als JSON, insbesondere hinsichtlich Stabilität, Klarheit und Zukunftssicherheit.

3. Grafische Inhalte strikt extern halten
Einbettete Grafik-Editoren erhöhen die Komplexität erheblich.
Externe SVG/PNG-Dateien sind für Wartung und Archivierung eindeutig überlegen.

4. Perspektive über dem Tabellenkalkulations-Bereich
Viele Probleme mit Calc resultieren aus der Vermischung von Daten, Logik und Darstellung.
Ein modernes Konzept trennt diese Schichten:

Daten: CSV / TSV / Parquet

Parametrisierung: YAML

Logik: externe Skripte (Python, Lua …)

Darstellung: ODS/PDF als Endprodukt

Das entspricht bewährten industriellen Prinzipien (Trennung der Verantwortlichkeiten, Nachvollziehbarkeit, Langzeitarchivierung).

Qualität trifft den Nagel.
Ein solcher Schritt würde LibreOffice nicht nur technisch stabiler machen, sondern auch als Werkzeug für professionelle Dokumentation und langfristige Archivierung deutlich aufwerten.

Ich würde mich freuen, wenn diese Überlegungen in zukünftige Architekturentscheidungen einfließen könnten.
Für Rückfragen oder einen technischen Austausch stehe ich gerne zur Verfügung.

Mit freundlichen Grüßen

Bernard Schœnacker
Verfahrenstechniker
Industrieller technischer Redakteur
Fénétrange (Moselle)
France