Engine/Format auswählen

„Welche LaTeX-Engine soll ich nehmen?“ – dies ist ein Entscheidungsleitfaden zu dieser Frage, mit der Antwort zuerst. Kurzfassung: pdflatex für westlichen Text, xelatex oder lualatex, wenn Systemschriften oder Unicode nötig sind, und uplatex oder lualatex für Japanisch. Diese vier sind allerdings keine vier gleichrangigen Optionen: Alle führen dasselbe LaTeX-Format aus; verschieden ist nur die Engine darunter. Es folgen das direkte Duell zwischen XeLaTeX und LuaLaTeX, der Grund, warum die Antwort für Japanisch anders ausfällt, und was beim Umstieg tatsächlich zerbricht.

Die kürzeste Antwort, nach Zweck

Für die meisten genügen diese vier Zeilen. Die genannten Namen sind Kombinationen aus einer Engine (dem laufenden Programm) und einem Format (LaTeX, dem Befehlssystem), angegeben als der Befehl, den man tatsächlich eintippt. Im Zweifel zuerst dem folgen, was das Einreichungsziel oder die Vorlage vorschreibt; nur wenn nichts vorgeschrieben ist, greifen die folgenden Verzweigungen.

• Westlicher Text (Englisch und europäische Sprachen), der sicherste Weg → pdfLaTeX (pdflatex). De-facto-Standard von LaTeX, mit der meisten Dokumentation und den meisten Vorbildern – und die einzige Engine, auf der sämtliche mikrotypografischen Funktionen greifen.
• Die Schriften des Betriebssystems nutzen, Sprachen mischen, Konfiguration schlank halten → XeLaTeX (xelatex). Mit fontspec genügt \setmainfont{...}.
• Dasselbe, dazu programmierbare Kontrolle über den Satz und eine Wette auf die Zukunft → LuaLaTeX (lualatex). Aus Lua heraus lässt sich in den Satz eingreifen, und engine-spezifische Neuerungen im Kernel landen meist zuerst hier – etwa die LuaTeX-Callback-Einträge in ltnews34.
• Japanisch → upLaTeX (uplatex) ist der stabile Mainstream; LuaLaTeX mit luatexja der moderne, Unicode-native Weg. XeLaTeX ist hier nicht zu empfehlen – der Grund steht weiter unten. Die Klasse jlreq arbeitet mit beiden erstgenannten.

XeLaTeX oder LuaLaTeX – welches wählen

Diese beiden decken sich so weit, dass „beide beherrschen Unicode und Systemschriften“ – genau deshalb fällt die Wahl zwischen ihnen am schwersten. Eine Zeile entscheidet: XeLaTeX, wenn das vorliegende Dokument leicht und schnell fertig werden soll; LuaLaTeX, wenn es ein Dokument ist, das über Jahre wachsen wird. Der Unterschied ist keine Punktetabelle von Funktionen, sondern die Art der Kosten: XeLaTeX ist billig an Konfiguration und Wartezeit, LuaLaTeX billig an Zukunftssicherheit und Erweiterbarkeit. Die folgende Tabelle unter diesem Blickwinkel lesen.

Aus dieser Tabelle lässt sich eine praktische Trennlinie ziehen. XeLaTeX wählen, wenn man eine Schrift auf dem eigenen Rechner beim Namen nennen und sofort setzen will; wenn das Mischen von Schriftsystemen der eigentliche Zweck ist und an westlicher Mikrotypografie wenig liegt; wenn vorhandene PSTricks-Grafiken mitgeschleppt werden; und wenn so oft neu übersetzt wird, dass die Wartezeit spürbar ist. LuaLaTeX wählen, wenn das westliche Ergebnis bis ins Letzte stimmen soll (die Fontdehnung von microtype wird gebraucht); wenn Japanisch in Unicode zu behandeln ist; wenn der Satz selbst programmiert werden soll, etwa durch Einlesen externer Daten für Tabellen; und wenn das Dokument über Jahre gepflegt wird. Für Japanisch, wohlgemerkt, taucht XeLaTeX in dieser Wahl gar nicht auf.

