Choisir un moteur ou un format

« Quel moteur LaTeX faut-il utiliser ? » — voici un guide de décision pour cette question, la réponse d’abord. En bref : pdflatex pour le texte occidental, xelatex ou lualatex s’il faut des fontes système ou de l’Unicode, et uplatex ou lualatex pour le japonais. Ces quatre-là ne sont pourtant pas quatre options équivalentes : toutes exécutent le même format LaTeX ; seul diffère le moteur au-dessous. Suivent le duel direct entre XeLaTeX et LuaLaTeX, la raison pour laquelle la réponse change en japonais, et ce qui casse réellement quand on change de moteur.

La réponse la plus courte, selon l’usage

Pour la plupart des gens, ces quatre lignes suffisent. Les noms ci-dessous sont des combinaisons d’un moteur (le programme qui s’exécute) et d’un format (LaTeX, le système de commandes), donnés sous la forme de la commande réellement tapée. Dans le doute, obéissez d’abord à ce qu’impose la revue ou le modèle ; les embranchements ci-dessous ne valent qu’en l’absence de consigne.

• Texte occidental (anglais et langues européennes), la voie la plus sûre → pdfLaTeX (pdflatex). Standard de fait de LaTeX, avec le plus de documentation et d’antécédents — et le seul moteur où toutes les fonctions micro-typographiques opèrent.
• Utiliser les fontes du système, mêler les langues, garder une configuration légère → XeLaTeX (xelatex). Avec fontspec, un \setmainfont{...} suffit.
• Tout cela, plus un contrôle programmable de la composition et un pari sur l’avenir → LuaLaTeX (lualatex). On peut intervenir dans la composition depuis Lua, et les nouveautés du noyau propres à un moteur arrivent le plus souvent ici d’abord — voir les entrées sur les callbacks LuaTeX dans ltnews34.
• Japonais → upLaTeX (uplatex) est le courant dominant et stable ; LuaLaTeX avec luatexja la voie moderne, nativement Unicode. XeLaTeX n’est pas recommandé ici — la raison suit. La classe jlreq fonctionne avec l’un ou l’autre des deux premiers.

XeLaTeX ou LuaLaTeX : lequel choisir

Ces deux-là se rejoignent jusqu’au point où « tous deux gèrent l’Unicode et les fontes système » — c’est précisément pourquoi le choix hésite le plus entre eux. Une ligne tranche : XeLaTeX si vous voulez achever légèrement et vite le document que vous avez sous la main ; LuaLaTeX s’il s’agit d’un document que vous ferez croître des années durant. La différence n’est pas un tableau de scores de fonctionnalités, mais le type de coût que l’on paie : XeLaTeX coûte peu en configuration et en attente ; LuaLaTeX coûte peu en pérennité et en extensibilité. Lisez le tableau suivant dans cette optique.

De ce tableau se dégage une ligne de partage pratique. Choisir XeLaTeX quand on veut désigner une fonte de sa machine par son nom et composer aussitôt ; quand le mélange d’écritures est le but et qu’on ne tient guère à la micro-typographie occidentale ; quand on traîne des figures PSTricks existantes ; et quand on recompile assez souvent pour que l’attente se sente. Choisir LuaLaTeX quand on veut peaufiner jusqu’au bout le rendu occidental (la dilatation des fontes de microtype est nécessaire) ; quand le japonais doit être traité en Unicode ; quand on veut programmer la composition elle-même, par exemple lire des données externes pour bâtir des tableaux ; et quand le document sera entretenu des années. Pour le japonais, notons-le, XeLaTeX n’entre pas du tout dans ce choix.

Quel moteur pour le japonais, et pourquoi la réponse change

Pour le japonais, le choix se fait entre uplatex et lualatex ; XeLaTeX sort du jeu. Les articles anglophones s’arrêtent d’ordinaire à « XeLaTeX ou LuaLaTeX s’il faut de l’Unicode et des fontes système », mais cette équation ne tient pas en japonais. La raison : la composition japonaise exige bien plus que de savoir produire des caractères Unicode — règles de césure kinsoku, espace d’un quart de cadratin entre japonais et texte occidental, écriture verticale, ruby, et métriques de fontes propres au japonais (JFM). Il y faut une couche dédiée, et celle-ci n’existe que pour la famille de moteurs pTeX et, côté LuaTeX, dans luatexja.

