pdfTeX

pdftex --version liefert drei aneinandergereihte Zahlen: pdfTeX 3.141592653-2.6-1.40.26. Die erste gehört gar nicht zu pdfTeX – es ist Knuths TeX auf halbem Weg seiner Annäherung an π, und XeTeX wie LuaTeX tragen dieselben Ziffern. pdfTeX ist genau dieses TeX mit einer Ergänzung: Es schreibt PDF unmittelbar. Beim Aufruf pdflatex läuft in Wirklichkeit dieses Programm, und es ist nach wie vor die Standard-Engine für LaTeX. Diese Seite erklärt, warum es der Standard blieb, wie Schriften über TFM-Metriken und Map-Dateien aufgelöst werden – ein älteres Entwurfsmuster – und worin pdfTeX's eigentlicher Beitrag besteht: die Mikrotypografie, die microtype einschaltet, also Randausgleich und Schriftdehnung. Alle Angaben stammen aus Läufen unter TeX Live 2024.

Der Unterschied zwischen pdflatex, latex und pdftex

Alle drei sind dieselbe ausführbare Datei. Im bin-Verzeichnis von TeX Live 2024 sind pdflatex und latex symbolische Verweise auf pdftex, ebenso amstex und csplain. Verschieden ist allein das beim Start geladene Format. Ein Format ist eine .fmt-Datei mit einem bereits expandierten und eingefrorenen Makrosatz; die Zeile pdflatex pdftex ... *pdflatex.ini in fmtutil.cnf besagt: Wird das Programm unter dem Namen pdflatex aufgerufen, läuft die pdftex-Engine mit den LaTeX-Makros. Engine (das Programm) und Format (das Befehlssystem) sind also zwei getrennte Achsen, und „pdfLaTeX“ bezeichnet schlicht die Kombination pdfTeX-Engine mit LaTeX-Format.

shell
$ readlink $(which pdflatex) latex amstex
pdftex
pdftex
pdftex

$ grep -E '^(latex|pdflatex|pdftex) ' $(kpsewhich fmtutil.cnf)
latex     pdftex language.dat -translate-file=cp227.tcx *latex.ini
pdflatex  pdftex language.dat -translate-file=cp227.tcx *pdflatex.ini
pdftex    pdftex language.def -translate-file=cp227.tcx *pdfetex.ini

Aus dieser Tabelle ergeben sich zwei Nebenerkenntnisse. Erstens ist der Befehl latex keineswegs „das alte TeX“, sondern pdfTeX im DVI-Modus. Beim Aufruf erscheint die Kopfzeile This is pdfTeX, ... (preloaded format=latex), und heraus kommt eine .dvi-Datei. Zweitens entsteht das Format pdftex aus pdfetex.ini: Das e steht für e-TeX, jene Erweiterungen – \protected, \unexpanded, der vergrößerte Registerbereich, \middle –, die modernes LaTeX stillschweigend voraussetzt. Prüft man auf allen drei Engines, ob \eTeXversion definiert ist, antworten pdfTeX, XeTeX und LuaTeX gleichermaßen mit Ja. e-TeX ist längst keine Option mehr. \pdftexversion dagegen gibt es nur in pdfTeX; daran erkennen Pakete, welche Engine sie ausführt.

PDF direkt schreiben – und mit \pdfoutput=0 zurück zu DVI

Über das Ausgabeformat entscheidet ein einziger Ganzzahl-Parameter: \pdfoutput. Ein positiver Wert bedeutet PDF, 0 bedeutet klassisches DVI. Knuths ursprüngliches TeX gab nur DVI (device independent) aus und überließ die Umwandlung nach PostScript oder PDF einem eigenen Programm; pdfTeX zog diesen Schritt direkt hinter den Seitenaufbau – schloss den DVI-Ausgang aber nie. Pakete, die auf PostScript-\specials beruhen, allen voran PSTricks, brauchen mitunter noch den Weg DVI → PS → PDF, und genau dafür bleibt \pdfoutput=0 erhalten.

