Layout eines Buch-Monsters in TeX/LaTeX

In 2018 durfte ich ein faszinierendes Buchprojekt begleiten – die Übersetzung eines 900-Seiten-Wälzers zum Themenkomplex Deep Learning, und zwar als Setzer im Textsatzsystem LaTeX. Wenn Sie ebenfalls großes in LaTeX vorhaben, oder von anderen Autoren LaTeX-Quellen übernehmen, dann ist dieser Beitrag für Sie, und auch wenn Sie ein Projekt auf einer bestehenden Basis durchführen.

Deep Learning

Es geht konkret um das Buch Deep Learning. Das umfassende Handbuch: Grundlagen, aktuelle Verfahren und Algorithmen, neue Forschungsansätze von Ian Goodfellow, Yoshua Bengio und Aaron Courville, erschienen im mitp Verlag.

Als die Lektorin auf mich zukam, weil wir ja seit vielen Jahren das LaTeX-Buch haben, vermutete ich ein kompliziertes, aber einfaches Vorgehen. Dem war nicht so. Was ich lernte, waren nicht nur technische Irrungen und Wirrungen, sondern auch ich alles beim Zusammenarbeiten an Dokumenten alles falsch machen kann.

Das Fazit für alle Nicht-LaTeX-Nutzer gibt’s am Ende dieses Beitrags.

Das Technische Zeugs

Kompilierfähig machen

Das komplexe am Satz war, dass keiner der Übersetzer oder Fachkorrektoren selbst LaTeX verwendete. So änderten diese also im Quellcode änderten, ohne selbst überprüfen zu können, ob das Dokument dann noch funktioniert. Da LaTeX letztlich eine Programmiersprache ist, klappt die Generierung von PDF nicht mehr, sobald irgendwo eine geschweifte Klammer fehlt.

Deshalb erster Schritt, und auch zwischendrin immer wieder notwendig: Übersetzungsfähigkeit herstellen: Fehlermuster ansehen und mit Suchen/Ersetzen beheben. Dabei hilft es ungemein, einen Editor zu benutzen, der auch reguläre Ausdrücke versteht.

Beispiel: Nach \newterm fehlte meist die öffnende geschweifte Klammer, manchmal mit, manchmal ohne Leerzeichen. Lösung: Suchen/ersetzen mit regulärem Ausdruck, der das toleriert.

Layoutbesonderheiten entfernen

In einem bestimmten Satzspiegel in der bestimmten Sprache wollte der Autor oder Setzer einen ganz bestimmten Effekt erzeugen und schrieb deshalb Steuerbefehle ins Manuskript. In der Übersetzung müssen die alle raus, weil ja alles anders rauskommt.

• Befehle wie \break, \enlargethispage, \clearpage, \pagebreak, \newline, \setcounter usw. müssen alle weg. Manuelle Seitenumbrüche treten nicht nur mit den Befehlen auf, die man gemeinhin erwartet, sondern auch dank geschickt eingefügter Leerzeilenbefehle. Die müssen zunächst alle raus.
• Gleitobjekte, also Abbildungen, Tabellen haben oft Platzierungseinschränkungen, die natürlich für die Übersetzung nicht mehr sinnvoll sind, also auch hier global Suchen/Ersetzen.
• Nicht alle Dokumentklassen kennen das Konzept von Vakatseiten, das sind Leerseiten vor dem nachfolgenden Kapitel, so dass Autoren diese mit absonderlichen Konstrukten nachbildeten. Auch das musste raus. KOMAscript kann das, da ich das nicht hatte, half das Paket emptypage.

Sprachbesonderheiten

Das ist sinnvoll so spät wie möglich durchzuführen, weil Fach- und Sprachkorrektoren sich nicht daran halten (können). Hier habe ich den Fehler gemacht, diese zu früh durchzuführen mit der Folge, dass ich es mehrfach tun musste.

