Methoden für japanischen Satz

Die erste Entscheidung beim japanischen Satz mit LaTeX betrifft nicht das Paket, sondern den Weg. Drei sind heute lebendig: upLaTeX + dvipdfmx, LuaLaTeX + LuaTeX-ja und XeLaTeX + zxjatype. Dieselbe .tex-Datei läuft durch alle drei, und alle drei betten dieselbe Grundschrift ins PDF ein. Unterschiedlich sind Geschwindigkeit, die noch nutzbaren Pakete und die Stellen, an denen es bricht. Japanisch ist überhaupt der Grund, warum TeX ein zweites Satzmodell bekam – Leim zwischen einzelnen Zeichen, vertikale Schrift, Umbruchverbote – und diese drei Wege sind drei Umsetzungen davon. Diese Seite entscheidet die Wahl anhand von Messungen auf TeX Live 2024.

Die drei Wege für japanisches LaTeX – und wo das Wissen sitzt

Der eigentliche Unterschied liegt darin, in welcher Schicht das japanische Wissen steckt. Bei upLaTeX sitzt es in der Engine: vertikale Schrift, Umbruchverbote und Leim zwischen Zeichen gehören zu einem in C geschriebenen Setzer – deshalb ist der Weg schnell. Bei LuaLaTeX steckt es in Lua-Callbacks: LuaTeX-ja durchläuft die soeben gebaute Knotenliste und wendet die japanischen Regeln darauf an – deshalb ist der Weg langsamer und weit leichter zu ändern. Bei XeLaTeX steckt es in einem Makropaket, zxjatype (das darunter xeCJK lädt), also in einem allgemeinen CJK-Mechanismus, der auf Japanisch abgestimmt wurde, nicht in einer japanischen Engine. Auch die Ausgabe unterscheidet sich: Nur upLaTeX läuft über DVI und übergibt an dvipdfmx, die anderen beiden schreiben direkt PDF.

Unten rechts in dieser Tabelle versteckt sich ein Stück japanischer TeX-Geschichte. dvipdfmx entstand als Erweiterung von Mark A. Wicks' dvipdfm um Multibyte- und CID-Unterstützung – ein Werkzeug, das für Japanisch gebaut wurde. XeTeX übernahm es dann als eigene Ausgabestufe und machte xdvipdfmx daraus. In einer realen TeX-Live-2024-Installation ist dvipdfmx ein symbolischer Link auf xdvipdfmx. Ein für Japanisch geschriebener Konverter besorgt heute den letzten Schritt jedes XeTeX-Dokuments, ob japanisch oder nicht.

Wie viel langsamer ist LuaLaTeX? Dieselbe Quelle über alle drei Wege

Dasselbe zehnseitige japanische Dokument brauchte unter TeX Live 2024 0,31 s mit uplatex + dvipdfmx, 0,59 s mit lualatex (ltjsarticle) und 0,74 s mit xelatex (bxjsarticle + zxjatype). Das ergibt etwa 1 : 1,9 : 2,4, und das Verhältnis gilt auch für eine einzelne Seite – der Abstand entsteht überwiegend durch Start und Satz selbst, nicht durch die Textmenge. Einmalig stört 0,3 s gegenüber 0,6 s niemanden; wer mit latexmk -pvc bei jedem Speichern neu übersetzt, merkt es. Genau das, nicht Nostalgie, hält den pLaTeX-Weg seit zwei Jahrzehnten am Leben. Alle drei PDFs betten dieselbe Schrift Harano Aji Mincho als Teilsatz ein, und pdftotext liefert aus allen dreien korrektes Japanisch zurück – der schnelle Weg ist also nicht der schlechtere.

# route 1 -- fastest; DVI in between
uplatex main.tex && dvipdfmx main.dvi
ptex2pdf -l -u main            # the same two steps in one command

# route 2 -- LuaTeX-ja, PDF straight out
lualatex main.tex

# route 3 -- XeTeX via zxjatype
xelatex main.tex

Die Dokumentklasse wählen: jsclasses, jlreq, ltjsclasses, bxjscls

Ist der Weg gewählt, wählt sich die Klasse fast von selbst: jsarticle (aus jsclasses) oder jlreq für upLaTeX, ltjsarticle (aus ltjsclasses) oder jlreq für LuaLaTeX, bxjsarticle (aus bxjscls) für XeLaTeX. Mit einer Ausnahme: jlreq unterstützt pLaTeX, upLaTeX und LuaLaTeX, aber nicht XeLaTeX. Gibt man \documentclass{jlreq} an xelatex, erscheint ! Undefined control sequence. und danach ! LaTeX Error: Missing \begin{document}. Die Idee, eine feste Klasse erlaube freien Engine-Wechsel, stimmt – XeLaTeX gehört nur nicht zu den möglichen Zielen.

Die eine Überraschung bei der Klassenwahl: Dasselbe 10pt bedeutet nicht dieselbe Größe. Setzt man ein Dokument in jsarticle mit 10pt und misst ein Kanji, ist es 9,24683pt breit – die Klassendatei enthält \def\Cjascale{0.924690} und lädt die japanische Schrift mit dem 0,924690-fachen der lateinischen Größe. In jlreq ist ein Kanji genau 10pt. Der Wechsel von jsarticle zu jlreq verändert also Zeilenlänge, Zeichen pro Zeile und den gesamten Satzspiegel. Eine Migration ist eine Neugestaltung, kein Vergleich unter gleichen Bedingungen.