Die Falle liegt im Ort. \pdfoutput muss vor der Ausgabe der ersten Seite feststehen; wird es später geändert, bricht pdfTeX ab mit ! pdfTeX error (setup): \pdfoutput can only be changed before anything is written to the output. und anschließend ! ==> Fatal error occurred, no output PDF file produced!. Weder PDF noch DVI bleiben übrig. Da LaTeX die Treibererkennung sehr früh durchführt, ist die sichere Stelle ganz oben in der Datei, noch vor \documentclass.

latex
% Force DVI output even when the file is compiled with pdflatex.
% This line must come before \documentclass.
\pdfoutput=0
\documentclass{article}
\begin{document}
This run writes a .dvi file, not a .pdf.
\end{document}

Was microtype wirklich tut: Randausgleich und Schriftdehnung

Diese eine Zeile \usepackage{microtype} schaltet zwei voneinander unabhängige Mechanismen ein. Im .log stehen sie nebeneinander: Package microtype Info: Character protrusion enabled (level 2). und Package microtype Info: Automatic font expansion enabled (level 2), stretch: 20, shrink: 20, step: 1. Das erste ist der Randausgleich (protrusion): Punkte und Bindestriche am Zeilenende dürfen ein wenig über den Satzspiegel hinausragen, sodass eine mechanisch bündige Kante optisch gerade wirkt – eine Verallgemeinerung des alten Hängenlassens von Satzzeichen. Das zweite ist die Schriftdehnung: Glyphen dürfen um bis zu 2 % (20/1000) horizontal gedehnt oder gestaucht werden, und dieser Spielraum fließt in die Zeilenumbruchentscheidung selbst ein. Die Wortzwischenräume gleichen sich an, und die weißen „Flüsse“ im Absatz werden schmaler.

Beide Ideen stammen nicht von TeX. Sie gehen auf das hz-Programm zurück, das der Schriftgestalter Hermann Zapf ab 1988 mit Peter Karow und anderen bei URW in Hamburg entwickelte – Ziel war ein gleichmäßig graues Satzbild ohne Löcher und ohne Flüsse. URW ließ es patentieren (Europäisches Patent EP 0466953; die Rechte liefen im Juli 2010 aus), und die Algorithmen gingen schließlich an Adobe, das sie in InDesign einbaute. Dieselbe Idee nahm jedoch noch einen zweiten Weg: Der aus Vietnam stammende Hàn Thế Thành analysierte hz und setzte es in TeX um – als Promotionsarbeit an der Fakultät für Informatik der Masaryk-Universität in Brünn, der Dissertation Micro-typographic extensions to the TeX typesetting system, Oktober 2000, betreut von Jiří Zlatuška. Eine Idee, zwei Ziele: die Spitze des kommerziellen Marktes und eine freie Implementierung, die jeder benutzen kann. \usepackage{microtype} ist die zweite.

latex
\documentclass{article}
\usepackage{microtype} % protrusion + expansion, sensible defaults
\begin{document}
With microtype loaded, pdfTeX nudges punctuation into the margin
and flexes glyph widths by a hair, so justified text looks far
more even. Nothing else in the document has to change.
\end{document}

Beides lässt sich auch mit rohen Primitiven steuern. Auf der Protrusionsseite: \pdfprotrudechars (0 aus, 1 an, 2 auch in der Breitenberechnung berücksichtigt) zusammen mit \lpcode und \rpcode, die den Betrag je Zeichen am linken und rechten Rand festlegen. Auf der Dehnungsseite: \pdfadjustspacing (=2 bezieht die Dehnung in den Zeilenumbruch ein), \efcode für die Dehnbereitschaft jedes Zeichens und \pdffontexpand, um die gedehnten Instanzen einer Schrift zu deklarieren. In der Praxis fasst man das kaum an – microtype bringt für jede Schrift eine Konfigurationsdatei mit (mt-cmr.cfg für Computer Modern) und wählt die Werte selbst. Die Namen zu kennen lohnt trotzdem: Erst dann werden die Warnungen im Log lesbar.

