Méthodes de composition japonaise

La première décision, en composition japonaise avec LaTeX, ne porte pas sur le package à charger mais sur la voie à emprunter. Trois sont vivantes aujourd'hui : upLaTeX + dvipdfmx, LuaLaTeX + LuaTeX-ja et XeLaTeX + zxjatype. Le même fichier .tex passe par les trois, et les trois embarquent la même police de labeur dans le PDF. Ce qui change, c'est la vitesse, les packages encore utilisables et l'endroit où cela casse. C'est le japonais qui a poussé TeX à se doter d'un second modèle de composition — colle entre caractères, écriture verticale, interdiction de coupure — et ces trois voies en sont trois implémentations. Cette page tranche à partir de mesures faites sur TeX Live 2024.

Les trois voies du LaTeX japonais : où réside le savoir

La vraie différence tient à la couche du système qui détient le savoir japonais. Dans upLaTeX, il est dans le moteur : écriture verticale, interdictions de coupure et colle entre caractères font partie d'un compositeur écrit en C, d'où la rapidité. Dans LuaLaTeX, il est dans des callbacks Lua — LuaTeX-ja parcourt la liste de nœuds que LuaTeX vient de construire et lui applique les règles japonaises, d'où la lenteur et une bien plus grande facilité de modification. Dans XeLaTeX, il est dans un package de macros, zxjatype (qui charge xeCJK en dessous) : un mécanisme CJK général réglé pour le japonais, non un moteur japonais. Les sorties diffèrent aussi : seul upLaTeX passe par DVI puis dvipdfmx ; les deux autres écrivent directement du PDF.

Un morceau d'histoire du TeX japonais se cache en bas à droite de ce tableau. dvipdfmx est né comme extension du dvipdfm de Mark A. Wicks, dotée du multi-octet et du CID — un outil bâti pour le japonais. XeTeX l'a ensuite adopté comme étage de sortie, ce qui a donné xdvipdfmx. Dans une installation TeX Live 2024 réelle, dvipdfmx est un lien symbolique vers xdvipdfmx. Un convertisseur écrit pour le japonais assure aujourd'hui la dernière étape de tout document XeTeX, japonais ou non.

Quel écart de vitesse ? La même source par les trois voies

Le même document japonais de dix pages a demandé 0,31 s avec uplatex + dvipdfmx, 0,59 s avec lualatex (ltjsarticle) et 0,74 s avec xelatex (bxjsarticle + zxjatype) sous TeX Live 2024. Soit environ 1 : 1,9 : 2,4, rapport qui vaut aussi pour un fichier d'une page : l'écart vient surtout du démarrage et de la composition, pas de la longueur. Une fois, personne ne remarque 0,3 s contre 0,6 s ; avec latexmk -pvc et une recompilation à chaque enregistrement, cela se sent. C'est cela, plus que la nostalgie, qui maintient la voie pLaTeX après vingt ans. Les trois PDF incorporent en sous-ensemble la même Harano Aji Mincho, et pdftotext en extrait du japonais correct dans les trois cas : la voie rapide n'est pas la voie médiocre.

# 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

Choisir la classe de document : jsclasses, jlreq, ltjsclasses, bxjscls

La voie choisie, la classe se choisit presque d'elle-même : jsarticle (de jsclasses) ou jlreq pour upLaTeX, ltjsarticle (de ltjsclasses) ou jlreq pour LuaLaTeX, bxjsarticle (de bxjscls) pour XeLaTeX. Une exception cependant : jlreq prend en charge pLaTeX, upLaTeX et LuaLaTeX, mais pas XeLaTeX. Donner \documentclass{jlreq} à xelatex produit ! Undefined control sequence. puis dégringole jusqu'à ! LaTeX Error: Missing \begin{document}. L'idée qu'une classe fixe permet de changer librement de moteur est exacte, mais XeLaTeX ne fait pas partie des destinations.