Les fichiers de classe le confirment. jlreq, la classe de composition japonaise conforme à JIS X 4051, reçoit le moteur en option — et jlreq.cls en accepte exactement trois : platex, uplatex et lualatex. xelatex n’en fait pas partie. Le japonais sous XeLaTeX n’est pas impossible ; des packages comme zxjatype existent. Mais les grandes classes japonaises et la documentation accumulée se trouvent du côté de ces trois-là, et les modèles japonais fournis par une revue ou une université restent presque toujours dans ce cadre. Conclusion pratique : si le document contient du japonais, XeLaTeX n’est pas le premier candidat.

Alors, uplatex ou lualatex ? La ligne naturelle est : uplatex en présence de matériel existant, lualatex pour repartir de zéro sur un document durable. uplatex est rapide, ses règles de composition japonaise sont parfaitement rodées, et la plupart des classes diffusées par les sociétés savantes et les éditeurs le supposent. Sa sortie est toutefois toujours du DVI : chaîne en deux temps via dvipdfmx, et fontes configurées à l’ancienne. lualatex avec luatexja emploie l’Unicode et les fontes système telles quelles, et luatexja-fontspec permet de désigner les fontes japonaises par leur nom — mais le temps de composition s’allonge sensiblement. À noter : ce n’est pas fontspec seul qui sélectionne les fontes japonaises.

Les axes qui décident

Pour les cas où la réponse rapide ne convient pas — ou quand on veut savoir pourquoi —, voici les axes un à un. La plupart reviennent en fin de compte à la manière dont le moteur traite les fontes et le codage des caractères.

Fontes. pdfTeX utilise le modèle de fontes traditionnel de TeX : TFM (TeX Font Metric) plus fontes Type1 ou PK. Il ne peut pas simplement désigner une fonte installée dans le système. C’est ici que XeTeX et LuaTeX divergent le plus nettement : tous deux savent employer directement les fontes TrueType et OpenType déjà présentes sur le système, désignées via le package fontspec comme dans \setmainfont{Times New Roman}. À l’inverse, fontspec exige XeTeX ou LuaTeX et ne fonctionne pas sous pdfLaTeX.

Codage d’entrée. XeTeX et LuaTeX sont nativement Unicode en interne et acceptent la source UTF-8 telle quelle. pdfTeX aussi utilise l’UTF-8 comme codage d’entrée par défaut depuis la version LaTeX de 2018, si bien que \usepackage[utf8]{inputenc} n’est plus nécessaire — mais en interne il projette encore sur des codages de fontes 8 bits comme T1, de sorte que les caractères disponibles dépendent de votre fontenc et de votre fonte, et qu’on ne peut pas taper n’importe quel Unicode ni du CJK. Pour saisir sans peine du texte multilingue et des symboles, XeTeX et LuaTeX ont l’avantage.

Compatibilité des packages. C’est l’écueil le plus souvent manqué en pratique. Certains packages sont propres à un moteur. fontspec et unicode-math sont réservés à XeTeX/LuaTeX. À l’inverse, pstricks fonctionne sous pdfLaTeX et XeLaTeX, qui passent par le DVI, mais en règle générale pas sous LuaLaTeX. L’incompatibilité joue aussi en sens inverse : une source rédigée d’après un vieux tutoriel peut ne pas compiler sur un moteur plus récent. La règle d’or est de vérifier avant tout quel moteur exige votre modèle ou la classe de la revue.

Vitesse. L’écart est réel et perceptible. L’ordre est pdfTeX le plus rapide, XeTeX au milieu, LuaTeX le plus lent — mais l’écart se creuse dans la part qui croît avec la quantité de composition, non au démarrage. Sur un document d’une page quasi vide, les trois sont presque indiscernables ; à quelques centaines de pages, LuaLaTeX demande plusieurs fois le temps de pdfLaTeX (les mesures figurent sur la page LuaTeX). Sur les centaines de recompilations d’une vraie session de rédaction, cela s’additionne. À l’inverse : pour un article d’une douzaine de pages, cela ne mérite pas d’inquiétude.

Micro-typographie (microtype). Ce qui rehausse sûrement l’aspect du texte occidental, ce sont le débord des caractères (protrusion) et la dilatation des fontes (expansion) de microtype. Les différences entre moteurs sont ici notables, et le README de microtype les énonce sans détour : le débord opère sur les trois — pdfTeX, LuaTeX et XeTeX —, mais la dilatation des fontes seulement avec pdfTeX et LuaTeX, pas avec XeTeX. En outre, l’ajustement des espaces inter-mots et du crénage supplémentaire est réservé à pdfTeX, tandis que la désactivation des ligatures et l’interlettrage réclament pdfTeX ou LuaTeX. Si le fini occidental prime, pdfLaTeX, puis LuaLaTeX, est le choix sûr.