PrimitivFunktionWofür zuständig
\pdfprotrudecharsprotrusion0 aus, 1 an, 2 wirkt auch auf die Breitenberechnung
\lpcode / \rpcodeprotrusionÜberhang je Zeichen am linken/rechten Rand (Promille)
\pdfadjustspacingexpansion=2 bezieht die Dehnung in den Zeilenumbruch ein
\efcodeexpansionDehnbereitschaft je Zeichen; in XeTeX nicht vorhanden
\pdffontexpandexpansiondeklariert die gedehnten Instanzen einer Schrift

Schriften werden über TFM-Metriken und Map-Dateien aufgelöst

pdfTeX bezieht Maße und Glyphenformen aus zwei verschiedenen Quellen. Die Maße stammen aus einer .tfm-Datei (TeX Font Metric): kpsewhich cmr10.tfm liefert fonts/tfm/public/cm/cmr10.tfm, und darin stehen nur Breite, Höhe, Tiefe jedes Zeichens sowie eine Unterschneidungstabelle – keine einzige Kontur. Erst wenn der Satz fertig ist und das PDF zusammengebaut wird, kommt die Map-Datei ins Spiel, und die dort benannte reale Schrift (eine Type-1-.pfb oder eine TrueType) wird gelesen. Der Eintrag für cmr10 ist eine einzige Zeile: cmr10 CMR10 <cmr10.pfb – TFM-Name, PostScript-Name, und < heißt „diese Datei einbetten“. Die von updmap unter TeX Live 2024 erzeugte pdftex.map umfasst 45.443 Zeilen; diese eine Textdatei ist die Zuordnungstabelle für sämtliche Schriften der Distribution.

shell
$ kpsewhich cmr10.tfm cmr10.pfb
/usr/local/texlive/2024/texmf-dist/fonts/tfm/public/cm/cmr10.tfm
/usr/local/texlive/2024/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb

$ grep -m1 '^cmr10 ' $(kpsewhich pdftex.map)
cmr10 CMR10 <cmr10.pfb

# The same one-line document, compiled by three engines:
$ pdffonts min-pdflatex.pdf
INJFRF+CMR10                        Type 1      Builtin      yes yes yes
$ pdffonts min-xelatex.pdf
HOLJOD+LMRoman10-Regular-Identity-H CID Type 0C Identity-H   yes yes yes
$ pdffonts min-lualatex.pdf
YIRABR+LMRoman10-Regular            CID Type 0C Identity-H   yes yes yes

Setzt man dasselbe einzeilige Dokument mit allen drei Engines und ruft pdffonts auf, zeigt sich der Entwurfsunterschied unmittelbar in der Ausgabe. pdfLaTeX bettet CMR10 als Type 1 ein; XeLaTeX und LuaLaTeX betten LMRoman10-Regular als CID Type 0C ein. Die Seite sieht in beiden Fällen nach Computer Modern aus, doch der eingeschlagene Weg und die eingebettete Datei sind völlig verschieden. Map-Dateien lassen sich aus dem Dokument heraus mit \pdfmapfile und \pdfmapline ergänzen – und bemerkenswerterweise gibt es beide auch in XeTeX. Das Erbe der 8-Bit-Zeit lebt breiter fort, als man vermuten würde.

Die 8-Bit-Grenze: ! Bad character code und warum fontspec sich weigert

256 Zeichen pro Schrift. Das ist pdfTeX's härteste Grenze. Schreibt man \font\x=cmr10 \x \char"1234, bricht es ab mit ! Bad character code (4660).. Dieselbe Eingabe an LuaTeX übergeben – nichts passiert, dessen Schriften sind intern breit. Diese Mauer aus 256 Plätzen ist der Grund, warum akzentuierte lateinische Buchstaben in eine Fontkodierung wie T1 umgepackt werden müssen und warum griechische Buchstaben und Sonderzeichen in eigene Schriften ausweichen. Wer diese Grenze kennt, versteht schlagartig, wozu fontenc da ist.

