js-basierte Klassen

Verlangt man von jsarticle einen „10-Punkt“-Textkörper, misst die japanische Schrift tatsächlich rund 9,25 Punkt. Das ist kein Fehler, sondern Absicht: Haruhiko Okumuras jsclasses (jsarticle, jsbook) sind um den japanischen Satzkegel von 13 Q (3,25 mm) herum gebaut, nicht um die lateinischen 10 pt. Die js-basierten Klassen behalten das Gefühl der LaTeX-Standardklassen und tauschen nur aus, was Japanisch braucht: die Fontmetrik, die Staffel der Schriftgrößen und den Mechanismus, der sie skaliert. ltjsclasses trägt den Entwurf zu LuaLaTeX, BXjscls zu jeder Engine. Diese Seite zeigt, welches Problem jede der drei Familien löst und wie man wählt.

Die zwei Dinge, die jsclasses an den Standardklassen ändert

Das mitgelieferte Handbuch von jsclasses nennt genau zwei Unterschiede zu den Standardklassen: die japanische Fontmetrik und den Umgang mit den Größenoptionen. Es schrieb keine Philosophie von Rändern oder Durchschuss um, sondern reparierte zwei Stellen, die beim japanischen Satz tatsächlich kaputt waren. Erstens verwendet es die JIS-Fontmetriken jis.tfm und jisg.tfm von Hajime Kobayashi (Tokyo Shoseki Printing) anstelle der älteren min10 und goth10. Zweitens baute es die Größenwahl neu: Die Standardklassen boten nur 10pt, 11pt und 12pt, und – so das Handbuch selbst – außerhalb der Standardgröße von 10 Punkt geriet die Balance der Schriften etwas aus dem Lot.

Beides hat dieselbe Wurzel. Der japanische Druck misst Schrift in Q (kyū, 1 Q = 0,25 mm), und der übliche Textkörper ist 13 Q, also 3,25 mm. Ein Vollbreitenzeichen der rohen JIS-Metrik misst jedoch 13,527 Q, weshalb jsclasses die japanische Schrift um 0,961 (= 13 ÷ 13,527) skaliert, damit das Geviert genau auf 13 Q fällt. Das Handbuch rechnet das vor und hält fest, dass ein nominell zehn Punkt großer Textkörper nach der Skalierung der 9,62216-pt-Metrik in Wahrheit „gut neun Punkt“ misst. Das Verhältnis steckt im reellwertigen Makro \Cjascale und beträgt in jsarticle, jsbook und jsreport 0,924690 (= 9,62216 pt × 0,961 ÷ 10 pt). Seit 2018 liest das OTF-Paket dieses Makro, um die japanische Größe anzugleichen.

% upLaTeX: the dvipdfmx option is a global option for graphicx/hyperref
\documentclass[uplatex,dvipdfmx,a4paper,papersize]{jsarticle}
\begin{document}
こんにちは、\LaTeX！
\end{document}

Die Familie besteht aus jsarticle (Aufsätze und Berichte), jsbook (Bücher) und jsreport (Berichte), dazu kommen jspf für eine Fachzeitschrift und kiyou für Bulletins. jsreport wurde im Februar 2017 nach einer Forumsdiskussion aus dem herausgelöst, was man zuvor mit der report-Option von jsbook erledigte. Okumura schrieb das Bündel ursprünglich auf Basis von classes.dtx des LaTeX3 Project und jclasses.dtx der ASCII Corporation; 2009 kam Takuji Tanakas upLaTeX-Patch hinzu, und seit Juli 2016 pflegt die Japanese TeX Development Community das Paket (texjporg/jsclasses auf GitHub). Es ist Teil von TeX Live, eine gesonderte Installation entfällt.

Wie die Textgröße entsteht: \mag gegen nomag

jsclasses setzt den Textkörper mit 10 pt und skaliert danach das ganze Dokument mit TeXs Primitive \mag auf die gewünschte Größe (×1,095 bei 11pt, ×1,200 bei 12pt). So kommen Größen zustande, die die Standardklassen nicht kennen: die geometrische Staffel 8pt, 9pt, 14pt, 17pt, 20pt, 21pt, 25pt, 30pt, 36pt, 43pt, die Q-Werte 12Q und 14Q sowie die Realgrößen 10ptj, 10.5ptj, 11ptj, 12ptj. \mag dehnt Papier, Glyphen und Linien gleichermaßen – wirkungsvoll, aber manche Werkzeuge verstehen den Wert nicht, und das Ergebnis hängt davon ab, wie dvipdfmx oder dvips ihn weiterverarbeiten.

