Skurriles

In letzter Zeit habe ich neue Erkenntnisse im Umgang mit LibreOffice Writer (dem Textmodul der freien Office-Suite) gewinnen können. Ich stellte – zusammenfassend – fest, dass sie trotz ihrer Konzeption als freie Software genau jene Tücken eines WYSIWYG-Editors besitzt wie beispielsweise M$ Word. Das hat allerdings – und das will ich hier betonen – nichts damit zu tun, dass sie als freie Software geschrieben wurde und freie Software in den meisten Fällen proprietärer Software vorzuziehen ist. Sie zeigt ganz einfach aufgrund der Komplexität ihrer Struktur jene Schwächen, die mit einem Quellcode-basierten Text, wie er mittels LaTeX ausgewertet werden kann, vermieden würden.

Doch zunächst zum Anfang des Reports: Durch Kooperation mit Kollegen beim Verfassen eines wissenschaftlichen Artikels und letztlich der Zusammenarbeit mit einem der großen Verlage gezwungen, auf eine *.doc-Dateien produzierende Software zurückzugreifen, griff ich statt zu M$ Word selbstverständlich zum Writer-Modul von LibreOffice. Dieser Schritt schien mir als der einzig Vernünftige, gilt LibreOffice doch als sehr fortschrittliches, facettenreiches und in ständiger Weiterentwicklung befindliches Projekt gegenüber beispielsweise OpenOffice (das aufgrund seiner eigenartigen Lizenzierung abzulehnen ist) oder der Calligra-Suite, die für meine Begriffe so instabil arbeitet, dass es einer Frechheit gleicht, sie über einen Versionsstatus von »1« hinausbefördert zu haben. Die Nutzung von »original« (Achtung! Werbe-Slogan! ;) ) M$ Office Word ist für mich von vornherein ausgeschlossen, vor allem weil man mit LibreOffice prima arbeiten kann, um ganz am Ende den Schritt zum Export ins ätzende *.doc-Format zu vollziehen.

Die Verwendung von LibreOffice bereitete mir anfangs Vergnügen. Vor allem die Eingabe umfangreicher Tabellen ist selbstverständlich sehr viel einfacher als mit LaTeX-Quellcode. Schriftarten wie Libertine kann ich ebenso in LibreOffice verwenden, ebenso all die darin enthaltenen schön designten Sonderzeichen. Ich freundete mich mit Formatvorlagen an und legte sie mit Akribie fest. Ich verstand sogar zum ersten Mal das Einbringen von Feldbefehlen, die mir Abbildungsnummern an die richtige Stelle im Text setzen. Nachteilig befand ich zu dieser Zeit allein, dass die Literaturverwaltung von Hand erfolgt und man ständig zu kontrollieren hat, ob die im Text zitierten Quellen auch im Literaturverzeichnis auftauchen und anders herum. Mit etwas Konzentration kam ich da noch mit. Selbstverständlich kenne ich die integrierte »Literaturverwaltung« von LibreOffice, aus der man ebenfalls nach Eingabe seiner Quellen-Infos Zitate im Text als Feldbefehl und am Ende des Dokuments ein automatisch generiertes Literaturverzeichnis platzieren kann. Allerdings könnte dieses Literaturverzeichnis nur innerhalb der LibreOffice-Familie zur Anwendung kommen; außerdem wären Zitierstile nur schwer änderbar (dann doch lieber manuell angepasste *.bst-Dateien für LaTeX ;) ).

Nun aber zu den Dingen, die sich zunächst unbemerkt entwickelten und schließlich zum Horror wurden. Wie ich sagte, hat dieser kritische Beitrag nichts mit freier Software an sich zu tun (sie bezieht sich sogar nur auf das Writer-Modul!), sondern allein mit dem Konzept einer Software, die alles können will und – ganz nach dem Prinzip eines WYSIWYG-Editors – nur das Endergebnis anzeigt, nicht aber die Prozesse oder Befehle, die im Hintergrund ablaufen; jene Prozesse, die dazu führen, dass diese oder jene Formatvorlage angewendet wird, dass ein Wort kursiv erscheint oder von links 1,2 cm eingerückt wird. Solange es auf dem Bildschirm vernünftig aussah, hatte ich damit kein Problem, würde am Ende dem Verlag sowieso ein Dokument mit zerrissenem Layout übergeben, bei dem hin und wieder zwischen 1- und 1,5-zeiligen Zeilenabstand gewechselt wird; Absätze in ähnlich aussehender, aber doch verschiedener Schriftart erscheinen und auch noch um den Wert von 1 abweichende Schriftgrößen verbaut wurden. All das würde der Verlag ja letztlich korrigieren, bevor es gesetzt wird.

