XML-Ecke

Struktur in den Content!

LibreOffice will “offenes und einheitliches Format für alle”

Nach den Problemen von OpenOffice.org strebt das Nachfolgeprojekt LibreOffice “ein offenes und einheitliches Format für alle” an. In einem Gespräch auf dem LinuxTag in Berlin sagte Projektmitglied Thomas Krumbein (auf dem Bild 3. von links): “Das ist allerdings ein Traum, den wir seit 20 Jahren haben und der wird auch in den nächsten 20 Jahren nicht realisiert werden. Formate müssten identisch sein, das sind sie aber leider nicht.” Letztlich könnte dies vermutlich nur gesetzlich geregelt werden.

Das Open Document Format (ODF) habe sich bewährt und eine weite Verbreitung gefunden, sagte Krumbein, der auch Gründungsmitglied der Document Foundation ist. Vor allem in Brasilien und Frankreich, aber auch in Deutschland werde es von einem großen Anteil der Anwender eingesetzt. Mit der zunehmenden Verbreitung von LibreOffice werde auch ODF weiter unterstützt. Allerdings verschickten Microsoft-Office-Nutzer ihre Dokumente als docx-Datei, ohne sich Gedanken zu machen, ob das der Empfänger auch lesen könne. Entscheidend sei, ob die Formate ausgetaucht werden könnten.

Der Novell-Manager Holger Dyroff betonte, dass es wichtig sei, die erforderlichen Filter für die jeweils anderen Formate in Microsoft Office und LibreOffice bereitzustellen – hier arbeitet Novell mit Microsoft eng zusammen. Vice President Dyroff sagte: “Da würde ich gerade auch den Microsoft-Office-Nutzer aufrufen, sich mehr mit ODF zu beschäftigen und dann auch die entsprechenden von Microsoft ausgelieferten Import- und Exportfilter zu benutzen, was heute leider relativ selten stattfindet.” Eine gemeinsame Dokument-Format-Lösung auf einer einheitlichen XML-Basis “wäre sicherlich hochgradig angenehm”, aber kaum realistisch. Zurzeit habe Open XML von Microsoft sicherlich den höchsten Marktanteil. In Zukunft sei aber zu erwarten, dass alle offenen Systeme ODF unterstützten, sagte Dyroff. “Da gehört sicherlich LibreOffice dazu, aber auch verschiedene Software-as-a-Service-Anwendungen wie zum Beispiel Google Docs.”

Posted in Im Lauf der Zeit | Tagged , , | Leave a comment

White Paper vergleicht ODF und OOXML

White Paper: Interoperabilität von DokumentenMicrosoft und das Fraunhofer-Institut für Offene Kommunikationssysteme (FOKUS) haben gemeinsam ein White Paper vorgelegt, das die Unterschiede der Dokumentenformate Office Open XML (OOXML) und Open Document Format (ODF) untersucht.Im Mittelpunkt stehen Anwendungsszenarien für die Umwandlung von OOXML in ODF und umgekehrt.

Dateien beider Formate sind komprimierte ZIP-Pakete aus mehreren einzelnen Dateien, welche den Inhalt und die Formatierung eines Dokuments mit den Mitteln von XML beschreiben. Bei OOXML wird “die Struktur des ZIP-Containers … von der Open Packaging Convention (OPC) definiert, die eine Abstraktionsschicht zwischen der physischen Datei/der Verzeichnisstruktur innerhalb der ZIP Datei und der Dokumentenstruktur ist”. Hingegen enthält ODF keine solche Abstraktionsschicht – “stattdessen werden feststehende Dateinamen für Dokumenteninhalt (content.xml), Stilinformation (styles.xml), Metainformation (meta.xml) und Anwendungseinstellungen (settings.xml) benutzt. Diese Dateien finden sich im Root Directory des Archivs.” Hinzu kommt in der Regel noch eine Thumnail-Ansicht des Dokuments im PNG-Format, wie die Autoren des White Papers, Klaus-Peter Eckert, Jan Henrik Ziesing und Ucheoma Ishionwu erklären.

