Was passiert, wenn man ein mit OpenOffice erzeugtes ODT-Dokument durch Textverarbeitungen wie Abiword, Writely und KWord jagt? Sehen Sie selbst.

Jahre hat es gedauert, nun rückt er in greifbare Nähe: der offene Standard für den Austausch von Office-Dokumenten zwischen verschiedenen Betriebssystemen. Das Open-Document-Format (ODF) basiert auf XML. Mit ihm transportieren Sie ein Textdokument (ODT), eine Zeichnung (ODG), eine Präsentation (ODP), ein Diagramm (ODC) oder andere Formate verlustfrei von OpenOffice nach Writely oder von KWord nach Abiword – so jedenfalls die Theorie. Tatsächlich unterstützen Textverarbeitungen das offene Format bisher nur mäßig, die Implementierung des sehr umfangreichen Standards ist noch im Gange. Die Stichprobe mit einem Text im ODT-Format zeigt, ob ODF bereits für den Praxiseinsatz taugt.

Eine kurze Geschichte des ODF

Entwickelt hat den Standard ein technisches Komitee, das auf die Abkürzung OASIS [1] (Organization for the Advancement of Structured Information Standards) hört. Es nutzte zwar das XML-Format von OpenOffice als Vorlage für die Spezifikation, fügte dem Modell allerdings über 100 Änderungen hinzu, erweiterte es um zusätzliche Fähigkeiten und unterzog es ausgiebigen Tests. Ein Jahr lang begutachteten OASIS-Experten die Spezifikation, dann gab es eine einmonatige öffentliche Testphase, und schließlich stimmten sämtliche OASIS-Mitglieder – sie repräsentieren rund 600 Organisationen – über den Standard ab. Der als OpenDocument 1.0 bezeichnete Standard basiert also auf einem recht breiten Konsens und steht kurz davor, als ISO/IEC 26300 auch internationale Weihen zu erfahren.

ODF in der Praxis

Unser Referenzdokument [2] haben wir mit einer Debian-Version von OpenOffice Witer 2.0.3 erstellt. Es bringt ein paar Schikanen mit, um die getesteten Programme ins Schwitzen zu bringen (siehe Kasten “Das Testdokument”).

Die Entscheidung für OpenOffice Writer als Referenzprogramm fiel aufgrund der Tatsache, dass sich die Entwickler des Open-Document-Standards bei OpenOffice bedienten und die Suite trotz Schwächen offensichtlich mehr ODF-Features unterstützt als andere freie Büroprogramme. Das bekräftigte auch ein Vortrag von Lotzi Boloni und Waldo Bastian auf der diesjährigen KDE-Entwicklerkonferenz Akademy. Ein mit der ODF-Spezifikation erstelltes Dokument wurde in OpenOffice 2.0.1 und KOffice 1.5.2 geöffnet. Es zeigte sich [3], dass keines der beiden Programme die Spezifikation vollständig erfüllt, aber OpenOffice die Funktionen tendenziell besser unterstützte als KOffice.

Implementierungen

Wir öffnen das Textdokument im Test mit Abiword [4], KWord [5] und Googles Writely [6]. Letzteres ist dabei, weil zunehmend auch Online-Editoren ODF unterstützen. Der Vorteil solcher Programme besteht darin, dass Sie via Internet ortsunabhängig an Ihrem Dokument arbeiten. Sie brauchen lediglich einen Rechner mit Internetzugang und einen Browser, um die Online-Textverarbeitung zu nutzen – sensible Daten sollten Sie allerdings auf diesem Weg nicht bearbeiten.

Wir öffnen das Referenzdokument von OpenOffice Writer in den jeweiligen Anwendungen und vergleichen anschließend die Resultate. Dann speichern wir das Dokument im ODT-Format des jeweiligen Programms und öffnen es erneut in OpenOffice, um Änderungen zu erkennen.

Abbildung 1: Ein ODT-Dokument enthält verschiedene XML-Dateien, die Sie über das Kommando “unzip” zu Tage fördern und mit einem Editor begutachten.

Abiword