Welche Engine für Japanisch – und warum die Antwort anders lautet

Für Japanisch steht die Wahl zwischen uplatex und lualatex; XeLaTeX fällt heraus. Englischsprachige Artikel enden meist bei „XeLaTeX oder LuaLaTeX, wenn Unicode und Systemschriften nötig sind“ – für Japanisch gilt diese Gleichung nicht. Denn japanischer Satz verlangt weit mehr, als Unicode-Zeichen ausgeben zu können: Kinsoku-Umbruchregeln, den Viertelgeviert-Abstand zwischen japanischem und westlichem Text, Vertikalsatz, Ruby und japanische Schriftmetriken (JFM). Dafür braucht es eine eigene Schicht, und die existiert nur für die pTeX-Engine-Familie und, für LuaTeX, in luatexja.

Die Klassendateien bestätigen das. jlreq, die japanische Satzklasse nach JIS X 4051, nimmt die Engine als Option entgegen – und jlreq.cls akzeptiert genau drei: platex, uplatex und lualatex. xelatex ist nicht darunter. Japanisch unter XeLaTeX ist nicht unmöglich; Pakete wie zxjatype existieren. Doch die maßgeblichen japanischen Klassen und der angesammelte Bestand an Dokumentation liegen bei jenen dreien, und die japanischen Vorlagen von Zeitschriften oder Hochschulen bleiben fast immer in diesem Rahmen. Praktische Schlussfolgerung: Enthält das Dokument Japanisch, ist XeLaTeX nicht der erste Kandidat.

Also uplatex oder lualatex? Die natürliche Trennung lautet: uplatex, wenn vorhandenes Material existiert; lualatex, wenn etwas Langlebiges neu begonnen wird. uplatex ist schnell, seine japanischen Satzregeln sind gründlich ausgereift, und die meisten von Fachgesellschaften und Verlagen verteilten Klassen setzen es voraus. Die Ausgabe ist allerdings stets DVI, also eine zweistufige Kette über dvipdfmx, und Schriften werden herkömmlich eingerichtet. lualatex mit luatexja nutzt Unicode und Systemschriften unmittelbar, und luatexja-fontspec erlaubt es, japanische Schriften beim Namen zu nennen – doch die Satzzeit wächst merklich. Zu beachten: Für die japanischen Schriften ist nicht das bloße fontspec zuständig.

Die Achsen, die entscheiden

Für den Fall, dass die schnelle Antwort nicht passt – oder dass man den Grund wissen will –, hier die Achsen einzeln. Die meisten laufen am Ende darauf hinaus, wie die Engine mit Schriften und Zeichenkodierung umgeht.

Schriften. pdfTeX nutzt TeX’ traditionelles Schriftmodell: TFM (TeX Font Metric) plus Type1- oder PK-Schriften. Auf eine im Betriebssystem installierte Schrift kann es nicht einfach zeigen. Hier gehen XeTeX und LuaTeX am schärfsten eigene Wege – beide können die bereits im System vorhandenen TrueType- und OpenType-Schriften unmittelbar verwenden, benannt über das Paket fontspec wie in \setmainfont{Times New Roman}. Umgekehrt gilt: fontspec setzt XeTeX oder LuaTeX voraus und funktioniert unter pdfLaTeX nicht.

Eingabekodierung. XeTeX und LuaTeX sind intern Unicode-nativ und nehmen UTF-8-Quellen unverändert entgegen. Auch pdfTeX verwendet seit dem LaTeX-Release von 2018 UTF-8 als Standardeingabekodierung, \usepackage[utf8]{inputenc} ist also nicht mehr nötig – intern bildet es jedoch weiterhin auf 8-Bit-Fontkodierungen wie T1 ab, sodass es von fontenc und Schrift abhängt, welche Zeichen erscheinen; beliebiges Unicode oder CJK lässt sich nicht einfach eintippen. Wer mehrsprachigen Text und Sonderzeichen unbeschwert schreiben will, ist mit XeTeX oder LuaTeX besser bedient.