Nun aber zum Unvermeidlichen:

• Mit zunehmender Anzahl integrierter Bilder wächst (ganz nach meiner Erwartung) die Dokument- und damit Dateigröße ins Unermessliche an. Speichervorgänge dauern eben sehr viel länger, als würde bei Verwendung von LaTeX nur der Quellcode in eine reine Textdatei gespeichert werden. Wurden Abbildungen integriert, dauert deren Darstellung beim Scrollen: Fährt man über solche Seiten, dauert es einige Sekunden, bis das Bild aufgebaut wird, der Scroll-Prozess wird kurz gestockt (Ja, ich weiß, das hängt von der Performance des PCs ab sowie von der Auflösung der Abbildungen. Man bedenke aber, dass beim Verfassen eines LaTeX-Quellcodes mit einem Texteditor es überhaupt nicht zu Stockungen kommen kann!)
• Trotz penibler Beachtung der Absatzvorlagen, kam es immer wieder zu Verschiebungen und ungewollten Änderungen an den auf den Text angewendeten Formaten. Wurden Absätze kopiert und in einen anderen Abschnitt verschoben, nahmen sie das Format des davor liegenden Absatzes an (das nicht unbedingt das Gleiche sein muss!); beim Umstellen auf die ursprüngliche Absatzvorlage gab es plötzlich einen etwas größeren Leerraum unter dem Absatz als kurz zuvor. Selbstverständlich fällt so etwas einem geübten (und von LaTeX-Dokumenten verwöhntem) Auge sofort auf. Aber ich kenne keine Möglichkeit, tiefer in die Struktur Einsicht zu nehmen (nein, auch Steuerzeichen helfen da nicht weiter). Beim LaTeX-Code wäre der Fehler sofort gefunden: Am Ende des entsprechenden Absatzes hätte es entweder einen Code-Rest gegeben, der das Gesehene bewirkt, oder auch nicht.
• Wurden Absätze kopiert und unter einem bestehenden Bild mit Unterschrift eingefügt, konnte es dazu kommen, dass diese eigentlich für normalen Text gedachten Absätze in eine Art Rahmen der Abbildung gerutscht sind und daraus nicht mehr zu extrahieren waren. Sie waren beidseitig eingefasst und liefen nicht über die Seitengrenzen hinaus, sondern verschwanden im »Nichts«.
• Mussten Abbildungen geändert werden, die bereits im Dokument integriert gewesen sind, hat man die Bildquelle entsprechend geändert und neu ins Dokument eingefügt. Dafür wurde das bestehende Bild in LibreOffice Writer angewählt und gelöscht. Zurück blieb die nackte Bildunterschrift. Fügte man nun ein neues Bild ein, bekam diese eine neue Bildnummer zugewiesen, allerdings keinen Text, so wie man es von einem frisch eingefügten Bild erwarten würde. Das Kopieren des Textes der alten Bildunterschrift an die neue Position führte ausnahmslos dazu, dass im Text bereits verlinkte Bilder (Feldbefehle, die die Abbildungsnummer ausgaben) nun nicht mehr gefunden wurden und die Verlinkung von Neuem beginnen durfte bzw. von Hand einzeln korrigiert werden musste. – Und ich dachte, das hätte ich hinter mir gelassen, nach dem ich mich von M$ Word abgewendet hatte… Möglicherweise würde dieses Problem umgehbar sein, wenn es eine Option gäbe, die bestehende Abbildung auszutauschen, sodass das neue Bild exakt an die gleiche Stelle des alten Bildes verfrachtet wird, ohne dass eine Änderung an der Bildunterschrift erfolgt. Eine solche Funktion ist mir bei Writer allerdings nicht bekannt.
• Wer nicht wirklich verantwortungsvoll mit Gliederungsebenen umgeht, wird auch hier schnell an seine Grenzen stoßen: Gliederungspunkte lassen sich entweder über Extras|Kapitelnummerierung festlegen oder über die Änderung an einer Absatzvorlage selbst, Tab »Gliederung & Nummerierung«. Leider weichen auch beide Menüs in ihrem Aufbau und Bedienung voneinander ab, sodass man gar nicht so recht weiß, welcher nun eigentlich der richtige Weg zu nummerierten Kapiteln ist. Beides führt augenscheinlich zunächst zu nummerierten Kapiteln bzw. Unterkapiteln. Später beobachtete ich aber, dass ehemalige Unterkapitel mit einer Signatur z.B. »2.2« wieder zu »1.« innerhalb des 2. Kapitels »aufstiegen«, sobald man ein paar Absätze daraus ausschnitt und woanders wieder einfügte. (Dagegen sei die augenscheinliche Einfachheit eines LaTeX-Quellcodes erwähnt, wo Kapitel und Unterkapitel mit einem bestimmten Befehl gekennzeichnet werden, der nicht plötzlich »verschwindet«, sofern man den Code nicht absichtlich verändert!)