In der Praxis beginnt man mit dem Standard usemag. Zeigen geometry, die Bildplatzierung oder eine PDF-Nachverarbeitung eine echte Maßabweichung, probiert man nomag*. Reproduzierbarkeit – dieselben Befehle ergeben dasselbe PDF – zählt mehr, als von Anfang an jede Option zu laden. Und weil ein per \mag skaliertes Dokument jedem nachgelagerten DVI-Werkzeug mitteilen muss, dass eine Vergrößerung gilt, erspart es Ärger, die Skalierungsmethode gemeinsam mit dem Build-Rezept festzulegen.

Braucht jsarticle pLaTeX oder upLaTeX?

Beides funktioniert, denn die Klasse erkennt die Engine selbst. Schreibt man nur \documentclass{jsarticle} und lässt upLaTeX laufen, meldet das Log Class jsarticle Info: Autodetected engine: upLaTeX und schaltet die japanischen Kodierungen auf JY2/JT2; unter pLaTeX steht dort Autodetected engine: pLaTeX. Trotzdem schreibt man uplatex (oder platex oder autodetect-engine) als Klassenoption: Sie hält die Absicht in der Quelle fest und verhindert, dass eine Verwechslung still ein anderes Layout erzeugt. Widersprechen sich Option und tatsächliche Engine, bricht die Klasse ab, etwa mit ! Class jsarticle Error: Option 'platex' is specified but you are running upLaTeX.

dvipdfmx ist dagegen gar keine Klassenoption. Was jsclasses nicht selbst verbraucht, wird als globale Option an die folgenden Pakete weitergereicht, und graphicx, color und hyperref lesen sie, um ihren Treiber zu wählen. Einmal in die Klammern von \documentclass geschrieben, erspart sie die Angabe bei jedem einzelnen Paket – mehr steckt hinter der geläufigen Form [uplatex,dvipdfmx] nicht.

Warum ein A5-Dokument als A4-PDF herauskommt

Wenn a5paper verlangt war und das PDF A4 ist, liegt es nicht an der Klasse, sondern daran, dass die DVI kein Papierformat mitführt. Unter TeX Live 2024 ergibt \documentclass[uplatex,a5paper]{jsarticle} über dvipdfmx ein PDF von 595,28 × 841,89 pt, also A4: Eine DVI-Datei kennt kein Papier, und dvipdfmx greift auf seine eigene Vorgabe zurück. Mit der Klassenoption papersize wird ein \special{papersize=...} geschrieben, und dieselbe Quelle kommt mit 419,53 × 595,28 pt heraus, also A5. Zusammen mit tombow wächst der Bogen um die Schneidmarken: Aus A5 werden 563,53 × 739,28 pt, exakt ein Zoll je Seite mehr. LuaLaTeX (ltjsclasses, nächster Abschnitt) schreibt das PDF direkt und kennt das Problem nicht.

ltjsclasses – jsclasses auf LuaLaTeX portiert

ltjsclasses schreibt jsclasses für LuaLaTeX (LuaTeX-ja) um und wird vom LuaTeX-ja-Projekt gepflegt. Es bietet ltjsarticle, ltjsbook und ltjsreport (dazu ltjspf und ltjskiyou) und entspricht den jsclasses eins zu eins, wie die Namen sagen. Der größte Unterschied liegt in der Skalierung. Das LuaTeX-Handbuch hält ausdrücklich fest, dass Vergrößerung mit \mag nur im DVI-Ausgabemodus unterstützt wird; bei direkter PDF-Ausgabe steht sie nicht zur Verfügung. Deshalb ist in ltjsclasses nomag* der Standard, und bei usemag warnt die Klasse mit This ltjsarticle cls does not support 'usemag' option, since LuaTeX does not support \mag in pdf output und fällt auf nomag* zurück.

Auch die engine-bezogenen Optionen verhalten sich anders. uplatex führt zu einem Fehler (this class does not support 'uplatex' option), während autodetect-engine nur eine Warnung auslöst und ignoriert wird – sinnvoll, denn hier gibt es nur eine Engine. Die japanische Metrik ist standardmäßig LuaTeX-jas jfm-ujis.lua; die Option ptexjis schaltet auf dieselbe JIS-Metrik wie jsclasses (jfm-jis.lua), mingoth auf die ältere jfm-min.lua. Zum Wechseln der Schriften kombiniert man die Klasse mit luatexja-fontspec und benennt jede im System installierte OpenType-Schrift direkt.

% compile with lualatex; nomag* is already the default here
\documentclass[a4paper]{ltjsarticle}
\usepackage{luatexja-fontspec}
\setmainjfont{Noto Serif CJK JP}
\setsansjfont{Noto Sans CJK JP}
\begin{document}
こんにちは、\LaTeX！
\end{document}

