Fehlermeldungen

Während des Kompilierens kommt es gelegentlich zu unerklärlichen und rätselhaften Fehlermeldungen. Hier einige Ratschläge zu diesem Thema:

Die Grundregel lautet:

Selbst ein einziges fehlendes Zeichen, zum Beispiel eine fehlende geschweifte Klammer eines Makros, kann Hunderte von Fehler-Warnungen erzeugen. Und dies an den seltsamsten Stellen und unter den eigenartigsten Zeilennummern!

Doch wenn der Fehler nicht zu lokalisieren ist, was kann ich prüfen?

1. Letzte Änderung am Dokument checken. Wenn davor keine Fehlermeldungen beim Kompilieren kamen, kann er nur an dieser Stelle entstanden sein.
2. GNU/Linux-Betriebssysteme unterscheidet zwischen Groß- und Kleinschreibung von Dateinamen: Ist im Dokument Bild1.jpg verlinkt, aber die Datei heißt in Wirklichkeit Bild1.JPG?
3. Wurde das Makro eines Paketes verwendet, das gar nicht in der Präambel geladen ist?
4. Reihenfolge der Pakete: Manche Pakete vertragen sich nicht mit anderen, man sollte daher eine Reihenfolge einhalten (dieses oder jenes als letztes laden usw., siehe jeweilige Paket-Dokumentation). Nur ein Beispiel: das Paket caption muß schon relativ früh geladen werden, um Fehlermeldungen zu vermeiden, obwohl mit dem LaTeX-Code alles korrekt ist. Das Paket hyperref sollte möglichst immer als letztes geladen werden.
5. Verwendet man die Zeichencodierung utf8, wie ich es hier empfehle, kann eine Fehlermeldung beim Kompilieren erscheinen, wenn man Text per Copy-and-Paste aus fremden Quellen einfach in den LaTeX-Code einfügt. Möglicherweise enthält dieser jetzt ein Zeichen, das in der Unicode-Codierung nicht vorgesehen ist. Prinzipiell müßte man das betreffende Zeichen löschen und neu eintippen; praktisch ist es aber so, daß man das Zeichen nicht erkennt bzw. von einem »normal eingetippten« Zeichen nicht unterscheiden kann. Hilfreich ist folgender Kniff: Der Texteditor Atom bietet ein Plugin namens »highlight-bad-chars«. Öffnet man seinen Quellcode dann mit dem Atom-Editor, werden alle ungültigen Zeichen hervorgehoben und können gezielt gelöscht werden. Wer Unicode-Zeichen direkt eingeben möchte, nutzt besser XeTeX oder LuaTeX.
6. Modus des Kompilierens: Hat man aus Versehen den Kompilieren-Knopf auf dvi statt pdflatex gestellt und kompiliert erfolglos, weil man .jpg-Bilder integriert hat?
7. PDFs von Corel erzeugt: Ein skurriler Fehler namens »mainstream error« hat sich bei mir einmal ergeben, als ich eine mit CorelDRAW erzeugte PDF als Gleitobjekt eingebunden habe. Alle anderen PDF-Zeichnungen im Dokument hatte ich dagegen mit Inkscape erstellt. Ich habe also dieselbe, mit Corel entworfene Zeichnung noch einmal mit Inkscape angelegt, wieder als PDF exportiert und siehe da – der Fehler war weg!
8. Veraltete Pakete: Nicht mehr aktuelle Pakete können selbstverständlich auch zu Fehlern im kompilierten Dokument führen, wenn man sie zusammen mit solchen Paketen verwendet, die auf dem neuesten Stand sind. Um zu prüfen, welche Paket-Versionen beim Kompilieren zum Einsatz kommen, stelle man ein \listfiles der Präambel voran (also noch vor \documentclass) und beim Kompilieren werden die verwendeten Pakete mitsamt ihrer Versionsnummer ans Ende der erzeugten .log-Datei geschrieben. Die kann man dann mit einem Texteditor einsehen und ggf. aktualisieren. Hier beschreibe ich so ein Beispiel.
9. Je nach Editor wird nach dem Kompilieren eine Log-Datei angezeigt, aus der ersichtlich wird, in welcher Zeile die betreffende Warnung oder der Fehler zu suchen ist. Hin und wieder ergibt die angezeigte Zeilen-Nr. keinen Sinn, z.B. »1« (also die Zeile der \documentclass). Hier empfehle ich, das Dokument mit einem anderen TeX-Editor zu kompilieren, da dieser den Fehler ggf. »anders« oder »korrekt« anzeigt. Beispiel: Mit Kile wird Fehler in Zeile 1 angezeigt → nichts zu finden. Mit TeXMaker wird der Fehler in Zeile 43 angezeigt → dort sehe ich, daß eine Klammer fehlt.
10. Gelegentlich ist hilfreich, alle beim Kompilieren erzeugten Metadateien zu löschen, und das Kompilieren mit einer ganz jungfräulichen tex-Datei zu wiederholen. Möglicherweise enthalten die Meta-Dateien für Verweise fehlerhafte Einträge, die immer wieder ausgewertet werden, obwohl die Verweise gar nicht mehr existieren.
11. Häufig vergißt man, daß es unter LaTeX sog. reservierte Zeichen gibt, darunter das Prozent und den Unterstrich. Will man beide als reinen Text erzeugen, muß ihnen ein Escape-Zeichen vorangestellt werden (\% bzw. \_). Nun ist es so, daß man diese speziellen Ausdrücke gelegentlich vergißt oder im Quelltext überliest, weil sich % nun mal unauffälliger liest als \%. Im Falle von Prozent, Kaufmanns-Und (&) und anderen reservierten Zeichen wird im Editor normalerweise hervorgehoben, daß etwas nicht stimmt. Doch was ist mit Quellcode, den man sonst nicht sieht? Etwa die eingebundene .bib-Datei für die Literatur? Also auch dort sollte man prüfen, ob nicht einzelnstehende &, %, $, _ und all die anderen reservierten Zeichen ohne entsprechendes Escape-Zeichen davor gespeichert sind.