% route 1: uplatex main.tex && dvipdfmx main.dvi
\documentclass[uplatex,dvipdfmx]{jsarticle}
\begin{document}
日本語と English を混ぜた段落です。約物（かっこ）も混じります。
\end{document}

% route 2: lualatex main.tex
\documentclass{ltjsarticle}
\usepackage{luatexja-fontspec}
\setmainjfont{Harano Aji Mincho}
\setsansjfont{Harano Aji Gothic}
\begin{document}
日本語と English を混ぜた段落です。約物（かっこ）も混じります。
\end{document}

Was der pLaTeX-Weg kostet: fontspec, unicode-math, microtype

Der Preis der Geschwindigkeit: Der pLaTeX-Weg sperrt die modernen, auf OpenType gebauten Pakete geschlossen aus. \usepackage{fontspec} bricht ab mit ! Fatal Package fontspec Error: The fontspec package requires either XeTeX or (in der nächsten Zeile LuaTeX), und unicode-math antwortet ! Package unicode-math Error: Cannot be run with uptex!. Heikel ist microtype: Es bricht nicht ab. Es schreibt Package microtype Warning: You don't seem to be using pdftex, luatex or xetex. ins Protokoll und tut dann stillschweigend nichts – geladen, aber wirkungslos, die am schwersten bemerkbare Art von Defekt. graphicx, hyperref und tikz laufen dagegen normal, sofern der Treiber passt; es gilt also nicht „nur alte Pakete funktionieren". Die Grenze verläuft genau entlang OpenType und Mikrotypografie.

Zerschossene PDF-Lesezeichen: hyperref und pxjahyper

Schreibt man unter (u)pLaTeX mit hyperref eine japanische Überschrift, kommen ausgerechnet die PDF-Lesezeichen verstümmelt heraus: Der Fließtext stimmt, die Gliederungsleiste ist Zeichensalat. Grund ist, dass hyperref die UTF-8-Bytes der Überschrift unverändert in eine UTF-16BE-Zeichenkette schüttet. In der erzeugten .out-Datei steht dann \376\377\000\346\000\227\000\245… – jedes Byte mit einer Null aufgefüllt. Mit \usepackage{pxjahyper} wird aus derselben Überschrift \376\377\145\345\147\054\212\236…, also 0x65E5 0x672C 0x8A9E, die drei Zeichen von 日本語. Wer hyperref auf (u)pLaTeX einsetzt, sollte pxjahyper als Pflicht betrachten. Unter LuaLaTeX mit LuaTeX-ja liefert schon das schlichte hyperref korrektes UTF-16BE; dieser Zusatzschritt entfällt.

% (u)pLaTeX: load pxjahyper AFTER hyperref, or the outline panel is garbage
\documentclass[uplatex,dvipdfmx]{jsarticle}
\usepackage{hyperref}
\usepackage{pxjahyper}
\begin{document}
\section{日本語の見出し}
本文。
\end{document}

Welchen Weg also wählen?

Für alles Neue gilt: LuaLaTeX mit LuaTeX-ja (ltjsarticle oder jlreq) wählen. Gegen eine Drittelsekunde bekommt man durchgängiges Unicode, Zugriff auf Systemschriften, funktionierendes fontspec, unicode-math und microtype sowie Lesezeichen, die einfach stimmen. Setzt die Abschlussarbeitsvorlage des Instituts oder eine Konferenz-Stildatei jsclasses voraus, oder zählt die Übersetzungszeit in einer engen Bearbeitungsschleife wirklich, bleibt man bei upLaTeX + dvipdfmx – kein Altweg, sondern weiterhin der schnellste. XeLaTeX + zxjatype wählt man, wenn bereits ein XeLaTeX-Dokument existiert, dem Japanisch hinzugefügt werden soll; allein für Japanisch spricht wenig dafür. Für ein neues Dokument gibt es keinen Grund mehr, einfaches platex zu nehmen: uplatex erweitert den setzbaren Zeichenvorrat (dieser Unterschied steht auf „Zeichenkodierung und Zeilenenden").

• Neues Dokument, keine institutionellen Vorgaben → lualatex mit ltjsarticle (oder jlreq); Unicode, Systemschriften und microtype stehen bereit.
• Eine vorhandene Vorlage setzt jsclasses voraus, oder die Übersetzungszeit zählt → uplatex + dvipdfmx; ptex2pdf -l -u fasst beides zu einem Befehl zusammen.
• Es gibt bereits ein XeLaTeX-Dokument → bxjsarticle + zxjatype + zxjafont; jlreq läuft unter XeLaTeX nicht.
• hyperref auf (u)pLaTeX? Dann pxjahyper laden. „Nur die Lesezeichen sind kaputt" ist fast immer das.
• microtype ist auf (u)pLaTeX wirkungslos – es warnt und tut nichts. Wer es braucht, geht den Lua- oder Xe-Weg.