Bei einem einfachen Musterbrief gibt es keine Probleme, wenn man das eine Format in das andere überträgt: “Einfache Textformatierungen wie Fett- und Kursivschrift, Absatzformatierungen sowie Standard-Textausrichtungen (können) problemlos zwischen verschiedenen Formaten konvertiert werden”. Problematisch wird es erst bei “Theme Fonts” von Microsoft, mit denen ODF nichts anfangen kann.

Im nächsten Anwendungsfall geht es um ein Formular mit Text und Tabellen. Hier kann von einer “Interoperabilität” der beiden Formate kaum noch die Rede sein. Das White Paper stellt fest: “Die Abbildung des Dokuments von einem Standard auf den anderen ist in mehrfacher Hinsicht schwierig.” Vor allem bei der Verarbeitung von Leerräumen (White Spaces) könne es zu größeren Schwierigkeiten kommen. Unterschiedliche Wege gehen beide Formate auch im Umgang mit Korrekturen, was für die gemeinsame Arbeit an Dokumenten von zentraler Bedeutung ist. Weitere Unverträglichkeiten entstehen bei der Verwendung von Vektorgrafiken: Während OOXML dafür ein eigenes DrawingML-Format mitbringt, setzt ODF auf den Standard SVG. Das Ergebnis: “Diese Unterschiede bedingen für Vektorgrafiken Probleme bei der Abbildbarkeit zwischen den beiden Standards.”

Auch bei mathematischen Formeln gibt es Unterschiede. ODF setzt hier allein auf den XML-Standard MathML. OOXML unterstützt dies zwar ebenfalls, verwendet daneben aber die eigene Auszeichnungssprache OMML. Als relativ problemlos stufen die Autoren einfache Tabellen mit grundlegenden Formeln ein. Schwieriger wird es erst bei komplexeren Formeln.

Ebenso ist der Austausch zwischen beiden Formaten unproblematisch, wenn es lediglich um einfache Textfolien in Präsentationen geht. Schwierig wird es aber, wenn aufwendige Folienübergänge und Effekte zum Einsatz kommen: “OOXML unterhält ein weitaus umfangreicheres Line-Up an Funktionen, die sich nur eingeschränkt oder gar nicht nach ODF abbilden lassen.”

Je mehr spezielle Funktionen in Dokumente eingebaut werden, desto problematischer wird die Übersetzung zwischen beiden Formaten: “Zusammenfassend kann festgehalten werden, dass viele Funktionalitäten, speziell bei ‘einfach’ gehaltenen Dokumenten, zwischen den Standards abgebildet werden können, während eine Abbildung anderer Funktionalitäten komplex oder unmöglich sein kann.” Letztlich hängt es also immer vom Einzelfall ab, ob ein Dokument des einen Formats von der auf das andere Format spezialisierten Software auf die gleiche Weise dargestellt wird. Die Studie weist aber auch darauf hin, dass hierbei nicht nur die Formatunterschiede eine Rolle spielen, sondern auch die “Rendering Engine” der Grafik und die verwendete Hardware.

Posted in Im Lauf der Zeit | Tagged , , , | Leave a comment

Windows 7 lernt ODF

Vielleicht wird es ja doch noch was mit dem einheitlichen Dokumentenformat: Das neue Windows 7, zurzeit im öffentlichen Betatest, unterstützt mit seiner Textanwendung Wordpad das Open Document Format (ODF). Das Mini-Word bietet beim Speichern neben RTF, TXT und Office Open XML (OOXML) auch das Textformat von ODF an:
Ausgepackt zeigt die odt-Datei die Standardstruktur des Formats, unter  anderem mit der Datei content.xml:

