Wie die Verarbeitung funktioniert (DVI/PDF)

Ein einzeiliges LaTeX-Dokument – \documentclass{article}\begin{document}Hi\end{document} – durch pdflatex geschickt ergibt ein PDF von 11.529 Byte. Dieselbe Quelle durch latex geschickt ergibt eine DVI-Datei von 248 Byte. Faktor sechsundvierzig. Beide beschreiben dieselbe eine Seite mit demselben einen Wort „Hi“ – wohin geht also der Unterschied? Die Antwort erklärt den gesamten Verarbeitungsweg von TeX. Diese Seite verfolgt den Weg von der Quelle über die Engine bis zur Ausgabe, zeigt, was wirklich in einer .dvi steckt, und erklärt, warum die ältere DVI-Route nicht verschwunden ist – durchgehend mit gemessenen Zahlen.

Warum kein WYSIWYG: die Entscheidung für Stapelverarbeitung

TeX zeichnet den Bildschirm nicht beim Tippen neu, weil es den Zeilenumbruch absatzweise optimiert. Es füllt nicht Zeile um Zeile, sondern bewertet den gesamten Absatz danach, welche Kombination von Umbruchstellen insgesamt am wenigsten stört, und nimmt die Lösung mit den geringsten Gesamtkosten. Die Folge: Ein zusätzliches Zeichen am Absatzende kann den Umbruch der allerersten Zeile verschieben. Jeden Absatz bei jedem Tastendruck neu zu berechnen, lohnt sich nicht.

Also entschied sich TeX für Stapelverarbeitung: das Manuskript bis zum Ende lesen und dann alles in einem Zug setzen. Aufgegeben wird der Komfort, die Seite beim Tippen mitwachsen zu sehen. Gewonnen werden global optimaler Satz, über lange Dokumente hinweg gleichbleibende Form und die Automatisierung, die Klartext ermöglicht – Quelltext per Skript erzeugen, in Git vergleichen, unbeaufsichtigt auf einem Server bauen. Der Arbeitsrhythmus heißt: schreiben, übersetzen, ins PDF schauen, wiederholen. Diese Schleife schnell zu machen, darum geht es im Folgenden fast durchgehend.

Zwei Wege von der Quelle zur Ausgabe: direkt zum PDF oder über DVI

Eine Engine schreibt entweder direkt PDF oder eine Zwischendatei namens DVI. pdflatex, xelatex und lualatex – die Engines pdfTeX, XeTeX und LuaTeX – schreiben PDF; latex sowie die japanischen platex und uplatex schreiben DVI. Damit ist die Arbeit nicht getan: Die Datei geht an ein eigenes Programm, einen DVI-Treiber, der sie in das gewünschte Format überführt – dvipdfmx nach PDF, dvips nach PostScript, dvisvgm nach SVG. Ein Treiber, der auf den Bildschirm zeichnet, heißt DVI-Betrachter.

# Direct to PDF, one step
lualatex  document.tex        # -> document.pdf
pdflatex  document.tex        # -> document.pdf

# Via DVI, two steps (the Japanese route)
uplatex   document.tex        # -> document.dvi
dvipdfmx  document.dvi        # -> document.pdf

# Other dvi drivers, same input
dvips     document.dvi        # -> document.ps
dvisvgm   document.dvi        # -> document.svg

Verwechselt wird hier gern, dass „läuft es über DVI?“ und „kann es Unicode und Systemschriften?“ zwei verschiedene Achsen sind. pdflatex umgeht DVI und schreibt direkt PDF, geht mit der Eingabe aber auf die alte Art um und lässt sich nicht einfach auf eine installierte OpenType-Schrift richten. xelatex und lualatex lesen umgekehrt Unicode unverändert und erlauben, eine Schrift über fontspec beim Namen zu nennen. Werden beide Achsen getrennt gehalten, ordnet sich die Fülle der Namen von selbst.

Was steckt wirklich in einer .dvi? Ein Blick in die 248 Byte

DVI steht für device independent – geräteunabhängig –, und darin steckt nichts als eine Folge von Anweisungen, welches Zeichen an welche Position gehört. Mit dvitype, das TeX Live beiliegt, lässt sich das in lesbare Form bringen. So sah es in der 248 Byte großen DVI aus, die aus dem einzeiligen Dokument oben entstand.

$ dvitype -output-level=4 one.dvi
numerator/denominator=25400000/473628672
magnification=1000
' TeX output 2026.08.13:1233'
maxv=41484288, maxh=26673152, maxstackdepth=3, totalpages=1
Font 27: cmr10---loaded at size 655360 DVI units

42: beginning of page 1
117: down4 41484288       v:=0+41484288=41484288
140: right3 5046272       h:=0+5046272=5046272
144: fntdef1 27: cmr10
165: fntnum27             current font is cmr10
166: setchar72            h:=5046272+491521=5537793
167: setchar105           h:=5537793+182045=5719838
[Hi]
181: setchar49            h:=15204352+327681=15532033
[ 1]
185: eop

