Im Dschungel von OpenOffice Writer

Alt-Enter in der ersten Zelle vor allem Content hilft.

In den meisten Fällen hilft es, mit F5 den Navigator zu starten, wenn er denn nicht ohnehin schon offen ist, zur entsprechenden Kategorie zu gehen und dort das Element doppelt anzuklicken. Bei 50 gleichen Elementen, die alle nur blabla-1 bis blabla-50 heißen, dauert es allerdings eine Weile, bis man das richtige gefunden hat. Und Pfeile oder andere Zeichenobjekte werden im Navigator gar nicht angezeigt.

Paragraphen, Überschriften werden also gut exportiert, bei Tabellen könnte man vielleicht versuchen, mit HTML tidy noch ein bisschen nachzubessern und ansonsten gibt es ja immer die Möglichkeit, einen eigenen XSLT Transformator zu schreiben. Oder man exportiert in DocBook und nutzt einen der unzähligen Transformatoren, die es für dieses Format schon gibt. Allerdings sieht es auf den ersten Blick so aus, als würden bei DocBook, die Links zu Bildern verloren gehen. Was ein bisschen merkwürdig ist, da das mit den Links bei HTML ja funktioniert.
Interessant und durchaus positiv ist, dass die Html Datei, Graphik-Dateien, die in der .odt Datei extern verlinkt sind, direkt verwendet. Dass die externen Graphiken also nicht dupliziert und mit nichts sagenden, sequentiell nummerierten Dateinamen versehen werden.

Ein einfaches Drag-and-Drop der Html-Datei funktioniert, allerdings sollte man direkt danach, auf die Seiten-Ansicht umstellen. Default ist nämlich die Web-Ansicht. Kommentare im HTML Source-Code werden zu Writer Kommentaren, was zwar eine nette Sache ist, aber meistens nicht das, was man will und bei mir zuerst mal die erstaunte Frage ausgelöst hat: "Wo kommt denn dieses blöde gelbe Rechteck her?".
Was ich nicht weiß, ist wie Writer mit @media print Anweisungen im Stylesheet Block umgeht. Zu wünschen wäre ja, dass er die gegenüber anderen etwaigen vorhandenen Format-Anweisungen für screen bevorzugt behandelt.

Der erste Schritt ist die .odt-Datei als Zip-Archiv zu öffnen. Die Struktur sieht dabei ungefähr so aus (die erste Spalte gibt übrigens die Dateigröße in Bytes an, je nach Dokument Inhalt kann es auch durchaus mal sein, dass die Bilder kleiner sind als der Text):

 --------  ---------------------------------------------
    55467  Pictures/1000000000000234000001C36BCCBC1C.png
    57517  Pictures/1000000000000234000001C3D532A03E.png
     5277  content.xml
 --------  ---------------------------------------------

Im internen Pictures Unterverzeichnis liegen die eingebetteten Bilder (das können .png oder .jpg Formate sein). Die Datei content.xml enthält den kompletten Text, die Textfelder und alles andere, was das Dokument ausmacht. In ihr muss man nach den Links zu den Bildern suchen.

Also extrahiert man zuerst alles, was im Pictures-Verzeichnis liegt, und versieht die Dateien, die sich dann auf der lokalen Festplatte befinden, vielleicht auch noch mit einem aussagekräftigeren Namen als diese sich doch sehr ähnelnden numerischen Bezeichner.
Die Datei content.xml wird ebenfalls extrahiert und dann mit einem brauchbaren Editor nach Textstellen mit .png oder Pictures/ durchsucht. So sollte man relativ schnell das xlink:href Attribut des Graphik-Tags finden, das geändert werden muss.

Bei externen Links gibt es die Möglichkeit entweder absolute oder relative Pfadangaben zu verwenden. So gut wie immer ist relativ die richtige Wahl.
Also:

relativ

xlink:href="../Pictures/neuerName.png"

absolut

xlink:href="/home/ich/Dokumente/Pictures/neuerName.png"

Es müssen wirklich zwei Punkte am Anfang vom relativen Pfad sein, auch wenn man damit im Dateisystem selber auf einer falschen (in den meisten Fällen nicht existierenden) Verzeichnisebene landen würde. Die doppelten Punkte sollen wohl sagen: "Aus dem Zip-Archive raus, in das Verzeichnis, wo die .odt Datei liegt, und dann von dort relativ in das Unterverzeichnis weiter."