• In deutschsprachigen LaTeX-Quellen ist der Bindestrich bei verbundenen Nomen nicht das Zeichen -, sondern die Zeichenkombination "=. Das einfache - verbietet nämlich die Silbentrennung in den angrenzenden Wörtern, und das wollen wir nicht. Also auch hier Suchen/Ersetzen mit regulärem Ausdruck. Aber – und das musste ich dann wieder reparieren – nicht in Kommentaren oder englischem Originaltext.
• Index sauber ziehen. Indexeinträge enthalten oft ein „siehe“. Der Code dafür lautet aber eben |see{Verweis}, und das ist zu korrigieren. Umlaute im Index können Probleme machen, also auch hier genau nachsehen. Das Paket sanitize-umlaut hilft hier sehr weiter.
• Silbentrennungen kann LaTeX prinizpiell selbst, trennt aber eben an allen erlaubten Stellen. In unserem Fall wollte die Lektorin bei vielen Wörtern aber nur die Trennstellen zulassen, die im Duden als empfohlen angegeben werden. Diese Wörter sind freilich auf keinen Fall einzeln bei ihrem Auftreten zu korrigieren, sondern zentral am Anfang des Dokuments mit \hyphenation{}.

Code sauber machen

Oft stehen Leerzeichen da, wo keine hingehören und keine dort, wo welche sein sollten. Nach Formatierungsbefehlen etwa muss ein Leerzeichen stehen, sonst fehlt es später. Nach Indexeinträgen darf keines stehen, weil sonst im ungünstigen Fall sowohl das vor dem Indexeintrag und das danach gesetzt werden. Wenn aber der Indexeintrag im Satz steht, muss entweder davor oder danach ein Leerzeichen stehen, weil sonst zwei Wörter zusammengepappt werden. Vor einem Indexeintrag darf kein Leerzeichen stehen aus demselben Grund. Auch hier gilt: Reguläre Ausdrücke suchen/ersetzen.

Je nachdem, wann Autoren mit LaTeX begonnen haben, finden sich sehr interessante Verwendungen von mathematischen Gleichungsumgebungen und Mathe-Befehlen. Um ein ordentliches Erscheinungsbild zu gewährleisten, müssen diese Umgebungen manchmal global ersetzt werden: Tiefstellung funktioniert im englischen wunderbar mit x_i, das bricht jedoch, wenn ich die europäische Zeichenkodierung verwende, dann muss es x_{i} heißen. Hier gilt jedoch: Aufpassen beim regulären Ausdruck, ich dachte ich hätte alles korrekt ersetzt, habe aber ganz viele Literaturverweise zerstört, die auch zufälligerweise in der Art my_ideal_reference benannt waren. Selbiges gilt für die Hochstellung.

Literaturangaben und Verweise korrigieren

Will der Verlag ein anderes Zitierschema, oder das originale passt nicht auf die Sprache, heißt es Hand anlegen und Zitierbefehle prüfen und gegebenenfalls ersetzen.

In unserem Fall waren alle Zitierbefehle zu ersetzen, und zwar je nach Kontext. Auch hier brachte Suchen/Ersetzen mit Regular Expressions wiederum eine Linderung des Problems.

Versionierung mit Git

Wie in meinem Artikel Git für LaTeX empfohlen, lege ich alle Dateien in der Versionsverwaltung Git ab, damit ich jederzeit auf einen alten Stand zurückgreifen kann, und auch parallele Zweige zum Ausprobieren nutzen kann, ohne etwas an bereits funktionierenden Dokumenten schwer reversibel verändern zu müssen.

Leider konnte ich die Lektoren und Korrektoren nicht davon überzeugen, selbst auch mit Git zu arbeiten, so dass ich selbst Branches, also Verzweigungen, anlegte, wenn ich mal wieder den Satz an Dateien mit eingeflochtenen Korrekturen bekam. Da ich ja in der Zeit oft daran selbst weiter gearbeitet hatte, musste ich dann beim Mergen, der Zusammenführung von Branches, bisweilen händisch Konflikte auflösen.

Deshalb die Empfehlung: Wenn parallel gearbeitet werden soll, unbedingt darauf bestehen, dass alle Beteiligten die Versionsverwaltung nutzen.

Oder, alternative Möglichkeit, erst mit den Feinheiten abseits der Kompilierfähigkeit beginnen, wenn sich nichts mehr ändert.

Makefile nutzen

Mag es tools wie texify und ähnliches geben, die auch alle bestimmt gut sind: Für mich ganz persönlich ist nach wie vor ein Makefile das Mittel der Wahl, weil ich hier sehr weit in die Aufrufparameter eingreifen und Abhängigkeiten gut modellieren kann.

In diesem Falle habe ich gar kaum Abhängigkeiten zwischen Dateien modelliert, sondern nur Aufrufe. Auch das Vorbereiten eines neuen Datei-Stands für die Lektoren läuft über das Makefile.

Setze dann ordentlich

Schriften wählen. Satzspiegel wählen. Gleich an optischen Randausgleich denken.

…aber nicht zu früh.

