Convertisseurs DVI

Vous tapez latex et aucun PDF n’apparaît. Rien n’est cassé : la plus ancienne commande de LaTeX écrit du DVI, pas du PDF, et tout ce qui suit revient à un convertisseur DVI — dvipdfmx, dvips, dvisvgm. Le format remonte loin : le source de DVItype, écrit par Knuth, note que le premier programme DVItype a été conçu par David Fuchs en 1979, plus de dix ans avant l’existence du PDF. Pourtant la route en deux temps survit à une époque où pdflatex produit directement du PDF, et pour des raisons bien concrètes. Cette page décrit ce que chaque convertisseur de TeX Live 2024 consomme et produit, pourquoi la chaîne japonaise uplatex → dvipdfmx reste la référence, et comment lire les erreurs qui surgissent à l’étape de conversion.

Pourquoi passer par DVI alors que pdflatex existe

DVI — device independent — est un format intermédiaire qui ne transporte que des instructions : place ce caractère de cette fonte à cette position sur cette page. Il n’incorpore aucun fichier de fonte, ignore la couleur et les images. Cette légèreté est tout l’enjeu. TeX se concentre sur la composition et confie à un convertisseur tout ce qui relève du périphérique de sortie ; une décision de conception de 1979 ouvre encore aujourd’hui la sortie vers PostScript, PDF et SVG. DVI ne survit donc pas seulement par compatibilité. pdflatex ne sait écrire que du PDF, alors qu’un seul fichier DVI se ramifie dans trois directions. De plus, la famille PSTricks fonctionne au moyen d’instructions \special qui supposent un interpréteur PostScript quelque part dans la chaîne, et latex → dvips est la façon directe de lui en fournir un. Quant aux moteurs japonais de la famille pTeX, ils n’ont aucune implémentation produisant directement du PDF.

dvipdfmx, xdvipdfmx et extractbb sont un seul et même programme

En regardant dans le répertoire bin de TeX Live 2024, on découvre que dvipdfmx, dvipdfm, extractbb et ebb sont tous des liens symboliques vers xdvipdfmx. C’est un seul exécutable sous cinq noms, et le programme regarde sous quel nom il a été appelé avant de décider de son comportement. dvipdfmx --version s’annonce « This is dvipdfmx Version 20240305 » ; xdvipdfmx --version donne la même date sous le nom xdvipdfmx. Même fichier. Une fois cela compris, le versant XeTeX s’éclaire aussi : xelatex -no-pdf n’écrit pas un PDF mais un .xdv (DVI étendu), que xdvipdfmx transforme en PDF — et comme c’est le même binaire, dvipdfmx sample.xdv fonctionne tout aussi bien. L’ancêtre dvipdfm a été écrit par Mark A. Wicks ; l’extension en dvipdfmx, avec prise en charge CJK, incorporation de fontes et flux d’objets, est l’œuvre de Jin-Hwan Cho, Shunsaku Hirata et d’autres.

ls -l $(dirname $(which dvipdfmx))/dvipdfmx
# dvipdfmx -> xdvipdfmx

dvipdfmx sample.dvi            # sample.dvi -> sample.pdf
dvipdfmx -p a4 -o out.pdf sample.dvi
xelatex -no-pdf paper.tex      # writes paper.xdv, not paper.pdf
xdvipdfmx paper.xdv            # paper.xdv -> paper.pdf

Devant ! LaTeX Error: Cannot determine size of graphic, soupçonnez l’option de pilote

Dès qu’on insère une figure dans la route DVI, c’est la première erreur rencontrée : ! LaTeX Error: Cannot determine size of graphic in fig.pdf (no BoundingBox). La cause n’est pas le fichier image mais le pilote pour lequel graphicx est configuré. Dans TeX Live 2024, graphics.cfg choisit par défaut dvips.def pour toute exécution qui écrit du DVI, et dvips ne sait incorporer que du PostScript : il n’a aucun moyen de lire la taille d’un PDF ou d’un PNG. Avec \usepackage[dvipdfmx]{graphicx} dans le préambule, sur cette installation, PDF et PNG passent directement sans fichier supplémentaire. À l’essai, latex a repris les figures sans le moindre fichier .xbb et sans shell escape, et dvipdfmx les a incorporées. Pour une image ancienne dont la taille reste indéterminable, lancez extractbb fig.pdf ; le .xbb produit tient en quelques lignes de texte, par exemple %%BoundingBox: 0 0 612 792 — et, d’après le lien symbolique ci-dessus, c’est dvipdfmx lui-même qui l’écrit.