Das Missverständnis sitzt auf der Eingabeseite. Eine UTF-8-Quelle übersetzt unter modernem LaTeX auch ohne inputenc – seit 2018 ist das die Voreinstellung. Übersetzt wird allerdings nur, was LaTeX an Zeichen deklariert hat. Eine .tex-Datei mit läuft klaglos durch pdflatex; steht darin, endet es mit ! LaTeX Error: Unicode character 日 (U+65E5) not set up for use with LaTeX.. pdfTeX's Beschränkung lautet also nicht „kann kein UTF-8 lesen“, sondern „kann nur vorgesehene Zeichen setzen“. Und es gibt keinen Weg, eine im Betriebssystem installierte OpenType-Schrift beim Namen zu nennen: Lädt man fontspec, stirbt der Lauf sofort mit ! Fatal Package fontspec Error: The fontspec package requires either XeTeX or LuaTeX.. Diese drei Punkte – 256 Plätze, nur deklarierte Zeichen, keine Systemschriften – erklären beinahe jeden Wechsel zu XeTeX oder LuaTeX.

  • Gründe zu bleiben: Kompatibilität mit vorhandenen Vorlagen, Geschwindigkeit und dreißig Jahre Praxiserprobung. Für einen überwiegend englischen Aufsatz ist pdflatex die überraschungsärmste Wahl.
  • Gründe zu wechseln: mehrsprachiges Unicode, Systemschriften, japanischer Satz, Lua-gesteuerte Verarbeitung. Wird auch nur eines davon wirklich gebraucht, lohnt der Wechsel mehr als das Stapeln von Behelfslösungen.
  • Der häufige Unfall: fontspec laden und dabei auf pdfLaTeX bleiben. fontspec gehört zu XeLaTeX und LuaLaTeX.
  • Der andere Unfall: \pdfoutput hinter \documentclass schreiben. Der Lauf bricht ab und hinterlässt weder PDF noch DVI.

Bilder: PNG, JPEG und PDF direkt, EPS wird umgewandelt

pdfTeX liest drei Bildformate unmittelbar – PNG, JPEG und PDF – über das tiefliegende \pdfximage, worüber im Alltag \includegraphics aus graphicx liegt. Nur EPS muss zuvor in PDF umgewandelt werden, und selbst das geschieht inzwischen automatisch: Bei dem in TeX Live voreingestellten eingeschränkten Shell Escape ruft \includegraphics{fig.eps} still repstopdf auf, legt daneben ein fig-eps-converted-to.pdf an und bettet dieses ein. Hier lauert die Falle. Läuft der Durchgang mit -no-shell-escape, findet keine Umwandlung statt – und es erscheint weder Fehler noch Warnung. Stattdessen wird ein leerer Rahmen mit dem Dateinamen gesetzt, und das PDF entsteht einwandfrei. So verschwinden Abbildungen typischerweise in der CI.

Da pdfTeX das PDF selbst schreibt, stellt es auch Primitive bereit, die bis in die PDF-Funktionen hineinreichen. \pdfliteral schleust rohe PDF-Zeichenoperatoren ein, \pdfobj erzeugt ein PDF-Objekt, \pdfannot setzt eine Annotation – einen Link, ein Formularfeld. Die Verweise und Lesezeichen von hyperref ruhen auf dieser Schicht. Für dokumentweite Einstellungen gibt es \pdfinfo für Metadaten wie Titel und Autor, \pdfcompresslevel für die Stärke der Komprimierung und \pdfpageattr, das jeder Seite Attribute anhängt.