In unserem Fall war ein explizites Kerning notwendig, da das große V und W nach einem Bindestrich zu viel Platz hatte. Ein kleines Makro und das einfügen diesen per Suchen/Ersetzen vollbrachte optische Wunder. Da ich das zu früh einbaute, musste ich dieses Suchen/Ersetzen öfter durchführen, ebenso wie viele Korrekturen in Sachen Klammersetzung, Leerstellen und so weiter.

Neues Layout

Grafiken, die im originalen Satz gut gepasst haben, sind vielleicht für den neuen Satzspiegel zu groß, so dass sie entweder gar nicht auf die Seite passen, oder die umfangreiche Bildunterschrift nicht mehr Platz findet. Hier ist im Einzelfall Abhilfe zu schaffen. In unserem Fall musste ich auf einigen Seiten schlicht die Seitenzahl unten weg lassen. Das alles wäre kein großer Act gewesen, hätte ich nicht frühzeitig akzeptiert, die ursprüngliche Dokumentklasse bestehen zu lassen und diese anzupassen, statt auf KOMAscript zu wechseln. So musste das Paket floatpag herhalten.

• 

• 

Die Mühen und Wehen, die das Patchen und Drumherumarbeiten in der originalen Dokumentklasse verursachte, hätte ich mir auf jeden Fall sparen können, hätte ich auf die von mir für den Verlag geschriebenen Klasse gewechselt.

Ebook als EPUB

Ich habe verschiedene Varianten, aus LaTeX ein Ebook im Format EPUB zu erschaffen, angesehen, und mit letztlich für tex4ebook entschieden, dass das von mir favorisierte TeX4ht verwendet.

Trotzdem war es ein ziemlicher Schlauch, bis alles gut lief.

Denn viele Pakete und Befehle, die mit pdfLaTeX problemlos durchlaufen, vertragen sich nicht mit TeX4ht. Hier hilft nur die Fallunterscheidung mit \ifdefined\HCode und damit dem Stummschalten einiger Pakete und Makros.

Komplett abgeschalten habe ich beispielsweise die Indexierung, aber natürlich auch Befehle die sich auf Satz von Seitenzahlen für Gleitobjektseiten beziehen, alles, was sich auf Kopfzeilen bezieht, und vieles mehr. Die Codierung von Ein- und Ausgabe mit UTF-8 muss auch heute noch explizit angegeben werden

TeX4ht ist sehr kritisch, was Sauberkeit von Code angeht. So bricht es beispielsweise für Abbildungen, die zu lange Bildunterschriften haben, weil im HTML-Code das title-Tag auf den Abbildungsunterschrift gesetzt wird. Also gilt es, für alle langen Abbildungsunterschriften auch noch kurze als Alternative anzugeben: \caption[kurz]{lang}. Das geht auch tatsächlich nicht automatisch, sondern nur durch intelligentes Durchhangeln.

Auch ist TeX4ht kritisch, was Mathematikumgebungen angeht. Läuft das leider immer noch von Autoren verwendete \[ \] problemlos mit pdfLaTeX durch, möchte TeX4ht das korrekte \begin{equation} \end{equation} haben. Auch andere Hacks in Gleichungen, wie das manuelle Anpassen von Zeilenvorschüben etc., nimmt TeX4ht nicht an.

Einen großen Diskussionspunkt hatten wir dann natürlich über der Frage, wie Gleichungen im EPUB dargestellt werden sollten, und welches EPUB-Format das richtige wäre.

Mein favorisierter Ansatz, EPUB3 mit der MathML-Darstellung von Mathematik zu generieren, kam nicht durch, weil viele Ebook-Reader eben noch nicht mit EPUB3 oder MathML umgehen können. Auch eine vektorbasierte Darstellung von Mathematik als SVG unterstützen leider nicht alle verbreiteten Lesegeräte, so dass wir uns dann doch auf das alte und nicht allzu schöne EPUB2 mit eingebundenen Grafiken verständigten, das dafür überall funktioniert. Das ist insofern tragisch, weil es bedeutet, dass zusätzliche 5000 Bitmap-Dateien generiert werden müssen, was die Generierungszeit für das Ebook auf knapp zwei Stunden hebt.

• 

• 

• 

Während das Paket cleveref wunderbare Ergebnisse mit pdfLaTeX produziert, zickt es mit TeX4ht herum. Als einzige Alternative, saubere automatisch benannte Querverweise zu bekommen, funktioniert das autoref-Paket aus der hyperref-Sammlung, das leider weniger mächtig als cleveref ist. So musste ich Verweise bzw. Verweisnamen auf mehrere Anker händisch nachpflegen.

