Formats LaTeX

À la question « qu’est-ce que pdflatex ? », la réponse exacte n’est pas « un programme ». C’est le moteur pdfTeX lancé avec le format LaTeX préchargé. Alignés comme noms de commandes, pdflatex, lualatex et platex ont l’air de logiciels distincts ; en réalité, chacun combine deux axes indépendants — un moteur (le programme qui s’exécute) et un format (un corps de macros compilé à l’avance). Dès que ces axes apparaissent, plusieurs choses s’expliquent d’un coup : ce qu’est un fichier .fmt, pourquoi latex produit un DVI et non un PDF, et ce qu’est réellement devenu LaTeX3.

La différence entre un moteur et un format

Un moteur est un exécutable ; un format, des données. Le moteur est le programme qui lit un fichier .tex et le compose — tex, pdftex, xetex, luahbtex, euptex, etc. Un format est une vaste collection de macros comme \documentclass et \section, développée à l’avance et figée en un seul vidage : un fichier .fmt. Le moteur charge ce .fmt en un instant au démarrage et n’a donc jamais à redéfinir des dizaines de milliers de lignes de macros à chaque exécution.

Ainsi, « LaTeX » est le nom d’un format, non d’un moteur. Le même format LaTeX peut tourner sur différents moteurs, et la commande que vous tapez désigne un couple moteur + format précis. Cette correspondance n’est pas à deviner : elle existe dans TeX Live sous la forme d’un unique fichier de configuration, fmtutil.cnf. Ses quatre colonnes sont le nom du format, le moteur, le fichier de motifs de césure et les arguments ; la version de TeX Live 2024 compte 54 lignes, soit 54 combinaisons enregistrées.

$ grep -E '^(tex|latex|pdflatex|lualatex|xelatex|uplatex|amstex|pdfcsplain) ' \
      $(kpsewhich fmtutil.cnf)

# format      engine     hyphenation                 arguments
tex           tex        -                           tex.ini
latex         pdftex     language.dat                *latex.ini
pdflatex      pdftex     language.dat                *pdflatex.ini
xelatex       xetex      language.dat                -etex xelatex.ini
lualatex      luahbtex   language.dat,language.dat.lua lualatex.ini
uplatex       euptex     language.dat                *uplatex.ini
amstex        pdftex     -                           *amstex.ini
pdfcsplain    luatex     -                           csplain.ini
pdfcsplain    pdftex     -                           csplain-utf8.ini
pdfcsplain    xetex      -                           csplain.ini

Deux choses ressortent de ce tableau. D’abord, un même nom de format peut figurer face à plusieurs moteurs — pdfcsplain a trois lignes, pour luatex, pdftex et xetex. Il n’est pas de meilleure preuve que format et moteur sont orthogonaux. Ensuite, le * préfixé aux arguments : il ordonne de produire le vidage avec les extensions e-TeX activées, et l’en-tête de commentaire du fichier précise que cela équivaut pour l’essentiel à l’option -etex. La ligne latex porte ce * ; la ligne du tex de Knuth, non. La dépendance du LaTeX moderne envers e-TeX tient dans ce seul caractère.

Ce que contient réellement un fichier .fmt

C’est un vidage mémoire de tout l’état interne du moteur. Ni code source, ni texte. Définitions de macros, codes de catégorie, motifs de césure, affectations des fontes mathématiques : tout ce qui se trouve dans la mémoire du moteur à l’instant où il achève la lecture de latex.ltx est écrit tel quel en binaire. Dans TeX Live 2024, latex.fmt pèse environ 8,2 Mo. L’écart entre la relecture de ces 8,2 Mo et la réinterprétation de latex.ltx à chaque fois explique exactement pourquoi LaTeX démarre instantanément.

Il est un endroit où la relation entre moteur et format se voit dans le système de fichiers lui-même : un .fmt n’est pas rangé sous le nom du format, mais dans un répertoire portant le nom du moteur. Sous texmf-var/web2c/, TeX Live 2024 aligne les répertoires tex/, pdftex/, xetex/, luahbtex/, euptex/, chacun contenant les formats produits par ce moteur. tex/tex.fmt est plain TeX, pdftex/latex.fmt est LaTeX, euptex/uplatex.fmt est upLaTeX — même extension .fmt, mais objets différents selon le moteur qui les a construits.

# Formats are filed by ENGINE, not by format name.
$ ls /usr/local/texlive/2024/texmf-var/web2c/
aleph  euptex  hitex  luahbtex  luajittex  luatex  metafont  pdftex  tex  xetex

$ ls /usr/local/texlive/2024/texmf-var/web2c/euptex/
eptex.fmt  euptex.fmt  platex.fmt  ptex.fmt  uplatex.fmt  ...

# Ask kpathsea which .fmt a given engine would load.
$ kpsewhich -engine pdftex latex.fmt
/usr/local/texlive/2024/texmf-var/web2c/pdftex/latex.fmt