Wie knacken nun die Textverarbeitungen diese Nuss? Allen voran geht Abiword: Das Schreibprogramm steht seit kurzem in Version 2.4.5 als Autopackage bereit und blickt laut Changelog auf zahlreiche Bugfixes im Bereich ODF-Support zurück. Unbeeindruckt davon zerlegt die Software das Testdokument fachgerecht in Einzelteile (Abbildung 2).

Abbildung 2: Abiword in Aktion: Die Ähnlichkeit mit dem Original besticht nicht gerade, besonders was die Position der Elemente und die Farben angeht.

Die Kopfzeile gibt es noch, auch ihre Schriftart und -größe stimmen. Sie klebt jedoch am obersten Rand des Dokuments. Es folgt der Rahmen mit der Überschrift: Abiword wählt Times New Roman obwohl es die Schriftart Bitstream Vera Serif mitbringt und hinterlegt lediglich die Buchstaben grau. Der restliche Hintergrund im Rahmen bleibt weiß. Das Bild befindet sich zwar auf der richtigen Seite, überlagert aber den Rahmen. Hinter dem Bild bricht der Fließtext um, der Abstand zwischen Text und Bild fehlt. Die drei Elemente Rahmen, Bild und Fließtext überlagern sich also, wobei letzterer nach oben rutscht.

Die fett gedruckten Worte im Fließtext haben die Verwandlung ebenso überlebt wie die Fußnoten, dafür fehlt die Trennlinie komplett. Auch den Spaltentext erwischt es: Ein Umbruch in der linken Spalte sorgt dafür, dass diese leer bleibt. Ihr folgt – in der korrekten Schriftart und in Blocksatz formatiert – der Text, der mit den zwei richtig formatierten Tabellen endet. Im Text sehen Sie aber drei weiße Lücken: Hier schreibt Abiword weiße Schrift auf einen weißen Hintergrund – ein Sieg für die Steganografie, leider schlecht lesbar. Die Fußnotentexte kleben direkt hinter der jeweiligen Zahl, die Seitenzahl in der Fußzeile verschwindet beim Ausdrucken des Dokuments, weil sie außerhalb des Druckbereichs liegt.

Überdruck

Apropos Drucken: Der Ausdruck sieht noch einmal etwas anders aus. So erscheinen – anders als am Bildschirm – pixelgroße Abstände und Überlappungen zwischen den Zellen der Tabellen. Im Kasten taucht statt der weißen Fläche der Fließtext im Hintergrund auf. Das Bild ersetzt der Drucker wahllos durch ein schwarzes oder ein weißes Quadrat.

Speichern Sie das Dokument nun als ODT mit Abiword und öffnen es dann in OpenOffice, erleben Sie eine weitere Überraschung: Es gibt wieder eine neue Version (Abbildung 3).

Abbildung 3: Siehe da: Nach dem Speichern des Dokuments in Abiword und dem erneuten Öffnen in OpenOffice entsteht ein ganz neues Dokument.

Das Bild fehlt nun komplett, der Fließtext sitzt mit einem falschen Zeilenabstand an der richtigen Stelle, nämlich unterhalb des Rahmens. Der verfügt nun plötzlich über einen hellblauen und nicht mehr einen grauen Hintergrund. Die fett gedruckten Begriffe und Fußnoten stimmen, als Schriftart wählt OpenOffice Times New Roman wie in der Vorlage. Die Spalten existieren noch, allerdings mit einfachem Zeilenabstand. Von den Tabellen bleiben nur noch die Inhalte übrig: Farben und Linien fehlen ebenso wie die Seitenzahl am Fußende – alles in allem eine recht heftige Mutation.

KWord

KWord heißt die Textverarbeitung von KOffice, das ebenfalls seit einiger Zeit den ODF-Standard unterstützt. Auch dieses Programm legt das ODT-Dokument sehr eigen aus (Abbildung 4), allerdings erscheint das Ganze lesbarer als bei Abiword, da sich die Elemente nicht überlagern.