Jetzt kommt der kritische Teil, denn jetzt werden die Änderungen ins Zip-Archiv zurückgeschrieben. Also ist auf jeden Fall sicher zu stellen, dass die .odt Datei in Writer nicht mehr geöffnet ist, dann packt man die modifizierte content.xml wieder ins Archiv und sollte sinnigerweise auch die "100000000000023400.png" Dateien im Pictures Unterverzeichnis im Zip-Archiv löschen. Oder vielleicht erst, nachdem man die modifizierte .odt Datei im Writer geöffnet hat und sich bei den Bild-Eigenschaften überzeugt hat, dass das Bild jetzt tatsächlich nach extern verlinkt ist und nicht direkt eingebunden. Und natürlich sollte das Bild auch angezeigt werden, und nicht nur ein Rahmen mit einer Meldung, dass eine Datei nicht gefunden werden kann.

In den neuen OpenOffice Versionen kann man sich das Löschen sparen. Denn da erkennt Writer selber, dass diese .png Datei im internen Pictures-Verzeichnis nicht genutzt wird und entfernt sie von alleine.

Und seit Release 3.0 kann man sich den ganzen Aufwand sparen. Denn da wurde das Kontextmenü einer Graphik um einen extra Eintrag erweitert, der es erlaubt, eingebettete Graphiken, als externe Datei zu speichern. Wobei das allerdings nur die halbe Miete ist, denn im Open-Office Dokument selber ist die Graphik weiterhin eingebettet und man müsste immer noch die alte Graphik löschen und eine neue, die mit einem Link zur externen Datei arbeitet, einfügen.

Wer mit dem Umgang mit Makros vertraut ist, kann auch ein Makro Extract graphics out of an existing writer document nutzen, das auf der Code-Snippets Seite von OpenOffice zu haben ist. Das extrahiert auch die Bilder und passt die Graphic-Tags im Dokument so an, dass sie als Link zu den Bilddateien im Filesystem fungieren.

Die "offiziell" empfohlene Variante ist die, das Master-Dokument und später dann die Sub-Dokumente alle von der gleichen Vorlage ausgehend zu erstellen. Das hört sich gut an und ist auch richtig gut implementiert, weil das Master-Dokument neue Stil-Vorlagen, die man beim Editieren und Erweitern der Sub-Dokumente -- und nur die kann man editieren -- angelegt hat, nach einem "Links aktualisieren" brav übernimmt.
Knifflig wird das beim typischen Fall einer Diplomarbeit: Einleitung und Theorie-Teil sind fertig und ich komme zum praktischen Teil mit Messungen, Ergebnissen und Auswertungen. Jetzt brauche ich eine Tabelle in einer 4 spaltigen Darstellung. In den vorangehenden Teilen -- und schon gar nicht beim anfänglichen Erstellen der Formatvorlage -- hat man das natürlich nicht voraussehen können. Also lege ich eine extra Stil-Vorlage für diesen Typ von Tabelle in meinem 3. Sub-Dokument mit den Messungen an, und ich bin mir ziemlich sicher, dass ich diesen Typ auch in den nächsten Kapitel mit den Ergebnissen wieder brauchen werde.

Da ja alle Stilformate vom Sub-Dokument ins Master-Dokument übernommen werden, mache ich mir keine Gedanken und lege im Navigator des Master-Dokuments einfach ein neues Sub-Dokument für das Kapitel mit den Ergebnissen an. Aber das neue Dokument hat die Stil-Vorlage für den neuen Tabellen-Typ nicht. Das Naheliegende passiert nämlich nicht: Obwohl aus dem Master-Dokument heraus angelegt, hat das neue Subdokument nicht die aktuellen Formatvorlagen des Master-Dokuments, sondern bestenfalls die alten, unter Umständen aber auch nur die Formate aus dem Template, was systemweit als Standard festgelegt ist.

Nicht weiter schlimm, denke ich mir. Ich kann ja einfach das Master-Dokument als Template speichern, da sind ja alle Stile drin. Die von Kapitel 1 und 2 und auch die neuen vom Kapitel 3 mit den speziellen Tabellen. Eben nicht! Nur normale .odt Dateien lassen sich als Template abspeichern, mit .odm Dateien geht das nicht. Solange das weniger als eine Hand voll Formate sind, kann man die Formate auch noch einzeln kopieren. Dazu gibt es ein eigenes Interface zum Organisieren der Formatvorlagen in Dokumenten (da sind Master-Dokumente diesmal nicht ausgeschlossen) und Templates.