<?xml version="1.0" encoding="UTF-8"?>
<office:document-content xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" xmlns:config="urn:oasis:names:tc:opendocument:xmlns:config:1.0" xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" xmlns:presentation="urn:oasis:names:tc:opendocument:xmlns:presentation:1.0" xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0" xmlns:style="urn:oasis:names:tc:opendocument:xmlns:style:1.0" xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" xmlns:anim="urn:oasis:names:tc:opendocument:xmlns:animation:1.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:math="http://www.w3.org/1998/Math/MathML" xmlns:xforms="http://www.w3.org/2002/xforms" xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0" xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" xmlns:smil="urn:oasis:names:tc:opendocument:xmlns:smil-compatible:1.0">
<office:automatic-styles>
<style:style style:name="T1" style:family="text">
<style:text-properties fo:font-size="36.00pt" fo:font-weight="normal" fo:font-family="Calibri" fo:background-color="transparent" fo:color="# 04dbb" />
</style:style><style:style style:name="P1" style:family="paragraph">
<style:paragraph-properties fo:line-height="115.00%" fo:text-align="left" fo:margin-bottom="10.00pt" />
</style:style>
</office:automatic-styles>
<office:body>
<office:text>
<text:p text:style-name="P1">
<text:span text:style-name="T1">Wordpad lernt </text:span>
</text:p>
<text:p text:style-name="P1">
<text:span text:style-name="T1">ODF und OOXML</text:span>
</text:p>
</office:text>
</office:body>
</office:document-content>

Auch beim Öffnen von Dateien zeigt sich Microsoft offen gegenüber dem konkurrierenden Dokumentenformat. Wordpad kann ohne Installation eines zusätzlichen Filters mit odt-Dokumenten umgehen. Wenig standardbewusst ist hingegen das neue iWork ’09 von Apple. Wie die Vorversion kann das neue Pages weiterhin nur docx-Dateien (OOXML) öffnen, fängt aber nichts mit ODF an. Beim Speichern beherrscht Pages nur das veraltete, binäre doc-Format von Word. Und beim Speichern im eigenen Format mit der Endung .pages wurde die Struktur geändert: Bisher verbarg sich hinter der Datei mit der Endung .pages ein Ordner mit komprimierten Dateien – jetzt handelt es sich (ähnlich wie bei ODF und OOXML) um einen komprimierten Ordner mit normalen Dateien. Diese Änderung hat zur Folge, dass Dateien, die mit Pages ’09 gespeichert wurden, von Pages ’08 nicht geöffnet werden können. Anstatt in die allgemein verständliche XML-Welt auszubrechen, bastelt Apple weiter an proprietären Formaten.

Posted in Im Lauf der Zeit | Tagged , , , | 1 Comment

Neue Schnittstelle für ODF-Anwendungen

Das Open Document Format (ODF) bekommt eine frei zugängliche Programmierschnittstelle (API). Damit soll die Entwicklung von Anwendungen vereinfacht werden, um ODF-Dokumente zu lesen, zu erstellen oder zu bearbeiten, ohne sich erst tief in die Spezifikation des Format vergraben zu müssen. Gedacht ist an Content-Management-Systeme oder Systeme für den Dokumenten-Workflow.

Die API soll Teil eines größer angelegten ODF Toolkits sein, zu dessen Unterstützern Sun Microsystems und IBM gehören. Sun hat schon mal einen ODF Validator beigesteuert, eine Java-Applikation, die die Konformität von ODF-Dokumenten überprüft. 

Im Zentrum der API steht ODFDOM. Dieses Document Object Model (DOM) definiert alle denkbaren Bestandteile des Dokumentenformats in einer Baumstruktur und verwendet ein Schichtenmodell:

 

ODFDOM Model

ODFDOM Model

 

 

Auf der Basisebene ganz unten geht es um die im ODF-Paket gespeicherten Dateien, also etwa die XML-Dateien oder Bilder. Die API kümmert sich darum, dass der gesamte Content des Dokuments in das Zip-Paket gepackt oder von dort herausgeholt werden. 

In der COM-Ebene werden die XML-Elemente, etwa aus der Datei content.xml verwendet, um gezielt auf einzelne Bestandteile zugreifen zu können. Auf der Grundlage des DOM-Konzepts wird jedem Element eine Java-Klasse zugeordnet.

Die zweite Ebene von oben behandelt allgemeine Funktionen für die Benutzerführung einer ODF-Anwendung, und in der obersten Ebene werden nutzerspezifische Einstellungen der Anwendung geregelt.

In der Baumstruktur des ODFDOM-Modells sind diese Ebenen dann mit jeweils zugehörigen Elementen bzw. Java-Klassen besetzt:

 

ODFDOM Klassenmodell

ODFDOM Klassenmodell

Posted in Im Lauf der Zeit | Tagged , , | 1 Comment