Es beginnt damit, dass KWord die Schriftarten und die Textausrichtung korrekt wiedergibt – zumindest fast. In der Kopfzeile, in der Überschrift und im Fließtext stimmt alles, im Spaltentext ersetzt KWord jedoch Arial durch eine Schriftart, die auf den lustigen Namen AR PL ShanHeiSun Uni hört. Kein Wunder: KWord bringt schlicht kein Arial mit und versucht daher, einen adäquaten Ersatz zu finden. Die Hintergrundfarbe im Kasten passt auch, dann aber verhaspelt sich die Software: Das Bild befindet sich links statt rechts, der Fließtext fließt nicht elegant darum herum, sondern eher unter der Grafik hinweg und der Text/Bild-Abstand fehlt.

Abbildung 4: KWord unterstützt ebenfalls seit einiger Zeit ODF, setzt aber noch nicht alle Möglichkeiten um, wie der Test zeigt.

Die vier fett gedruckten Worte finden sich ebenso im Fließtext wieder wie die Fußnoten: Allerdings beginnt KWord merkwürdigerweise mit Fußnote 0. Unter dem Fließtext fügt es tatsächlich eine Trennlinie ein, allerdings malt die Software einen überflüssigen Strich über den Fußnotenbereich. Die zweite Zeile in der Fußnote rückt KWord jeweils ein, was das Layout im Ernstfall verschiebt. Die Seitenzahl in der Fußzeile passt, allerdings fehlt rechts neben der Zahl ein Leerzeichen.

Der tiefer gelegte Fließtext verschiebt den Rest des Dokuments nach unten und damit auf die zweite Seite. Das Spaltenlayout verdient ohne Spalten den Namen nicht wirklich, dafür zeigt KWord die inversen Wörter richtig an. Abschließend folgen zwei Tabellen, die zwar die Farben korrekt darstellen, in denen es aber – wie bei Abiword – pixelgroße Abstände zwischen den Zellen gibt. Das größte Problem hat KWord offenbar mit der Kombination von Text und Bild.

Unter Druck

Drucktechnisch sieht die Sache schon freundlicher aus, WYSIWYG heißt hier die Devise: Was Sie sehen, bekommen Sie auch im Druck. Allerdings sehen die kleinen Abstände zwischen den Zellen der Tabelle auf dem Bildschirm etwas anders aus als beim fertigen Ausdruck.

Öffnen Sie das in KWord als ODT abgespeicherte Dokumente nun wieder in OpenOffice, offenbart sich auch hier ein neues Layout: Das ganze Dokument umfasst nun drei Seiten, von denen die erste leer bleibt. Bild und Kasten mit der Überschrift fehlen komplett, auf der zweiten Seite hält der Fließtext tapfer die Stellung – diesmal sogar mit der Fußnote 1 statt 0 – und auf der dritten Seite gibt es den ehemaligen Spaltentext noch immer ohne Spalten. Dafür expandieren die Tabellen über die komplette Seitenbreite.

Writely

Bleibt noch der Online-Kandidat Writely: Kommt er besser mit ODT zurecht? Nicht wirklich, aber Writely bleibt auch nicht hinter der Konkurrenz zurück. Eine Schwierigkeit im direkten Vergleich ergibt sich aber: Die Software stellt das Referenzdokument nicht im A4-Rahmen dar, sondern verteilt den Inhalt über die gesamte Breite des Bildschirms (Abbildung 5). Beim Drucken packt Writely indes den kompletten Inhalt auf eine Druckseite.

Abbildung 5: Writely steht nicht schlechter da als die Offline-Kollegen, zeigt allerdings die Elemente eher als HTML-Seite denn als Textdokument an.

Die Kopfzeile bekommt Writely richtig hin, setzt allerdings auf Schriftgröße 10 statt 9. Den Kasten stellt die Software zu schmal dar und malt lediglich den Raum hinter den Buchstaben grau an: Der Resthintergrund bleibt weiß. Als Ersatz für das nicht unterstützte Vera Bitstream Serif wählt Writely Times New Roman, verteilt dann aber neue Schriftgrößen. Die Überschrift schreibt es in Größe 36, dem Fließtext, der am Fuß des Kastens beginnt, weist es die Größe 10 zu. Die fett gedruckten Wörter und Fußnoten passen. Der Zeilenabstand stimmt, lässt sich aber nicht verändern. Auch die Trennlinie ist da, doch anstelle des Fließtextes umläuft der Spaltentext das Bild, besser gesagt, der ehemalige Spaltentext: Die Spalten fehlen komplett. Der Text schlängelt sich rechts am Bild vorbei – seitenverkehrt zum Original.