$ ls -l $(kpsewhich -engine pdftex latex.fmt)
-rw-r--r--  1 root  wheel  8221690 May  4  2024 .../pdftex/latex.fmt

Le mécanisme du côté producteur est tout aussi simple. Lancez un moteur avec -ini et il entre dans un mode d’initialisation où aucun .fmt n’est chargé. Faites-lui lire dans cet état une source comme latex.ltx, terminez par la primitive \dump, et l’état interne d’alors est écrit sous forme de .fmt. initex, jadis exécutable distinct, n’est rien d’autre qu’un nom pour ce démarrage -ini et ne survit plus que comme lien symbolique vers tex.

Reconstruire un format avec fmtutil

La commande qui reconstruit un .fmt est fmtutil. Elle lit fmtutil.cnf et regénère chaque format avec le moteur et les arguments qui y figurent. Elle s’exécute normalement toute seule lors de la mise à jour de la distribution, si bien qu’on l’appelle rarement à la main — mais lorsque le remplacement d’un fichier du noyau ou d’un motif de césure ne produit aucun effet, la cause est presque toujours un format périmé. Les deux formes réellement utiles sont fmtutil-sys --all (tout reconstruire) et fmtutil-sys --byfmt latex (un seul).

# Rebuild one format (writes into the system tree; needs write permission).
$ fmtutil-sys --byfmt latex

# Rebuild every format listed in fmtutil.cnf.
$ fmtutil-sys --all

# Rebuild only the formats that use a given engine.
$ fmtutil-sys --byengine luahbtex

# Personal tree instead of the system tree (no root needed).
$ fmtutil-user --byfmt pdflatex

# Where did the format end up, and when was it built?
$ kpsewhich -engine pdftex latex.fmt

La différence entre -sys et -user tient au lieu d’écriture : l’arbre système (TEXMFSYSVAR) ou l’arbre propre à l’utilisateur (TEXMFVAR). Avec des droits d’administration, -sys est le choix évident ; -user sert à ne remplacer que sa propre copie sur une machine partagée. Mélanger les deux produit à coup sûr le fameux « je l’ai pourtant corrigé et rien ne change » : mieux vaut fixer l’un des deux pour tout le projet. Notez encore que fmtutil.cnf relève de la distribution — son commentaire d’en-tête indique clairement que toute modification manuelle y sera perdue à la mise à jour. Pour un changement durable, passer par la voie prévue, comme fmtutil-sys --enablefmt.

LaTeX2e : le format qui tourne réellement sur votre machine

Aujourd’hui, « LaTeX » désigne presque toujours LaTeX2e. C’est la version courante des macros LaTeX écrites par Leslie Lamport, parue en 1994 et désormais maintenue par le LaTeX Project. Le « 2e » signalait une petite révision du LaTeX 2.09 antérieur — à l’époque, une étape intermédiaire vers le LaTeX3 longtemps annoncé. On peut vérifier soi-même le format dont on dispose : le fichier noyau latex.ltx se déclare par \def\fmtname{LaTeX2e}, et dans l’exemplaire livré avec TeX Live 2024, \fmtversion vaut 2023-11-01 avec \patch@level 1.

Le noyau est désormais mis à jour selon une cadence régulière d’environ deux publications par an. Retenir « la dernière version » sous forme de numéro ne sert à rien : elle se périme en quelques mois. Prenez plutôt l’habitude de lire \fmtversion dans latex.ltx de votre propre installation : c’est la date du noyau effectivement produit là. Pour qui veut essayer la prochaine version en avance, TeX Live fournit en parallèle des formats de développement. fmtutil.cnf comporte des lignes latex-dev, pdflatex-dev, xelatex-dev, lualatex-dev et uplatex-dev ; pdflatex-dev main.tex compose donc avec le noyau à venir. Cela sert à tester la compatibilité des classes et packages, pas à produire un manuscrit définitif.

Ce qu’est devenu LaTeX3 : la réponse s’appelle expl3

Un format LaTeX3 n’a jamais vu le jour. Ce qui a vu le jour, c’est le langage de programmation de LaTeX3. Cette couche, nommée expl3 (L3 programming layer), n’est pas arrivée comme un nouveau noyau distinct mais absorbée à l’intérieur de LaTeX2e. La question « faut-il migrer vers LaTeX3 ? » reste donc sans réponse — non faute de destination, mais parce que vous l’utilisez déjà.

Le tournant est consigné. LaTeX News 31 (2 février 2020) relevait qu’expl3 était passé, au cours de la décennie précédente, de largement expérimental à globalement stable, et rapportait que, dans cette version, l’équipe avait ajusté le noyau pour précharger une part importante d’expl3 lors de la construction du format. Le motif était la vitesse : les documents chargeant fontspec sous XeLaTeX ou LuaLaTeX payaient à chaque exécution un lourd tribut à la lecture des données Unicode.