Paketkompatibilität. Das ist die in der Praxis am häufigsten übersehene Falle. Manche Pakete sind engine-spezifisch. fontspec und unicode-math gibt es nur für XeTeX/LuaTeX. Umgekehrt läuft pstricks unter dem DVI-geführten pdfLaTeX und unter XeLaTeX, in der Regel aber nicht unter LuaLaTeX. Die Unverträglichkeit wirkt auch andersherum: Quelltext nach einem alten Tutorial übersetzt womöglich nicht auf einer neueren Engine. Die goldene Regel lautet, vor allem anderen zu prüfen, welche Engine die Vorlage oder die Zeitschriftenklasse verlangt.

Geschwindigkeit. Der Unterschied ist real und spürbar. Die Reihenfolge lautet pdfTeX am schnellsten, XeTeX in der Mitte, LuaTeX am langsamsten – doch die Lücke öffnet sich im Teil, der mit der Satzmenge wächst, nicht beim Start. Bei einem nahezu leeren einseitigen Dokument sind die drei kaum zu unterscheiden; bei einigen hundert Seiten braucht LuaLaTeX ein Mehrfaches der Laufzeit von pdfLaTeX (die Messwerte stehen auf der LuaTeX-Seite). Über die Hunderte von Neuübersetzungen einer echten Schreibphase summiert sich das. Umgekehrt gelesen: Bei einem Aufsatz von einem Dutzend Seiten lohnt die Sorge nicht.

Mikrotypografie (microtype). Was das Erscheinungsbild westlichen Textes zuverlässig hebt, sind der Randausgleich (protrusion) und die Fontdehnung (expansion) von microtype. Die Engine-Unterschiede sind hier groß und stehen unverblümt in der README von microtype: Randausgleich wirkt auf allen dreien – pdfTeX, LuaTeX und XeTeX –, doch Fontdehnung nur mit pdfTeX und LuaTeX, nicht mit XeTeX. Darüber hinaus ist die Anpassung von Wortabständen und zusätzlicher Unterschneidung pdfTeX vorbehalten, während das Abschalten von Ligaturen und der Sperrsatz pdfTeX oder LuaTeX verlangen. Steht der westliche Feinschliff an erster Stelle, ist pdfLaTeX, mit LuaLaTeX als Zweitem, die sichere Wahl.

Grafiken und Programmierbarkeit. Das Einbinden von PNG, JPEG und PDF schreibt sich auf jeder Engine im Wesentlichen gleich, über graphicx und \includegraphics (pdfLaTeX wandelt EPS selbsttätig um). Der Unterschied liegt in der für LuaTeX eigentümlichen Steuerung aus Lua: Man kann sich in die Stufen des Satzes einklinken oder externe Daten einlesen, um eine Tabelle zu bauen – Dinge, die sich als Makros mühsam schreiben. Es harmoniert zudem mit dem modernen Paketbestand einschließlich fontspec und unicode-math, worauf sich die Rede von der Zukunftssicherheit stützt.

Die vier Optionen nebeneinander

Hier stehen die vier Hauptoptionen entlang der entscheidenden Achsen; die erste Spalte nennt den Befehl, den man tatsächlich eintippt, und microtype ist in Randausgleich und Dehnung aufgeteilt. Die Tabelle ist ein Wegweiser, kein Urteil – pdfLaTeX setzt zusammen mit \usepackage[T1]{fontenc} und einem passenden westlichen Schriftpaket viele europäische Sprachen vorzüglich, und Randausgleich greift auch unter XeLaTeX. Weniger als Ja/Nein lesen, mehr als Abwägung zwischen Aufwand und Feinschliff.

Mit einer kleinen Testdatei entscheiden

Bevor das Schreiben beginnt, die in Frage kommenden Engines an einer einseitigen Testdatei laufen lassen. Ein Engine-Wechsel mitten in einer Abschlussarbeit oder einer Einreichung verschiebt Schriften, Abbildungen, Literaturverzeichnis und Zeilenumbrüche zugleich und verdeckt die Ursache jeder Störung. Zu prüfen ist nicht nur, ob es durchläuft. Zu betrachten sind die Warnungen im Log, die Schrifteinbettung im PDF, das Ergebnis der Abbildungen und die Frage, ob Mitwirkende dieselben Schritte reproduzieren können – diese vier.