Schriftart und -ausrichtung stimmen, auch die inversen Wörter passen noch. Die Tabellen und ihre Inhalte zeigt Writely wie geplant, es hängt sie an den Fließtext und verwendet die richtigen Hintergrundfarben – allerdings erstrecken sie sich über die gesamte Seitenbreite. Fehlen bloß noch die Fußnoten: Für diese nutzt jedes Programm seinen eigenen Stil. Writely zeichnet sie blau und unterstrichen im klassischen HTML-Stil. Wie im Original beschließt die Seitenzahl in der Fußzeile das Dokument.

Speichern Sie das Dokument nun mit Writely im ODT-Format und öffnen es erneut in OpenOffice: Hurra, plötzlich kehren die Spalten zurück und die Tabelle positioniert sich wie im Original in der ganz rechten Spalte (Abbildung 6). Da der Spaltentext allerdings nur noch einzeilig läuft, füllt er nicht die gesamte Seite aus, zudem fehlt der Abstand zwischen den beiden Tabellen.

Abbildung 6: Öffnet man das als Writely-ODT gespeicherte Dokument wieder in OpenOffice kehren auf wundersame Weise die Spalten zurück.

Stille Post

Sicher kennen Sie das Spiel namens “Stille Post”: Jemand flüstert dem rechten Nachbarn einen Satz ins Ohr, der gibt ihn wiederum an den Nebenmann weiter und so geht es reihum. Der Letzte in der Kette spricht den Satz laut aus. Das ist meist lustig, weil der Satz komplett anders lautet. Ähnliches erlebt man zur Zeit mit ODF.

Obwohl die Entwickler mit Hochdruck an der ODF-Implementierung arbeiten, versprechen die Marketing-Leute zu viel: Zwischen ODF unterstützen und ODF beherrschen liegen Welten. Keine Anwendung gibt das Originaldokument korrekt wieder. Drucken Sie es, verändert sich das Layout; reimportieren Sie es, erscheint wiederum ein völlig neues Dokument.

Die gute Nachricht: Die Dokumente lassen sich öffnen, der Text bleibt unversehrt, für sehr einfache Dokumente genügt der ODF-Support. Im Idealfall soll das einheitliche Format jedoch ein 1-zu-1-Abbild eines Dokuments schaffen: Das klappt mit keinem der freien Programme – auch nicht bei OpenOffice. Es kippt zwar als Referenzprogramm aus der Wertung, der Test während der Akademy offenbarte hier jedoch ebenfalls Schwächen.

Wo aber liegen die Probleme? Zunächst integrieren die Entwickler den ODF-Support unterschiedlich schnell. So versucht sich Abiword zumindest an Spalten, während Writely und KWord das Feature komplett ignorieren. Ein konkreteres Probleme haben die Textverarbeitungen mit den Schriften: Fehlt Abiword eine Schriftart, verschiebt sich das Layout, sobald die Software sie ersetzt. Auch mit Bildern, Spalten und der Platzierung einzelner Bereiche kämpfen die Programme noch.

Nachdem eine Gruppe erfolgreich den Standard ODF entwickelt hat, braucht es jetzt wohl eine zweite Gruppe, die für eine einheitliche Implementierung sorgt. Inge Wallin – Marketing-Koordinator bei KOffice – fasste die Situation in einem Blog-Kommentar zusammen: Die volle Unterstützung von ODF sei ein Langzeit-Ziel. Beim großen Umfang des Standards nehme es wenig Wunder, wenn die Programme zwischenzeitlich inkompatibel blieben, so Wallins Schlussfolgerung. Also sollten Sie mit dem Austausch komplexer Dokumente noch etwas warten – es sei denn, Sie mögen “Stille Post”.