% name the driver explicitly on the DVI route
\documentclass{article}
\usepackage[dvipdfmx]{graphicx}
\begin{document}
\includegraphics[width=3cm]{fig.pdf}
\end{document}

dvips : la route qui subsiste pour ce que seul PostScript sait faire

dvips -o paper.ps paper.dvi transforme le DVI en PostScript. C’est le programme de Tomas Rokicki, mais la ligne d’auteur de sa page de manuel indique « extended to virtual fonts by Don Knuth », avec la recherche de chemins et la configuration dues à Karl Berry — un travail véritablement collectif. Aujourd’hui, trois raisons subsistent d’y recourir : les figures qui reposent sur l’arithmétique PostScript, PSTricks en tête ; un imprimeur qui réclame un .ps ; et l’extraction d’une figure unique par dvips -E, qui écrit un EPS dont la boîte englobante colle au contenu réel (ici %%BoundingBox: 148 88 326 668). S’il faut un PDF au bout, la finition habituelle passe par ps2pdf, fourni avec Ghostscript.

dvips -t a4 -o paper.ps paper.dvi   # DVI -> PostScript
ps2pdf paper.ps                     # PostScript -> PDF (Ghostscript)
dvips -E -o figure.eps figure.dvi   # one tightly cropped EPS

Voici le piège qui coûte une journée entière quand on ne le connaît pas. N’envoyez pas d’images bitmap sur la route dvips. Avec le pilote resté à dvips, \includegraphics{dot.png} s’arrête sur l’erreur no BoundingBox ci-dessus ; forcez le passage — en fournissant un .xbb à la main, par exemple — et ni LaTeX ni dvips ne dit plus rien : un fichier .ps est bel et bien écrit. La casse est en aval. En passant ce .ps à ps2pdf, Ghostscript a affiché ici Error: /syntaxerror in (binary token, type=137) puis s’est arrêté sur GPL Ghostscript 10.03.0: Unrecoverable error, exit code 1. PostScript ne sait tout simplement pas ce qu’est un PNG, ce qui se comprend ; le pénible, c’est que rien ne proteste jusqu’à l’ultime étape. Donc : avec dvips, gardez toutes les figures en EPS. Pour mélanger PNG, JPEG et PDF, prenez la route dvipdfmx. Cette seule ligne suffit à décider.

dvisvgm : des formules en SVG, et comment le format de fonte change la taille

Mettre des mathématiques sur le Web, c’est d’ordinaire choisir entre une image matricielle qui se brouille au zoom et du MathML qui s’affiche différemment partout. dvisvgm — de Martin Gieseking, développé depuis 2005 — convertit le DVI directement en SVG, de sorte que la composition de TeX survit sous forme vectorielle. La version présente ici dans TeX Live 2024 est dvisvgm 3.2.2 ; elle accepte aussi l’EPS avec --eps et le PDF avec --pdf. L’option décisive est --font-format. En convertissant la même page et en mesurant : 13 156 octets avec les fontes SVG incorporées par défaut, 8 361 octets avec --font-format=woff2, et — en sens inverse — 23 563 octets avec --no-fonts, qui transforme chaque glyphe en tracé. Le fichier vectorisé ne contient en outre aucun élément <text> : impossible d’y chercher ou d’y copier du texte. « Les contours sont plus légers » ne tient pas ici.

latex equation.tex                        # -> equation.dvi
dvisvgm --font-format=woff2 equation.dvi  # -> equation.svg
dvisvgm --pdf figure.pdf                  # PDF input
dvisvgm --libgs=/path/to/libgs.dylib f.dvi  # only if PS specials are used