latex
\pdfinfo{
  /Title (My Report)
  /Author (A. Author)
}
\pdfcompresslevel=9
% a thin rule drawn with a raw PDF operator
\pdfliteral{0 0 m 100 0 l 0.4 w S}
PrimitivAufgabe in pdfTeXSchreibweise in LuaTeX
\pdfoutputwählt PDF- oder DVI-Ausgabe\outputmode
\pdfliteralschleust rohe PDF-Zeichenoperatoren ein\pdfextension literal
\pdfobj / \pdfannoterzeugt ein PDF-Objekt oder eine Annotation\pdfextension obj / annot
\pdfinfoschreibt Metadaten wie Titel und Autor\pdfextension info
\pdfcompresslevelKomprimierungsgrad des PDFs (0–9)\pdfvariable compresslevel
\pdfximageliest ein PNG-/JPEG-/PDF-Bild ein\saveimageresource
\pdfsaveposzeichnet die aktuelle Position auf der Seite auf\savepos
\pdfprotrudecharsaktiviert den Randausgleich\protrudechars
\pdfadjustspacingaktiviert die Schriftdehnung\adjustspacing

Was pdfTeX's \pdf...-Primitive in späteren Engines hinterließen

LuaTeX baut auf pdfTeX auf und übernahm den größten Teil von dessen Maschinerie, doch der wuchernde \pdf...-Namensraum wurde aufgeräumt. Vieles läuft nun über drei Zugänge – \pdfextension, \pdfvariable und \pdffeedback –, die ein Schlüsselwort samt Argumenten entgegennehmen. Aus \pdfliteral wurde \pdfextension literal, aus \pdfoutput wurde \outputmode, aus \pdfximage wurde \saveimageresource, und aus \pdfprotrudechars / \pdfadjustspacing wurden \protrudechars / \adjustspacing. \lpcode, \rpcode und \efcode behielten dagegen ihre Namen unverändert. Das Wissen aus der pdfTeX-Zeit trägt fast vollständig; nur die Schreibweise verschiebt sich.

XeTeX hat nur einen Teil davon übernommen, und gerade diese Teilerbschaft wirkt sich in der Praxis aus. Prüft man die Primitive unter TeX Live 2024 einzeln durch, so besitzt XeTeX \lpcode und \rpcode, nicht aber \efcode; auch der Schalter für den Randausgleich heißt nicht \pdfprotrudechars, sondern abweichend \XeTeXprotrudechars. Unter XeLaTeX funktioniert der Randausgleich also, während sich die Schriftdehnung grundsätzlich nicht umsetzen lässt; fordert man sie ausdrücklich mit \usepackage[expansion=true]{microtype} an, bricht der Lauf ab: ! Package microtype Error: Font expansion does not work with xetex.. Lädt man microtype ohne Optionen, verschwindet die Dehnungszeile kommentarlos aus dem Log – daher der verbreitete Eindruck, microtype „bewirke unter XeLaTeX weniger“, ohne dass der Grund klar wäre.

Wann pdflatex heute die richtige Wahl ist

Ist das Dokument überwiegend englisch, ist die Vorlage durch Zeitschrift oder Mitautoren bereits festgelegt und drängt die Frist, dann pdfLaTeX. Bei einem 417-seitigen mathematischen Dokument, auf dieser Maschine gemessen, war pdfLaTeX die schnellste der drei Engines – und zugleich diejenige, die am seltensten über ein vorhandenes Paket stolpert. Es verlangt wenig: eine Zeile \usepackage{microtype}, Abbildungen als PNG/JPEG/PDF und, wenn EPS im Spiel ist, kein abgeschaltetes Shell Escape. Umgekehrt lohnt es nicht, für ein Dokument mit japanischem Satz oder Systemschriften immer neue Behelfe auf pdfTeX zu türmen; jenseits dieser Grenze ist es Sache von XeLaTeX oder LuaLaTeX. pdfTeX selbst befindet sich heute weitgehend im Wartungsmodus, die Neuentwicklung ist zu LuaTeX gewandert – doch die 45.443 Zeilen von pdftex.map und drei Jahrzehnte angesammelter Vorlagen bleiben vorerst, wo sie sind.