https://bugs.documentfoundation.org/show_bug.cgi?id=170478
Bug ID: 170478
Summary: Feature Migrate from XML ti Markdown
Product: LibreOffice
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: enhancement
Priority: medium
Component: Writer
Assignee: [email protected]
Reporter: [email protected]
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
--
You are receiving this mail because:
You are the assignee for the bug.