Illustrations et programmabilité. L’import de PNG, JPEG et PDF s’écrit à peu près de la même façon sur tous les moteurs, via graphicx et \includegraphics (pdfLaTeX convertit l’EPS pour vous). Ce qui les sépare, c’est le contrôle depuis Lua propre à LuaTeX : on peut s’accrocher aux étapes de la composition, ou lire des données externes pour construire un tableau — choses malaisées à écrire en macros. Il s’accorde aussi avec l’écosystème moderne, fontspec et unicode-math compris, ce qui fonde l’idée qu’il est « prêt pour l’avenir ».

Les quatre options côte à côte

Voici les quatre options principales disposées selon les axes décisifs ; la première colonne donne la commande réellement tapée, et microtype est scindé entre débord et dilatation. Prenez ce tableau pour un guide, non pour un verdict — pdfLaTeX, associé à \usepackage[T1]{fontenc} et à un bon package de fontes occidentales, compose superbement bien des langues européennes, et le débord opère aussi sous XeLaTeX. À lire moins comme un « peut / ne peut pas » que comme un équilibre entre effort et finition.

Trancher avec un petit fichier d’essai

Avant de commencer à rédiger, faites tourner les moteurs candidats sur un fichier d’essai d’une page. Changer de moteur au milieu d’une thèse ou d’une soumission déplace d’un coup fontes, figures, bibliographie et coupures de ligne, et masque la cause de tout incident. Ce qu’on vérifie n’est pas seulement la compilation. Regardez les avertissements du journal, l’incorporation des fontes dans le PDF, le rendu des figures, et la capacité d’un collaborateur à reproduire les mêmes étapes — ces quatre points.

# 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

• S’il existe un modèle imposé, testez avec ce modèle. Qu’un fichier vide compile ne prouve rien sur la configuration de soumission.
• Incluez une figure, une équation hors texte et une référence bibliographique. Un essai qui n’est pas une miniature du vrai manuscrit ne teste rien.
• Vérifiez en même temps les outils de bibliographie et d’index. BibTeX ou Biber, mendex ou upmendex : le réglage de latexmk en dépend. Fixer le moteur ne suffit pas — si ces pièces ne s’emboîtent pas, la compilation échoue quand même.
• Une fois le choix fait, inscrivez le moteur dans .latexmkrc ou le README, pour que nul ne compile ensuite le projet avec un autre par mégarde.
• Comparez les PDF. Si les coupures de ligne ou les fontes diffèrent, laissez dans le projet la raison du choix.

Ce qui casse quand on change de moteur

Une source identique peut donner un résultat différent dès que le moteur change. Voici les quatre mines sur lesquelles on marche vraiment.

La configuration des fontes et du codage change. Les incontournables de pdfLaTeX que sont \usepackage[utf8]{inputenc} et \usepackage[T1]{fontenc} sont inutiles sous XeLaTeX et LuaLaTeX, et normalement omis — ces moteurs sont Unicode en interne. On emploie fontspec et \setmainfont à la place. Transporter tel quel un préambule pdfLaTeX peut produire des avertissements ou des erreurs liées aux fontes.

% 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 n’agit pas de la même façon. Le même \usepackage{microtype} produit des effets différents selon le moteur — sous XeLaTeX, la dilatation des fontes est purement et simplement désactivée. Une mise en page réglée sous pdfLaTeX se décale donc légèrement au transfert : longueurs de lignes et points de coupure changent. Sur un document de quelques dizaines de pages, il n’est pas rare que la pagination bouge d’une unité.

L’ensemble des packages utilisables change. Certains cessent de fonctionner sur le moteur cible, d’autres deviennent disponibles pour la première fois. Les figures tracées avec PSTricks ne tourneront pas si on les porte sous LuaLaTeX, qui ne prend pas en charge pstricks ; inversement, fontspec et unicode-math sont indisponibles sous pdfLaTeX. Les modèles de revues et d’éditeurs supposent en général un moteur précis : s’y conformer d’abord est le geste sûr.

En japonais, toute la configuration des fontes CJK change. upLaTeX (la famille pTeX) et LuaLaTeX avec luatexja diffèrent tant dans la désignation des fontes japonaises que dans leur incorporation. Prévoyez plus de douleur pour une migration japonaise que pour une migration occidentale. Les équivalences concrètes de commandes sont réunies sur la page « Commandes de compilation ».