La surprise que réserve toujours le choix de la classe : le même 10pt ne désigne pas la même taille. Composez en jsarticle à 10pt, mesurez un kanji : il fait 9,24683pt de large, car le fichier de classe contient \def\Cjascale{0.924690} et charge la police japonaise à 0,924690 fois la taille latine. Le même essai en jlreq donne exactement 10pt. Remplacer jsarticle par jlreq modifie donc la longueur de ligne, le nombre de caractères par ligne et tout le pavé de texte. Une migration se prépare comme une remise en page, pas comme une comparaison à conditions égales.

% 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}

Ce que coûte la voie pLaTeX : fontspec, unicode-math, microtype

Le prix de cette rapidité : la voie pLaTeX exclut en bloc les packages modernes fondés sur OpenType. \usepackage{fontspec} s'arrête sur ! Fatal Package fontspec Error: The fontspec package requires either XeTeX or (LuaTeX à la ligne suivante), et unicode-math répond ! Package unicode-math Error: Cannot be run with uptex!. Le cas retors est microtype : il ne provoque aucune erreur. Il écrit Package microtype Warning: You don't seem to be using pdftex, luatex or xetex. dans le journal, puis ne fait silencieusement rien — chargé mais inerte, la panne la plus difficile à repérer. En revanche graphicx, hyperref et tikz fonctionnent normalement si le pilote correspond : il ne s'agit donc pas de « seuls les vieux packages marchent ». La frontière passe exactement par OpenType et la micro-typographie.

Signets PDF illisibles : hyperref et pxjahyper

Écrivez un titre de section en japonais sous (u)pLaTeX avec hyperref et seuls les signets du PDF ressortent illisibles : le texte courant est parfait, le panneau de plan est incompréhensible. La cause : hyperref verse les octets UTF-8 du titre tels quels dans une chaîne UTF-16BE. Le fichier .out engendré contient alors \376\377\000\346\000\227\000\245…, chaque octet doublé d'un zéro. Ajoutez \usepackage{pxjahyper} et le même titre devient \376\377\145\345\147\054\212\236…, soit 0x65E5 0x672C 0x8A9E, les trois caractères de 日本語. Avec hyperref sur (u)pLaTeX, considérez pxjahyper comme obligatoire. Sous LuaLaTeX avec LuaTeX-ja, hyperref seul produit déjà de l'UTF-16BE correct : cette étape disparaît.

% (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}

Alors, quelle voie choisir ?

Pour tout nouveau document, choisissez LuaLaTeX avec LuaTeX-ja (ltjsarticle ou jlreq). Contre un tiers de seconde, on obtient de l'Unicode de bout en bout, l'accès aux polices système, fontspec, unicode-math et microtype opérationnels, et des signets tout simplement corrects. Si le modèle de thèse du département ou un fichier de style de conférence suppose jsclasses, ou si le temps de compilation compte vraiment dans une boucle d'édition serrée, restez sur upLaTeX + dvipdfmx : ce n'est pas la voie héritée, c'est encore la plus rapide. XeLaTeX + zxjatype se choisit lorsqu'un document XeLaTeX existe déjà et qu'il faut y ajouter du japonais ; pour du japonais seul, l'intérêt est mince. Enfin, plus aucune raison de démarrer sur platex simple : uplatex élargit le répertoire de caractères composables (différence traitée dans « Encodage des caractères et fins de ligne »).

• Nouveau document, aucune contrainte institutionnelle → lualatex avec ltjsarticle (ou jlreq) ; Unicode, polices système et microtype sont disponibles.
• Un modèle existant suppose jsclasses, ou la vitesse de compilation compte → uplatex + dvipdfmx ; ptex2pdf -l -u réunit le tout en une commande.
• Un document XeLaTeX existe déjà → bxjsarticle + zxjatype + zxjafont ; jlreq ne fonctionne pas sous XeLaTeX.
• hyperref sur (u)pLaTeX ? Chargez pxjahyper. « Seuls les signets sont illisibles » vient presque toujours de là.
• microtype est inopérant sur (u)pLaTeX : il avertit et ne fait rien. Pour en profiter, passez par Lua ou Xe.