Die OpenOffice Entwickler sind davon ausgegangen, dass man von einem Template in ein Dokument Formate übernehmen will, oder umgekehrt. Jedenfalls ist die Starteinstellung so, dass links die Templates angezeigt werden und rechts die Dokumente. Das lässt sich aber leicht ändern und dann kann man selbst erstellte Stilvorlagen von einem Dokument zum anderen per Drag-and-Drop kopieren. Aber auch da ist der Standard gewöhnungsbedürftig: Ein einfaches Drag-and-Drop verschiebt nämlich das Format, das heißt es verschwindet aus dem ursprünglichen Dokument oder Template, was meiner Meinung nach vollkommen unsinnig ist, da Stile leichtgewichtige Objekte von noch nicht mal einem kByte sind und beim besten Willen keinen Platz wegfressen. Bis zur nächsten Usability-Umfrage, die diese Unart dann hoffentlich aus der Welt schafft, muss man beim Ziehen mit der Maus noch die Ctrl-Taste gedrückt halten, um zu kopieren.

Auf dem Wiki zu OpenOffice gibt es auch einen User Guide Working with Master Documents der sich mit dieser Thematik befasst. Allerdings lässt er einige der hier aufgezählten Fallstricke außen vor.

Eigentlich ist nichts einfacher als das: Beim Erstellen der Abschnitts-Überschrift oder der Bild-Unterschrift wird eine Referenz darauf angelegt und später, wenn darauf verwiesen werden soll, klickt man über das Menü "Insert Field" den entsprechenden Dialog auf, sucht sich bei den Referenzen die benötigte raus, und fügt sie durch einen Doppelklick an der aktuellen Stelle in den Text ein. Das war's.

Wenn die Referenzen über Subdokumente verteilt sind, klappt das allerdings nicht mehr. Dann wird nämlich das, was man auswählen will, nicht mehr in der Referenzliste des Dialogfelds angezeigt. Es bleibt nichts anderes übrig, als im Blindflug zu arbeiten und die Referenzmarken aus dem Gedächtnis oder von einem Zettel abgeschrieben per Hand in das Dialogfeld einzutippen. Bei Latex ist das ja auch nicht anders. Nur gaukelt einem dort kein graphischer Dialog vor, dass es eigentlich einfacher und eleganter gehen müsste. Sondern es gilt die einfache Abmachung zwischen Textsatzsystem und Autor von Anfang an: Such' dir einfache Labels für deine Textmarken aus, die du dir leicht merken kannst, so dass du später einfach und schnell darauf zugreifen kannst.

Doof ist auch, dass diese von Hand angelegten Cross-Referenzen, die Datei übergreifend arbeiten, innerhalb des Subdokuments nicht korrekt evaluiert werden. Das ist einleuchtend, da ein Subdokument per se nix von einem zweiten Subdokument (und erst recht nicht von dessen Referenz-Label) im selben Master-Dokument wissen kann. Nur das Master-Document weiß von beiden Subdokumenten und kann von daher die Referenzen richtig auflösen.

Als Workaround ist es angebracht, immer mal wieder aus dem Master Dokument per Export ein normales OpenOffice Text Dokument zu machen. Da sind dann die Inhalte aller Subdokumente tatsächlich in einer Datei und konsequenterweise zeigt dann der Navigator auch alle Objekte an, egal ob das Referenzmarken, Grafiken oder Überschriften sind.

Zuerst ist zu überprüfen, ob das Dokument überhaupt auf einem Template basiert. Das passiert in den Eigenschaften des Dokuments (File - Properties ..., oder bei deutschen Versionen Datei - Eigenschaften):

Beim erneuten Öffnen kommt dann allerdings eine sehr schwer zu verstehende Warnmeldung:

Keine Ahnung warum man da nicht "Styles from the template" sagen kann. Genau das jedenfalls ist mit "current styles" gemeint.

Mit ein paar Manipulationen direkt in den Dateien im Zip-Archiv lässt sich einer Datei auch noch nachträglich ein Template zuweisen. Die entsprechenden Anpassungen sind in der dankbar kleinen und übersichtlichen Datei meta.xml zu machen. Dort sollte es ein meta:template Tag geben:

<meta:template xlink:type="simple" xlink:href="../otherTemplate.ott" xlink:title="" ../>

xlink:href und xlink:title sind anzupassen. Ohne Title Attribut wird allerdings in den Datei-Eigenschaften nichts angezeigt. Und für den Link gilt mal wieder, dass die zwei Punkte entgegen allen bekannten Standards eben nicht aufs übergeordnete Verzeichnis verweisen, sondern aufs das aktuelle, in dem auch die .odt oder .odm Datei drin liegt.