Für gewöhnlich bin ich ein sehr präziser Mensch und sehe Dinge nicht gerne unordentlich. Wo andere sich sagen: »Das Dokument muss nicht formatiert werden, weil diese Mühe am Ende beim Einreichen beim Verlag sowieso nicht gewürdigt wird.«, bin ich der Meinung, eine Struktur aufzubauen und einzuhalten, vor allem wenn man die Werkzeuge dazu hat. Dass dies trotz meiner Maßnahmen letztlich wieder zu einem uneinheitlich formatierten Dokument führt, finde ich beschämend und enttäuschend.

Es bleibt abzuwarten, wie sich die Dokumentstruktur in den nächsten Wochen der Bearbeitung weiter zerfleddert, obwohl ich das Dokument noch nicht einmal zu *.doc konvertiert habe (!) ! Wird die Datei zwischen den einzelnen Co-Autoren herumgereicht, dürfte es zu einer weiteren Fragmentierung kommen, wenn diese abwechselnd in *.odt, *.doc und *.docx speichern.

Heil, du mein geliebtes LaTeX! Was freue ich mich doch auf unser nächstes Projekt!

Kürzlich hatte ich ein kniffliges Problem mit meinem LaTeX-Quellcode – er ließ sich erstaunlicherweise nicht mehr fehlerfrei kompilieren! Es handelte sich um eine etwa ein halbes Jahr alte Quellcode-Datei von einer Präsentation für eine wissenschaftliche Tagung. Normalerweise behalte ich nie alle Meta-Daten des Kompiliervorganges, sondern nur den Quelltext (und ggf.. die separaten Bilder). Denn für gewöhnlich erzeugt das Kompilieren zu einem beliebigen Zeitpunkt stets das gleiche Dokument als PDF.

In diesem Fall wurde die Fußzeile der Präsentation zur Hälfte aus unbekannten Gründen überdeckt. Fehler oder Warnungen wurden keine ausgegeben. Egal, welche Einstellungen ich auch vornahm – immer wieder wurde die Fußzeile zur Hälfte mit einer weißen Fläche überdeckt. Die ganze erkenntnisreiche Geschichte kann man im GoLaTeX-Forum nachlesen.

Um eine Kurzfassung zu geben: Es hatte letztlich damit zu tun, dass meine Pakete für die beamer-Klasse als auch die für das verwendete libertine-Paket und andere teilweise total veraltet gewesen sind (dabei besonders hilfreich war der der Präambel vorangestellte Befehl \listfiles, der alle beim Kompilieren benutzten Pakete inklusive Versionsnummer in die .log-Datei schreibt). Dies konnte ich mir zunächst nicht erklären, installierte ich doch brav fast die ganze TeXLive-Distribution aus Ubuntus Paketquellen! – Sollten die nicht weitgehend aktuell sein? Auch das Einbinden der Entwickler-Backports führte zu keiner Aktualisierung, wie im Forum beschrieben wurde. Schließlich musste ich kapitulieren und TeXLive manuell installieren (was ich bis dahin noch nie gemacht hatte, vertraute ich doch stets auf die Aktualität von TeXLive aus den Repositories).

Nach manueller Installation von TeXLive und erfolgreichem Update auf die jeweils aktuellen Probleme war das Problem gelöst und das Dokument wurde wieder korrekt erstellt. Ein bitterer Nachgeschmack bleibt jedoch – wie kann es vorkommen, dass ein paar nur wenige Monate veraltete Pakete dazu führen, dass ein Dokument nicht mehr darstellungsrichtig kompiliert wird? Für gewöhnlich wird ja die Meinung vertreten – und dies auch aus meiner Erfahrung abgeleitet – dass ein Quellcode beliebigen Alters stets das gleiche Dokument erzeugt!