Un autre message alimente un flot constant de signalements : processing of PostScript specials is disabled (Ghostscript not found) — sur une machine où Ghostscript est pourtant installé. C’est exactement le cas ici : gs se trouve dans /usr/local/bin/gs, et dvisvgm le dit quand même. La raison : il cherche autre chose. dvisvgm n’exécute pas le binaire gs ; il charge à l’exécution la bibliothèque partagée libgs. Le Ghostscript livré avec MacTeX n’installe que l’exécutable, la bibliothèque reste donc introuvable. Pour convertir des figures qui utilisent \special — PSTricks, certaines sorties TikZ —, installez un Ghostscript fournissant la bibliothèque partagée, ou indiquez-la avec --libgs=. Pour un DVI ne contenant que des mathématiques et des \includegraphics, l’avertissement peut être ignoré.

La route japonaise uplatex → dvipdfmx et ptex2pdf

Si la route DVI survit dans la composition japonaise, c’est par nécessité, non par nostalgie. Les moteurs de la famille pTeX — ptex, eptex, uptex, uplatex — ne savent pas écrire de PDF directement. Écriture verticale, interdictions de coupure, espacement entre écriture japonaise et latine : tout cela appartient à pTeX, tandis que dvipdfmx se charge de fabriquer le PDF et d’incorporer les fontes japonaises. Quarante ans de travail se sont accumulés de part et d’autre de ce partage. La procédure comporte donc toujours deux étapes : uplatex paper.tex produit le .dvi, et dvipdfmx paper.dvi produit le PDF. Nommer aussi le pilote dans le document, comme dans \documentclass[uplatex,dvipdfmx]{jsarticle}, est ce qui fait écrire à graphicx et color les bonnes instructions \special.

Réunir ces deux étapes en une seule commande, c’est le rôle de ptex2pdf. La version présente dans TeX Live 2024 est 20200520.0, un script texlua de texjporg — la communauté japonaise de développement TeX — et de Norbert Preining ; la commande elle-même est un lien symbolique vers texmf-dist/scripts/ptex2pdf/ptex2pdf.lua, et elle appelle dvipdfmx automatiquement une fois le moteur terminé. Le moteur se choisit en combinant des options, et upLaTeX, standard pour les articles japonais, correspond à -l -u. Les options fines vont au moteur TeX avec -ot et à dvipdfmx avec -od. Ce que ptex2pdf ne fait pas, c’est compter les passes de compilation : pour un document avec renvois ou bibliographie, mieux vaut confier la tâche à latexmk.

# the two steps, written out
uplatex paper.tex          # -> paper.dvi
dvipdfmx paper.dvi         # -> paper.pdf

# the same thing in one command
ptex2pdf -l -u -ot '-kanji=utf8 -synctex=1' paper.tex
ptex2pdf -l -u -s paper.tex   # stop at the DVI

# what to check when the converter fails
dvipdfmx nosuch.dvi
# dvipdfmx:fatal: Could not open specified DVI (or XDV) file: nosuch.dvi
# No output PDF file written.

Les erreurs de l’étape de conversion et leur signification

Les vérifications avant remise diffèrent elles aussi selon la route. Si vous rendez un PDF, ouvrez-le après dvipdfmx dans le lecteur qu’utiliseront vos lecteurs et contrôlez fontes incorporées, format papier, signets et liens. S’il part chez un imprimeur, comparez le .ps de dvips avant et après ps2pdf pour vérifier que les fichiers EPS et les instructions \special PostScript ont survécu. Et si vous comptez sur la recherche directe et inverse depuis votre éditeur, latex -synctex=1 produit un .synctex.gz sur la route DVI également — ici un fichier de 860 octets, toujours présent après le passage de dvipdfmx. Le .dvi, le .pdf et le .synctex.gz partagent le nom de travail : si les sorties vont dans un répertoire à part, faites indiquer ce chemin de façon cohérente par l’outil de build.

Cela dit, vous taperez rarement ces commandes à la suite. latexmk couvre les routes latex → dvipdfmx et (u)platex → dvipdfmx par un simple changement de $pdf_mode, et il détermine lui-même si le .dvi est périmé. La saisie manuelle sert quand on suspecte la route elle-même — c’est-à-dire dans les situations auxquelles cette page est destinée. Autrement dit : apprenez une fois les noms et les arguments des convertisseurs, et vous saurez aussi lire ce que fait votre outil de build.