Das ist die ganze Datei. setchar72 heißt „setze Zeichencode 72 (H) hierher“, setchar105 „setze 105 (i)“, und setchar49 ist die 1 der Seitenzahl am Fuß. right3 und down4 verschieben den aktuellen Punkt, und die Einheit – ein DVI unit ist ein sp, also 1/65536 pt – erklärt, warum cmr10 mit „655360 DVI units“ genau 10 pt entspricht. Entscheidend ist die Zeile fntdef1 27: cmr10: die DVI ruft die Schrift bloß beim Namen. Nirgends in der Datei steht, wie cmr10 aussieht.

Beim PDF ist es genau umgekehrt. Im 11.529 Byte großen PDF von pdflatex ist die Schrift eingebettet, unter dem Namen UNYBJV+CMR10. Das sechsstellige Präfix kennzeichnet einen Subset – der Beleg, dass nur die tatsächlich benutzten Glyphen entnommen wurden. Das Objekt mit dieser Schrift lautet /Length1 1394 /Length2 8300 /Length3 0 /Length 9259: 9.259 Byte selbst nach Kompression, vier Fünftel der gesamten 11.529 Byte. Dorthin ist der Faktor sechsundvierzig im Wesentlichen geflossen. Wo die DVI „das H von cmr10“ schreiben darf, muss das PDF den Umriss dieses H mit sich führen. Das ist der Preis für das Versprechen des PDF, überall gleich auszusehen.

Eine Einschränkung allerdings. „Die DVI ist klein, weil sie keine Schrift enthält“ stimmt; „das PDF hat 11.529 Byte, weil es eine enthält“ erklärt noch nicht alles. Läuft dieselbe 248-Byte-DVI durch dvipdfmx, ist das PDF 1.950 Byte groß. Auch dort ist die Schrift eingebettet, aber in die weit kompaktere Form /Subtype/Type1C überführt, in der sie nur 546 Byte beansprucht. Eine Seite mit einem einzigen Wort liegt also – je nach Beschreibung – bei 248, 1.950 oder 11.529 Byte. Wo die Dateigröße zählt, macht sich der gewählte Weg tatsächlich bemerkbar.

Warum die DVI-Route weiterlebt: Japanisch und .xdv

Der stärkste praktische Grund für das Fortbestehen von DVI ist, dass darüber der Standardweg des japanischen Satzes führt. platex und uplatex geben DVI aus, und dvipdfmx macht am Ende ein PDF daraus. Dieses Programm ging aus Mark A. Wicks' dvipdfm hervor und wurde für japanische Anforderungen erweitert; die Fassung in TeX Live 2024 stammt vom März 2024. Seine Aufgabe: die Positionierungsbefehle der DVI in PDF-Zeichenoperationen übersetzen und die referenzierten Schriften finden und einbetten. Läuft ein einzeiliges japanisches Dokument durch upLaTeX, wird aus einer 396-Byte-DVI ein 5.998-Byte-PDF, in dem die japanische Schrift HaranoAjiMincho als CID-Schrift eingebettet ist.

Und dieser Mechanismus ist aktueller, als man denkt. Prüft man in TeX Live 2024 nach, was dvipdfmx tatsächlich ist, stellt sich heraus: ein Symlink auf xdvipdfmx – das Programm, das die von XeTeX erzeugten .xdv-Dateien liest. XeTeX gibt intern also ein leicht erweitertes DVI aus und lässt es von einem Treiber in PDF verwandeln: genau die DVI-Route. Beweisen lässt sich das mit xelatex -no-pdf, das vor der Umwandlung anhält und die .xdv liegen lässt. Beim einzeiligen Dokument ist die .xdv 436 Byte groß; durch xdvipdfmx entsteht daraus ein PDF von 2.329 Byte – genau so groß wie das Ergebnis eines schlichten xelatex-Laufs über dieselbe Quelle. Die Arbeit von Hand in zwei Schritte zu zerlegen, macht bloß sichtbar, was xelatex intern ohnehin tut.

$ readlink $(which dvipdfmx)
xdvipdfmx

$ xelatex -no-pdf one.tex     # stop before the driver stage
$ ls -l one.xdv
-rw-r--r--  1 user  staff  436 one.xdv

$ xdvipdfmx one.xdv           # run the driver by hand
$ ls -l one.pdf
-rw-r--r--  1 user  staff  2329 one.pdf

Die praktische Regel ist einfach. Wer neu in englischer oder anderer lateinschriftlicher Sprache anfängt, nimmt die Direkt-PDF-Route (pdflatex oder lualatex): eine Stufe weniger heißt eine Fehlerquelle weniger. Wer auf Japanisch mit vorhandenem Material oder einer Institutsgepflogenheit arbeitet, fährt mit der DVI-Route (uplatex plus dvipdfmx) weiterhin solide; sie hat eine lange Bilanz beim Vertikalsatz und den japanischen Umbruchregeln. Die vollständige Abwägung gehört auf die Seite zur Wahl der Engine; jedenfalls besteht kein Anlass, DVI als etwas zu meiden, nur weil es alt ist.

