Outils de polices et de bases de données

Vous avez installé une fonte et LaTeX ne la trouve pas. Cette page existe pour répondre à cette seule phrase. Le point délicat : chaque moteur cherche les fontes d’une manière entièrement différente. pdflatex ne consulte jamais les fontes du système ; il ne fait confiance qu’aux maps de fontes construites par updmap. XeTeX interroge la machinerie de fontes du système d’exploitation. LuaTeX consulte une base Lua qui lui est propre, construite par luaotfload. « Elle apparaît dans fc-list mais je ne peux pas m’en servir » n’a donc rien de contradictoire : vous regardez simplement un autre des trois mécanismes. La suite classe fc-list, fc-cache, updmap, kanji-config-updmap, luaotfload-tool et fmtutil selon la couche que chacun répare.

Comment un moteur trouve une fonte : trois mécanismes distincts

Cette division en trois n’est que la différence d’époque entre les moteurs, conservée telle quelle. pdfTeX descend du TeX des années 1980, quand le système d’exploitation n’avait pas la moindre notion de catalogue de fontes. La correspondance entre un nom logique côté TeX — une chaîne comme ptmr8r — et un fichier réel est donc consignée dans une table appelée map de fontes, que updmap assemble. XeTeX, à partir de 2004, a été conçu pour s’appuyer directement sur la machinerie de fontes du système : un otool -L sur le binaire xetex de la version macOS de TeX Live 2024 montre CoreText parmi les bibliothèques liées. LuaTeX, lui, résout les noms en Lua en consultant la base construite par luaotfload. Écrivez le même \setmainfont{...} : selon le moteur, cette ligne interroge trois autorités différentes.

fc-list et fc-cache ne sont pas des commandes TeX Live

Se tromper sur ce point fausse tout le raisonnement qui suit. fc-list, fc-cache et fc-match appartiennent à fontconfig, un projet distinct, et ne font pas partie de TeX Live. On peut fouiller le répertoire bin de TeX Live 2024 de bout en bout : aucun exécutable ne commence par fc- ; ceux présents sur ce Mac ont été installés par Homebrew sous la forme de fontconfig 2.18.2. Ils restent utiles, car ils disent quelles fontes le système possède et où sont les fichiers. fc-list : family n’affiche que les noms de familles, fc-list -f un format choisi comme file, family et style. Sur cette machine, la liste comptait 2 799 entrées.

fc-list : family | sort -u | wc -l         # how many families the system offers
fc-list -f '%{file}\n' :family=Menlo        # where the file actually is
fc-cache -fv ~/Library/Fonts               # rebuild the fontconfig cache

fc-match "NoSuchFontXYZ"
# Verdana.ttf: "Verdana" "Regular"          <- a substitute, not an error

Un piège attend ici, et tout le monde y tombe une fois. fc-match ne dit jamais « introuvable ». Donnez-lui un nom inexistant et fontconfig renvoie quand même quelque chose : ici, fc-match "NoSuchFontXYZ" a répondu Verdana.ttf: "Verdana" "Regular". C’est une substitution, pas une confirmation. Utilisez fc-match pour vérifier qu’une fonte est installée et il répondra toujours oui. Pour trancher vraiment, comparez le nom de famille renvoyé à celui demandé, ou restreignez avec fc-list. Sur macOS, une seconde mise en garde : comme le montrait la section précédente, xetex regarde CoreText, donc figurer dans fc-list ne garantit pas que XeTeX puisse utiliser la fonte. À l’inverse, sur les builds où XeTeX cherche bien via fontconfig — typiquement TeX Live sous Linux —, lancer fc-cache après avoir déposé une fonte dans son répertoire personnel est exactement le bon geste.

updmap : ce que dit vraiment une ligne de map de fontes

Une map de fontes est du texte brut, une ligne par lien entre un nom logique TeX et un fichier réel. updmap n’écrit pas ces lignes lui-même : il concatène les fichiers .map énumérés dans updmap.cfg en psfonts.map pour dvips et pdftex.map pour pdftex et dvipdfmx. En comptant updmap-sys --listmaps sur cette machine, on obtient 389 déclarations : 332 Map, 46 MixedMap, 11 KanjiMap. Le psfonts.map concaténé est un fichier texte unique de 45 672 lignes, près de 5,5 Mo. Une ligne se lit ainsi : le nom côté TeX, le nom de fonte PostScript, une instruction de réencodage, puis les fichiers réels.

# one real line out of psfonts.map on this machine
ptmr8r NimbusRomNo9L-Regu " TeXBase1Encoding ReEncodeFont " <8r.enc <utmr8a.pfb

updmap-sys --listmaps            # every declared map, and which cfg declared it
sudo updmap-sys --enable Map myfont.map
sudo updmap-sys                  # rebuild psfonts.map and pdftex.map

