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, daß sie trotz ihrer Konzeption als freie Software genau jene Tücken eines WYSIWYG-Editors besitzt wie beispielsweise MS Word. Das hat allerdings – und das will ich hier betonen – nichts damit zu tun, daß 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 MS Word selbstverständlich zum Writer-Modul von LibreOffice (LO). Dieser Schritt schien mir als der einzig vernünftige, gilt LO 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, daß es einer Frechheit gleicht, sie über einen Versionsstatus von »1« hinausbefördert zu haben. Die Nutzung von »original« MS Office Word ist für mich von vornherein ausgeschlossen, vor allem weil man mit LO prima arbeiten kann, um ganz am Ende den Schritt zum Export ins unsägliche .doc-Format zu vollziehen.

Die Verwendung von LO bereitete mir anfangs Vergnügen. Vor allem die Eingabe umfangreicher Tabellen ist selbstverständlich viel einfacher als mit LaTeX-Quellcode. Lieblingsschriftarten wie Libertinus kann ich ebenso in LO 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, daß 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 LO, aus der man ebenfalls nach Eingabe seiner Quellen-Infos Zitate im Text als Feldbefehl und am Ende des Dokuments ein automatisch generiertes Literaturverzeichnis plazieren kann. Allerdings könnte dieses Literaturverzeichnis nur innerhalb der LO-Familie zur Anwendung kommen; außerdem wären Zitierstile nur schwer änderbar (dann doch lieber manuell angepaßte .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, daß diese oder jene Formatvorlage angewendet wird, daß 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 (hoffentlich) 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 Unermeßliche 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-Prozeß 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, daß 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 davorliegenden Absatzes an (das nicht unbedingt das Gleiche sein muß!); 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, daß 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 eingefaßt und liefen nicht über die Seitengrenzen hinaus, sondern verschwanden im »Nichts«.
• Mußten 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 LO 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, daß 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 mußte. – Und ich dachte, das hätte ich hinter mir gelassen, nach dem ich mich von MS Word abgewendet hatte… Möglicherweise würde dieses Problem umgehbar sein, wenn es eine Option gäbe, die bestehende Abbildung auszutauschen, sodaß das neue Bild exakt an die gleiche Stelle des alten Bildes verfrachtet wird, ohne daß 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, sodaß man gar nicht so recht weiß, welcher nun eigentlich der richtige Weg zu numerierten Kapiteln ist. Beides führt augenscheinlich zunächst zu numerierten Kapiteln bzw. Unterkapiteln. Später beobachtete ich aber, daß 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 muß 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, v.a., wenn man die Werkzeuge dazu hat. Daß 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 Quellcode-Datei (ca. ein halbes Jahr alt) 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, daß 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 immer brav beinahe die gesamte 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 mußte 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, daß ein paar nur wenige Monate veraltete Pakete dazu führen, daß ein Dokument nicht mehr darstellungsrichtig kompiliert wird? Für gewöhnlich wird ja die Meinung vertreten – und dies auch aus meiner Erfahrung abgeleitet – daß ein Quellcode beliebigen Alters stets das gleiche Dokument erzeugt!