Kommt man einer skurrilen LaTeX-Fehlerwarnung trotz mehrfachen Durchsehens des Quellcodes nicht auf die Schliche, hat sich immer der folgende Kniff bewährt:

Man beendet vorzeitig das Dokument (d.h. mitten im Dokument) mit

und beobachtet, ob der Fehler immer noch auftritt. Tritt beim Kompilieren der gleiche Fehler immer noch auf, heißt das, daß sich die Quelle des Fehlers oberhalb vom testweise eingefügten \end{document} befindet. Tritt kein Fehler auf, weiß man, daß das Dokument bis hierher »sauber« ist und die Fehlerquelle erst irgendwo später im Dokument kommt. Auf diese Weise läßt sich die Fehlerquelle »eingrenzen«.

Gelegentlich kämpft man mit zahlreichen »overfull boxes«-Meldungen, d.h. der Blocksatz kann durch überlange Wörter oder nicht anwendbare Worttrennungsmuster nicht sauber hergestellt werden. Wörter ragen dann über das Zeilenende heraus. Beim Durchscrollen der erzeugten PDF-Datei sieht man die Übeltäter rasch, zumindest, wenn sie lang genug sind. Ragen die Wörter aber nur 1 oder 2 pt über das Zeilenende heraus, kann man zunächst nicht sehen und nachvollziehen, warum und wo es an dieser Stelle eine »overfull box« gibt. Abhilfe schafft die Option »draft«, die der Dokumentklasse zeitweilig hinzugefügt wird:

Nun werden im kompilierten PDF alle »overfull boxes« mit einem schwarzen Rechteck am Seitenrand gekennzeichnet und können einzeln durch Umstellungen im Satzbau oder manuelle Trennstellen korrigiert werden.

Wer das microtype-Paket nicht verwendet, sollte es spätestens jetzt tun! Damit erledigen sich die meisten box-Probleme. Unter XeTeX, das microtype nur unvollständig unterstützt, kann mit sich mit dem Befehl \sloppy am Dokumentanfang behelfen.

Achtung! Niemals alle »overfull boxes« gleichzeitig editieren! Angenommen, es gibt in einem Absatz 7 »overfull boxes«-Meldungen, dann wird zunächst die erste »overfull box« z.B. durch Wortumstellung korrigiert. Beim anschließenden Kompilieren kann es durchaus sein, daß aufgrund der Verschiebung der Wortfolgen aus den restlichen 6 »overfull boxes« nur noch 2 werden!