Ce qui fait trébucher en pratique, c’est rarement la commande, mais la configuration que l’on touche. Dans TeX Live 2024, updmap nu refuse de s’exécuter : il répond updmap [ERROR]: Either -sys or -user mode is required. puis updmap [ERROR]: In nearly all cases you should use updmap -sys. Ce refus est une bienveillance, car le vrai piège se trouve juste derrière. La sortie de updmap --help le dit franchement : dès que updmap-user a été lancé ne serait-ce qu’une fois, exécuter updmap-sys n’a plus aucun effet. Un fichier de configuration personnel apparaît et prend désormais le pas. Sur les machines partagées et en CI, standardisez sur updmap-sys, et ne recourez à updmap-user que si vous voulez sciemment remplacer les réglages système. Le sudo est nécessaire parce que tout ce qui se trouve sous /usr/local/texlive/2024 appartient à root.

kanji-config-updmap : choisir la fonte japonaise incorporée

Si le choix de la fonte japonaise a sa propre commande, ce n’est pas un hasard. Sur la route pLaTeX et upLaTeX, la fonte japonaise incorporée au PDF n’est pas décidée à la composition mais à l’étape dvipdfmx. On peut donc remplacer après coup la fonte incorporée sans toucher au manuscrit ; kanji-config-updmap, de texjporg, est ce commutateur, et il règle en interne l’option jaEmbed de updmap, autrefois nommée kanjiEmbed. Commencez par status. Sur cette machine, la réponse a été CURRENT family for ja: haranoaji (variant: -04), suivie de ipa et ipaex parmi les familles en attente. Pour changer, passez directement le nom de famille. Comme pour updmap, il existe une forme -sys et une forme -user ; sur les machines partagées, kanji-config-updmap-sys est le choix sûr.

kanji-config-updmap-sys status
# CURRENT family for ja: haranoaji (variant: -04)
# Standby family : ipa
# Standby family : ipaex

sudo kanji-config-updmap-sys ipaex   # embed the IPAex family instead
sudo kanji-config-updmap-sys auto    # let it pick from what is installed

luaotfload-tool : pourquoi la première exécution de LuaTeX est lente

Ce qui surprend lors de la première exécution de LuaLaTeX, c’est l’attente. La cause est la base de noms de luaotfload, construite en parcourant les fichiers de fontes du système pour associer noms et fichiers. Sur cette machine, elle se trouve dans TEXMFVAR/luatex-cache/generic/names/luaotfload-names.luc.gz et pèse environ 390 Ko. Le détail intéressant : une recherche infructueuse déclenche d’elle-même une reconstruction. Donnez à \setmainfont un nom inexistant et le journal affiche luaotfload | db : Reload initiated (formats: otf,ttf,ttc); reason: Font "NoSuchFontXYZ" not found. avant de s’arrêter sur ! Package fontspec Error: The font "NoSuchFontXYZ" cannot be found. Ainsi, « LuaLaTeX ne voit pas la fonte que je viens d’installer » se règle généralement en relançant une fois. Pour forcer les choses, luaotfload-tool --update reconstruit la base et, quand il n’y a rien au départ, annonce Font names database not found, generating new one. puis This can take several minutes; please be patient.

luaotfload-tool --update              # rebuild the LuaTeX names database
luaotfload-tool --diagnose=environment # what luaotfload thinks its world looks like
ls "$(kpsewhich --var-value=TEXMFVAR)/luatex-cache/generic/names/"

fmtutil : reconstruire le .fmt chargé au démarrage du moteur

Quand on lance pdflatex, le moteur charge d’abord un fichier de format comme latex.fmt avant de faire quoi que ce soit. Ce fichier est un instantané de tout l’état interne du moteur au moment où il venait de lire l’intégralité de LaTeX — l’astuce qui lui permet de démarrer sans relire des milliers de lignes de macros à chaque fois. fmtutil reconstruit ces fichiers .fmt. Le besoin est rare : seulement après une mise à jour touchant un format, ou lorsqu’un .fmt est abîmé et que le moteur s’arrête avant même de démarrer. Ce n’est pas à lancer après chaque installation de package. Pour un seul format, fmtutil-sys --byfmt pdflatex ; pour tous, fmtutil-sys --all, qui prend plusieurs minutes. La distinction -sys / -user fonctionne exactement comme pour updmap, et les machines partagées s’en tiennent à -sys.

sudo fmtutil-sys --byfmt pdflatex   # rebuild one format
sudo fmtutil-sys --all              # rebuild every format (several minutes)
kpsewhich --var-value=TEXMFVAR      # where the .fmt files end up

Quelle commande pour quel symptôme

Pour finir, un petit outil en marge de cette carte. TeX Live fournit une commande nommée albatross, que sa page de manuel présente comme un outil pour trouver les fontes contenant un glyphe Unicode donné — et qui s’appuie en interne sur fontconfig, encore un endroit où un outil du monde TeX fait appel à fontconfig. Son lancement ici s’est toutefois arrêté sur Unable to locate a Java Runtime. Il exige un environnement d’exécution Java ; installez-le séparément si vous y tenez. mktexlsr et texhash, ainsi que kpsewhich, sont traités en détail sur la page des outils de build.