expl3 fait désormais partie du format. En lisant le fichier noyau latex.ltx, on voit la logique à l’œuvre : si expl3 est déjà là, il annonce Skipping: expl3 code already part of the format et poursuit ; sinon il le charge par \input expl3.ltx ; et si expl3.ltx reste introuvable, il s’arrête sur \errmessage{LaTeX requires expl3}. Autrement dit, expl3 n’est plus un package facultatif mais un composant requis de LaTeX2e. Écrire \RequirePackage{expl3} dans un document ou un package reste recommandé par égard pour les formats anciens, mais ne fait pratiquement rien sur un format récent. La syntaxe d’expl3 elle-même — \ExplSyntaxOn, \cs_new:Npn, les variables typées de l3kernel — dispose de sa propre page.

Les formats autres que LaTeX

LaTeX est le format le plus répandu, mais pas le seul. Sur les 54 lignes de fmtutil.cnf, quelques-unes seulement relèvent de LaTeX ; les autres sont d’autres systèmes de macros. amstex mérite ici un mot. En tant qu’exécutable, amstex n’est qu’un lien symbolique vers pdftex, et la ligne amstex pdftex - *amstex.ini de fmtutil.cnf désigne le moteur pdfTeX chargé des macros AMS-TeX. AMS-TeX est le jeu de macros de l’American Mathematical Society pour la composition mathématique, bâti sur plain TeX, et pour qui utilise LaTeX, il a de fait été remplacé par le package amsmath. Commencer un nouveau document en AMS-TeX n’a guère de raison d’être.

pLaTeX et upLaTeX : le format LaTeX pour le japonais

pLaTeX et upLaTeX posent le format LaTeX sur des moteurs conçus pour la composition japonaise. L’écriture verticale, les ruby (furigana) et la composition des lignes japonaises sont l’affaire de la famille de moteurs pTeX, étendue à l’origine chez ASCII Corporation. Dans le fmtutil.cnf de TeX Live 2024, platex comme uplatex sont inscrits face au moteur euptex ; ce qui les sépare, c’est le fichier d’initialisation du format (*platex.ini contre *uplatex.ini). La différence ne tient donc pas à l’exécutable mais à la façon dont le format traite les caractères : platex conserve le comportement compatible pTeX traditionnel, tandis qu’uplatex suppose Unicode en interne. Pour un nouveau document japonais, uplatex est le choix standard.

Cette famille produit toujours du DVI, et le DVI porteur de japonais est converti en PDF par dvipdfmx — une chaîne en deux temps (uplatex file.tex, puis dvipdfmx file.dvi). On y adjoint upmendex pour l’index. Comme classes de document, les jsarticle et jsbook de Haruhiko Okumura (pour pLaTeX) et leurs équivalents Unicode comme ujarticle sont courants, tout comme le plus récent jlreq, conforme aux exigences de composition japonaise de la norme JIS X 4051. Les détails internes des moteurs — métriques JFM, règles de césure kinsoku, mise en œuvre de l’écriture verticale — relèvent de la page « famille pTeX ».

Quelle commande correspond à quel appariement

Même avec un format LaTeX identique, le nom de la commande fixe le moteur sous-jacent, le format de sortie et le traitement des fontes. Lisez le tableau ci-dessous en partant du nom de commande, de gauche à droite. En pratique, c’est la colonne de droite qui pèse le plus : la disponibilité de fontspec recoupe directement le choix du moteur.

# Engines that write PDF finish in one step.
$ pdflatex main.tex      # -> main.pdf
$ lualatex main.tex      # -> main.pdf
$ xelatex  main.tex      # -> main.pdf

# DVI-based routes add a conversion step.
$ latex    main.tex      # -> main.dvi   (pdfTeX in DVI mode)
$ uplatex  main.tex      # -> main.dvi   (Japanese)
$ dvipdfmx main.dvi      # -> main.pdf

Lire la première ligne du journal, puis figer l’appariement

La première ligne du journal nomme à la fois le moteur et le format. Décomposez This is pdfTeX, Version 3.141592653-2.6-1.40.26 (TeX Live 2024) (preloaded format=latex) : la première moitié est le moteur et sa version, et (preloaded format=...) le format chargé. This is LuaHBTeX ..., This is XeTeX ... et This is e-upTeX ... se lisent pareillement. Quand un collaborateur signale « même commande, sortie différente », la comparaison de cette seule ligne distingue aussitôt un problème de configuration d’éditeur d’une différence de millésime TeX Live ou de format.

Et une fois l’appariement arrêté, consignez-le dans le projet et figez-le. Pour une thèse : dès que la page de titre, la table des matières, les figures, les tableaux et la bibliographie passent, notez la commande dans le README ou dans .latexmkrc. Faire passer un document de lualatex à uplatex en cours de route change d’un coup le choix des fontes, le traitement du japonais, la route vers le PDF et souvent le traitement bibliographique. S’il faut vraiment changer, vérifiez toutes les fonctionnalités sur un petit fichier d’essai avant de revenir au manuscrit réel. Les critères de choix — vitesse, compatibilité des packages, situation du japonais — sont réunis sur la page « Choisir un moteur ».