Um valides EPUB zu erhalten, waren in unserem Fall noch einige Ersetzungen nach der Generierung nötig. Dank tex4ebook, das wiederum make4ht verwendet, können diese Ersetzungen direkt in den Prozess automatisiert eingebunden werden. So sind beispielsweise Parameter wie cellspacing, cellpadding nicht erlaubt, aber auch das geschützte Leerzeichen mit   kennt EPUB nicht. Ebenso weist CSS in EPUB einige Beschränkungen auf. Diese umgehe ich automatisch mittels Weiterverarbeitung.

Einige aus mehreren Grafikdateien zusammengesetzte Grafiken, die im PDF noch sauber aussahen, wurden im EPUB je nach Lesegerät ganz schrecklich falsch umbrochen oder eben gar nicht. Hier war noch an einigen Stellen Hand anzulegen, jeweils direkt an die einzelne Grafik. Automatisch ging hier nichts. Einige zusammengesetzte Grafiken musste ich schließlich als Gesamtes nochmal exportieren und direkt als Bitmap einbinden.

Kapitel- und Abschnittsüberschriften, die ein mathematisches Symbol beinhalten, brauchen auch wieder ihre textuelle Alternative, da sonst die Generierung von HTML-Inhaltsverzeichnis fehl schlägt, aber eben nur, wenn das EPUB generiert wird.

Einige Kopfstände erforderte das Inhaltsverzeichnis, da bei Verwendung von \part hier je nach Konfiguration die Nummerierung nicht mehr stimmt, da eine einfache HTML-Abzählliste generiert wird, die natürlich nach jedem Teil die Kapitelnummerierung neu beginnt, während sie im Original durchläuft. Die Lösung war letztlich, komplett das Format EPUB2 statt EPUB3 zu generieren.

Postprocessing im EPUB-Editor Sigil war für einige Dinge dennoch erforderlich. So wurde die Titelgrafik nicht korrekt eingebunden, was invalides bzw. falsch dargestelltes EPUB zur Folge hatte.

In Apple iBooks klappte zudem die Darstellung von mathematischen Gleichungen und Symbolen innerhalb von Fußnoten nicht. Hier musste fallweise ein CSS-Trick helfen, der der eingebundenen Grafik selbige auch noch als Hintergrundgrafik zuweist. Einem <img src="../Images/B10251_Book3356x.png" class="math"/> fügte ich jeweils manuell noch ein style="background-image: url('../Images/B10251_Book3356x.png')" hinzu.

Auch habe ich das Inhaltsverzeichnis nachträglich nochmal neu generiert.

Fazit und 4 Empfehlungen für jegliches Projekt

Fazit: Ohne den Editor EMACS wäre ich wahnsinnig geworden, die Features, die dieser mächtige Editor für LaTeX bietet, lindern viele Nöte. Wenn Sie sich nicht als Nerd sehen, dann ist das jedoch wahrscheinlich nicht der richtige Editor für Sie.

Was ich in diesem Projekt falsch gemacht habe, was mir andererseits als Lerneinheit auch für andere Projekte nutzt, ist dies:

1. Nur weil eine Aufgabe bereits durchgeführt werden kann heißt das nicht, dass es sinnvoll ist, dies bereits zu tun. Besser prüfen, ob der Arbeitsschritt durch nachfolgende Schritte noch mehrmals notwendig werden kann.
2. Auch ein gutes Versionierungssystem bringt nicht mehrere Zweige ohne manuellen Aufwand zusammen. Besser wir schwören vorab alle Beteiligten auf dasselbe System der Bearbeitung ein.
3. Wenn wir uns nicht explizit darüber unterhalten, in welcher Phase sich das Projekt gerade befindet, werden Missverständnisse zu Doppelarbeit führen. Spreche die sinnvolle Reihenfolge vorher ab.
4. Unterschätze nie die verborgenen Probleme einer Plattform, die du nicht einmal bis ganz unten geprüft hast. Es wird etwas drin sein. Wenn möglich, führe das Problem auf ein bekanntes zurück.

Insgesamt eine sehr interessante Erfahrung, die ich in in derselben Weise jedoch nicht unbedingt trachte zu wiederholen. Deshalb machen wir das nächste derartige Projekt sauberer, besser geplant.

Seiten: 1 2