Also wird mit F11 der Stylist aufgeklappt und nach Liste gesucht. Da gibt's eine ganze Menge: List 1, List 1 Cont., List 1 End, List 1 Start -- und das ganze auch noch mal für 2, 3, 4 und alle anderen Einrückungs- oder Hierarchie-Ebenen. List 1 ist die erste Wahl. Aber nachdem man dieses Format dem eigenen Text zugewiesen hat, ist der zwar eingerückt, aber von Aufzählungszeichen oder Bullets ist nichts zu sehen.

Ein Blick in die Formatvorlage zeigt erstmal eine etwas merkwürdige Voreinstellung: Ich brauche doch keinen hängenden Indent, sondern will allen Text gleich weit eingerückt haben, lediglich die Bullets sollen links raus stehen! So wie das in der folgenden HTML Liste zu sehen ist.

• Writer kennt zwei Styles für List 1, einen Paragraph Stil, der festlegt, wie der Text aussehen soll (Font, Zeilenabstand, ...)
• und einen List Stil, in dem definiert wird, wie die Aufzählungszeichen aussehen und wie sie positioniert sind.

Solange mir diese Unterscheidung der beiden Stilvorlagen nicht klar war, war die Arbeit mit Listen überaus frustrierend, weil ich eben letztendlich dann doch darauf zurückgefallen bin, die Bullets durch das entsprechende Symbolleisten-Icon zu erzeugen. Und das ergibt dann den unbeliebten Mix zwischen Text und Formatierung.
Die richtige Vorgehensweise ist, zwei Styles jeweils einen Paragraph Style und einen List Style anzulegen, den als Liste zu formatierenden Text zu selektieren und ihm den frisch definierten Paragraph-List Stil zuzuweisen. Zu diesem Zeitpunkt wird man noch keine oder nur minimale Veränderungen sehen, da der Paragraph Stil immer noch ein normaler Textblock Stil ist.

In einem zweiten Schritt wird das geändert, indem der Paragraph Stil modifiziert wird und zwar auf dem Tab "Numbering". Dort findet sich in der Auswahlbox "Numbering Type" alles, was im Stylist als List-Styles vorhanden ist, unter anderem auch die neue selbst definierte Stil-Vorlage "IndentedList". Wenn die selektiert und danach mit Okay die Format-Vorlagen Einstellung geschlossen wird, dann erhält auch der selektierte Text sofort die gewünschten Bullets. Außerdem ist damit auch der Paragraphen-List Style mit dem List-Style verknüpft, so dass in Zukunft durch ein Zuweisen der Paragraphen-Eigenschaft auch implizit, die Listen-Eigenschaften dem Text angehängt werden.

HTML und LaTeX unterstützen jeweils beide die "Description List" für solche Fälle, wobei HTML da ein bisschen inkonsequent ist, da dabei das Schlagwort auf eine eigene Zeile gesetzt wird. Das Schlagwort steht dann genau zwischen zwei Beschreibungen, was beim schnellen Überfliegen irritierend ist, da sich die zugehörige Beschreibung nicht so einfach zu ordnen lässt.

In Writer behilft man sich mit einem erweiterten Listenformat. Was ich vorher bemängelt habe, dass in der Standard-Einstellung die erste Zeile einer Liste einen negativen Einzug hat, wird jetzt ausgenutzt: Der Einzug, sowohl der positive für alle Zeilen, als auch der negative für die erste Zeile, wird synchron vergrößert, so dass er in etwa die Länge von einem typischen Schlagwort hat. Über 5 Zentimeter sollte man aber nicht hinausgehen, denn ab da sieht es dann sehr gewöhnungsbedürftig aus.
Gleichzeitig legt man einen Tabstop fest, der mit dem Einzug identisch ist. Den Text gibt man dann als Schlagwort, TAB, beschreibender Text ein. Das TAB sorgt dafür, dass zwischen Schlagwort und anschließendem Text genau so viel Platz gelassen wird, dass alle beschreibenden Zeilen gleich tief eingerückt sind.
Für das Schlagwort selber ist damit aber noch kein Formatierungsstil festgelegt. Das muss man leider noch für jedes Listen-Element selektieren und manuell als "Fett" formatieren. Und wenn ein Schlagwort tatsächlich mal so lang ist, dass es in den Text rein reicht, dann ist der Tabstop natürlich nicht mehr angebracht und es muss ein einfaches Leerzeichen als Trenner zum Text benutzt werden.