BXjscls – eine Quelle, jede Engine

BXjscls (Takayuki Yato, bekannt als ZR) weitet den Entwurf der jsclasses auf jede Engine aus und bietet bxjsarticle, bxjsbook, bxjsreport und bxjsslide. Zuerst kommt es darauf an, wie die Engine benannt wird. Die Engine ist eine schlichte Klassenoption, kein engine= – eine von lualatex, xelatex, pdflatex, platex, uplatex, latex, platex-ng oder autodetect-engine für die automatische Erkennung. Schreibt man engine=lualatex, kommt die Angabe nicht an und der Lauf endet mit ! Class bxjsarticle Error: An engine option must be explicitly given.

% the engine is a bare option; ja= picks the Japanese driver
\documentclass[lualatex,ja=standard,a5paper]{bxjsarticle}
\begin{document}
こんにちは、\LaTeX！
\end{document}

% same body, different engine: swap the first option only
% \documentclass[uplatex,ja=standard,dvipdfmx,a5paper]{bxjsarticle}

Der zweite Schlüssel ist ja= (früher jadriver), der das japanische Verarbeitungsschema aus standard, minimal, modern und pandoc wählt. Hier liegt die eigentliche Falle. Lässt man ja= weg, wird nur unter (u)pLaTeX standard ergänzt; jede andere Engine fällt mit der Warnung The option 'ja' is MISSING!! So 'ja=minimal' is assumed as fallback, but such implicit setting is now DEPRECATED! auf minimal zurück. Umgekehrt wird eine ausdrückliche Engine-Option zwingend, sobald ja= angegeben ist. In der Praxis ist die einzig sichere Form daher, Engine und ja= stets gemeinsam zu schreiben. Mit ja=standard lädt die Klasse das passende Japanisch-Paket für die verwendete Engine.

Das Vokabular für Maße borgt bei jsclasses und bei jlreq. Die lateinische Grundgröße heißt base= (Alias fontsize=), die japanische jbase= (Alias jafontsize=) und das japanische Skalenverhältnis scale= (Alias jafontscale=) mit dem Standardwert \jsScale = 0,924715 (\Cjascale zeigt auf denselben Wert). Der Textblock lässt sich mit textwidth= und number-of-lines= angeben oder mit jlreqs Schreibweisen line_length= und number_of_lines=. Die Skalierung wählt magstyle= mit usemag, nomag oder nomag*; ab LuaTeX v0.87 und unter pTeX-ng ist nomag* der Standard, und magstyle=usemag bricht ab mit ! Class bxjsarticle Error: The engine does not support 'magstyle=usemag'.

jsclasses, ltjsclasses oder BXjscls – was wählen?

Zuerst die Engine wählen, dann die passende Klasse. Selbst für denselben „jsarticle-Look“ ändert sich der Klassenname mit dem Prozessor. Nur die Klasse zu tauschen und die Engine zu belassen, ist der sichere Weg, die Japanisch-Verarbeitung zu verlieren und das Layout zerfallen zu sehen.

• Unter pLaTeX/upLaTeX jsclasses verwenden. Die Standardwahl, wenn vorhandene Quellen oder Einreichungsvorgaben den Prozessor festlegen. Als Ausgangspunkt dient \documentclass[uplatex,dvipdfmx,papersize]{jsarticle}.
• Vor allem LuaLaTeX? ltjsclasses. OpenType-Schriften des Systems funktionieren direkt, und das PDF entsteht ohne DVI-Zwischenschritt; nomag* ist Standard, und das Papierformat geht nie verloren.
• Engine nicht festlegen oder die Quelle weitergeben? BXjscls. Zwei Änderungen – Engine-Name und ja= – genügen, damit dieselbe Datei zwischen pdfLaTeX, XeLaTeX, LuaLaTeX und (u)pLaTeX wandert.
• Textblock in Zahlen vorgeben? jlreq. Eine eigene Linie neben der js-Familie, in der Zeilenlänge, Zeilenzahl und Ränder nach dem Standard entworfen werden.

Die Route im Log bestätigen

Da in der js-Familie Engine und Klasse ein Paar bilden, verraten die ersten Zeilen der .log-Datei, ob das Dokument über die beabsichtigte Route gesetzt wurde. In Zusammenarbeit oder CI ist nicht zu prüfen, ob ein PDF entstand, sondern ob das PDF aus der vorgesehenen Route stammt. Im Idealfall nennen Build-Befehl, \documentclass-Zeile und README dasselbe.