# Western candidates: same source, three engines.
$ pdflatex engine-test.tex
$ xelatex  engine-test.tex
$ lualatex engine-test.tex

# Japanese candidate: upLaTeX writes DVI, dvipdfmx makes the PDF.
$ uplatex   engine-test.tex
$ dvipdfmx  engine-test.dvi

# Then compare what actually came out.
$ pdffonts engine-test.pdf     # are all fonts embedded?
$ grep -i warning engine-test.log

• Gibt es eine Zielvorlage, mit dieser Vorlage testen. Dass eine leere Datei durchläuft, beweist nichts über die Einreichungskonfiguration.
• Eine Abbildung, eine abgesetzte Formel und einen Literatureintrag aufnehmen. Ein Test, der kein Miniaturbild des echten Manuskripts ist, prüft nichts.
• Zugleich die Werkzeuge für Literatur und Register prüfen. BibTeX oder Biber, mendex oder upmendex – davon hängt die Konfiguration von latexmk ab. Die Engine allein festzulegen genügt nicht: Passt das hier nicht zusammen, scheitert der Bau trotzdem.
• Nach der Entscheidung die Engine in .latexmkrc oder die README schreiben, damit später niemand das Projekt beiläufig mit einer anderen übersetzt.
• Die PDFs vergleichen. Weichen Zeilenumbrüche oder Schriften ab, den Grund der Wahl im Projekt hinterlassen.

Was beim Wechsel der Engine zerbricht

Derselbe Quelltext kann nach einem Engine-Wechsel ein anderes Ergebnis liefern. Das sind die vier Minen, in die man tatsächlich tritt.

Schrift- und Kodierungseinrichtung ändern sich. Die pdfLaTeX-Klassiker \usepackage[utf8]{inputenc} und \usepackage[T1]{fontenc} sind unter XeLaTeX und LuaLaTeX unnötig und werden normalerweise weggelassen – diese Engines sind intern Unicode. Stattdessen greift man zu fontspec und \setmainfont. Eine pdfLaTeX-Präambel unverändert zu übernehmen, kann Warnungen oder schriftbezogene Fehler erzeugen.

% For pdfLaTeX (traditional; both lines are optional on current LaTeX)
%   \usepackage[utf8]{inputenc}
%   \usepackage[T1]{fontenc}

% For XeLaTeX / LuaLaTeX: name an OS or TeX font instead
\usepackage{fontspec}
\setmainfont{TeX Gyre Termes}

microtype wirkt anders. Dasselbe \usepackage{microtype} zeitigt je nach Engine andere Effekte – unter XeLaTeX ist die Fontdehnung schlicht abgeschaltet. Ein unter pdfLaTeX abgestimmter Umbruch verschiebt sich daher beim Wechsel leicht: Zeilenlängen und Umbruchstellen ändern sich. Bei einem Dokument von einigen Dutzend Seiten ist es nicht ungewöhnlich, dass die Seitenzahl um eins wandert.

Der Bestand nutzbarer Pakete wechselt. Manche Pakete funktionieren auf der Zielengine nicht mehr, andere werden überhaupt erst verfügbar. Mit PSTricks gezeichnete Abbildungen laufen nach dem Umzug auf LuaLaTeX nicht, das pstricks nicht unterstützt; umgekehrt sind fontspec und unicode-math unter pdfLaTeX nicht verfügbar. Vorlagen von Zeitschriften und Verlagen setzen meist eine bestimmte Engine voraus; ihr zuerst zu folgen, ist der sichere Zug.

Bei Japanisch ändert sich die gesamte CJK-Schrifteinrichtung. upLaTeX (die pTeX-Familie) und LuaLaTeX mit luatexja unterscheiden sich sowohl in der Benennung japanischer Schriften als auch in deren Einbettung. Für eine japanische Migration mehr Schmerz einplanen als für eine westliche. Die konkreten Befehlsentsprechungen stehen gesammelt auf der Seite „Übersetzungsbefehle“.