Hilfsdateien und die Zahl der Durchgänge – samt BibTeX und makeindex

„Die Engine einmal laufen lassen, fertig“ gilt nur für Dokumente ohne Verweise, Inhaltsverzeichnis, Literaturverzeichnis und Register. Während eines Laufs schreibt die Engine .aux (Nummern und Seiten) und .toc (das Inhaltsverzeichnis); der nächste Lauf liest sie zurück. Das zu wiederholen, bis es sich einpendelt, ist die Grundform – sobald ein einziges \ref auftaucht, sind es mindestens zwei Durchgänge. Literaturverzeichnisse und Register schieben weitere Programme in die Schleife: BibTeX liest die .aux und schreibt eine .bbl (oder biber liest eine .bcf), makeindex liest die .idx und schreibt eine .ind. Deren Ausgaben muss die Engine anschließend lesen, woraus sich die unten stehende Reihenfolge ergibt.

# A document with cross-references, a bibliography and an index
pdflatex   thesis      # writes .aux, .idx; references still print as ??
bibtex     thesis      # reads .aux  -> writes .bbl
makeindex  thesis      # reads .idx  -> writes .ind
pdflatex   thesis      # pulls .bbl and .ind in; numbering shifts again
pdflatex   thesis      # everything settles

# Or simply
latexmk -pdf thesis    # figures out the order and the count on its own

Aufhören, Durchgänge zu zählen: latexmk, Editoren und SyncTeX

latexmk beobachtet die Hilfsdateien und wiederholt den Lauf genau so oft, wie das Dokument es braucht. Kommen .aux und Verwandte gleich wie beim letzten Mal heraus, gilt der Build als eingependelt und der Vorgang endet; unterwegs werden BibTeX/biber oder makeindex aufgerufen, falls nötig. Voreingestellt sind höchstens fünf Wiederholungen ($max_repeat = 5), bevor eine Schleife angenommen wird. Echte Dokumente erreichen diese Grenze praktisch nie. Auch für die DVI-Route genügt derselbe eine Befehl, sobald der Weg in einer latexmk-Konfigurationsdatei hinterlegt ist.

latexmk -pdf      document.tex   # pdfLaTeX, as many passes as needed
latexmk -lualatex document.tex   # LuaLaTeX
latexmk -pv       document.tex   # build, then open the viewer
latexmk -c                       # remove .aux, .log, .toc and friends
latexmk -C                       # the same, and remove the PDF too

LaTeX Workshop in VS Code, TeXShop, TeXstudio und Overleaf rufen im Hintergrund meist latexmk auf – ein Druck auf „Kompilieren“ hat das Zählproblem also längst gelöst. Ebenfalls einschaltenswert ist SyncTeX: Es hält in einer .synctex.gz-Datei fest, aus welcher Quellzeile jede Stelle im PDF stammt. Aktiviert genügt ein Klick im PDF, um in der Quelle an der passenden Zeile zu landen – und umgekehrt. Je länger das Dokument, desto mehr lohnt sich das.

Wenn ein Build stoppt: welche Stufe verdächtig ist

Aus welcher Stufe eine Meldung stammt, bestimmt den Suchort. Ein Engine-Fehler im .log heißt: Das Problem liegt in der Quelle. Beschwert sich der DVI-Treiber, geht es um ein Bild oder eine Schrift. Ausgaben von BibTeX oder biber verweisen auf die .bib. Am verwirrendsten ist das Symptom „mein Bild erscheint nicht“ – darin schlägt der Unterschied der Routen unmittelbar durch: Die DVI-Route nimmt EPS bereitwillig, die Direkt-PDF-Route nimmt PDF, PNG und JPEG. Ein PNG in ein mit latex übersetztes Dokument einbinden zu wollen, ist daher ein sehr häufiger Einstieg in dieses Problem. Wie das Log zu lesen ist, behandelt die Seite zur Fehlersuche ausführlich.

• Wenn nur die Querverweise falsch sind, keine Hilfsdateien löschen, sondern latexmk so oft laufen lassen, wie es nötig ist.
• Wenn nur Bilder fehlen, prüfen, ob der laufende Weg direkt zum PDF oder über DVI führt, und die Datei in ein Format wandeln, das dieser Weg annimmt.
• Wenn ein Symptom ohne Erklärung bestehen bleibt, und erst dann, .aux, .toc und .out löschen und neu bauen (latexmk -c). Lag es an veralteten Hilfsdateien, ist es damit behoben.
• Wenn sich Schriften in einem japanischen PDF ändern, die Einbettungskonfiguration von dvipdfmx verdächtigen. Das ist eine Treiberfrage, keine Frage der Engine.