Herramientas de fuentes y bases de datos

Has instalado una fuente y LaTeX no la encuentra. Esta página existe para responder a esa única frase. Lo incómodo es que cada motor busca las fuentes de un modo completamente distinto. pdflatex no consulta jamás las fuentes del sistema; solo confía en los mapas de fuentes que construye updmap. XeTeX pregunta a la maquinaria de fuentes del sistema operativo. LuaTeX consulta una base de datos Lua propia que construye luaotfload. Así que «aparece en fc-list pero no puedo usarla» no es contradictorio: simplemente estás mirando otro de los tres mecanismos. Lo que sigue ordena fc-list, fc-cache, updmap, kanji-config-updmap, luaotfload-tool y fmtutil según la capa que repara cada uno.

Cómo encuentra un motor una fuente: tres mecanismos separados

La división en tres no es más que la diferencia de época entre los motores, conservada intacta. pdfTeX desciende del TeX de los años ochenta, cuando el sistema operativo no tenía la menor noción de catálogo de fuentes. Por eso la correspondencia entre un nombre lógico de TeX —una cadena como ptmr8r— y un archivo real se anota en una tabla llamada mapa de fuentes, y updmap es quien la ensambla. XeTeX, desde 2004, se diseñó para colgar directamente de la maquinaria de fuentes del sistema: al ejecutar otool -L sobre el binario xetex de la compilación para macOS de TeX Live 2024 aparece CoreText entre las bibliotecas enlazadas. LuaTeX resuelve los nombres en Lua consultando la base que construye luaotfload. Escribe el mismo \setmainfont{...}: según el motor, esa línea pregunta a tres autoridades distintas.

MotorCómo busca una fuenteOrden que lo repara
pdftexIgnora por completo las fuentes del sistema; resuelve nombres lógicos .tfm mediante un mapaupdmap-sys
xetexPregunta al sistema operativo; la compilación de macOS está enlazada con CoreTextel gestor de fuentes del sistema
luatexResuelve nombres en Lua consultando la base de nombres que construye luaotfloadluaotfload-tool --update
dvipdfmxNo compone, incrusta: el mapa decide qué fuentes entran en el PDFupdmap-sys / kanji-config-updmap-sys

fc-list y fc-cache no son órdenes de TeX Live

Equivocarse aquí desbarata todos los razonamientos posteriores. fc-list, fc-cache y fc-match pertenecen a fontconfig, un proyecto aparte, y no forman parte de TeX Live. Se puede rastrear el directorio bin de TeX Live 2024 de punta a punta: no hay ningún ejecutable que empiece por fc-; las copias de este Mac las instaló Homebrew como fontconfig 2.18.2. Siguen mereciendo la pena, porque responden qué fuentes tiene el sistema y dónde están los archivos. fc-list : family imprime solo los nombres de familia, y fc-list -f un formato elegido como file, family y style. En esta máquina la lista devolvió 2.799 entradas.

terminal
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

Aquí hay una trampa en la que todos caen una vez. fc-match nunca dice «no encontrado». Dale un nombre que no existe y fontconfig devolverá algo igualmente: aquí, fc-match "NoSuchFontXYZ" respondió Verdana.ttf: "Verdana" "Regular". Eso es una sustitución, no una confirmación. Usa fc-match para comprobar si una fuente está instalada y siempre te dirá que sí. Para decidir de verdad, compara el nombre de familia devuelto con el que pediste, o acota con fc-list. En macOS hay una segunda advertencia: como mostró la sección anterior, xetex mira CoreText, así que aparecer en fc-list no garantiza que XeTeX pueda usar la fuente. A la inversa, en compilaciones donde XeTeX sí busca a través de fontconfig —normalmente TeX Live en Linux—, ejecutar fc-cache tras dejar una fuente en tu directorio personal es justo lo que hay que hacer.

updmap: qué dice realmente una línea de un mapa de fuentes

Un mapa de fuentes es texto plano, una línea por cada vínculo entre un nombre lógico de TeX y un archivo real. updmap no escribe esas líneas por sí mismo; concatena los archivos .map enumerados en updmap.cfg en psfonts.map para dvips y pdftex.map para pdftex y dvipdfmx. Al contar updmap-sys --listmaps en esta máquina salen 389 declaraciones: 332 Map, 46 MixedMap y 11 KanjiMap. El psfonts.map concatenado es un único archivo de texto de 45.672 líneas, cerca de 5,5 MB. Una línea de su interior se lee así: el nombre del lado de TeX, el nombre PostScript de la fuente, una instrucción de recodificación y los archivos reales.

terminal
# 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

Lo que hace tropezar en la práctica rara vez es la orden, sino qué configuración se está tocando. En TeX Live 2024, el updmap pelado se niega a ejecutarse: responde updmap [ERROR]: Either -sys or -user mode is required. y a continuación updmap [ERROR]: In nearly all cases you should use updmap -sys. Esa negativa es una cortesía, porque la trampa de verdad está justo detrás. La salida de updmap --help lo dice sin rodeos: en cuanto updmap-user se ha ejecutado aunque sea una sola vez, ejecutar updmap-sys deja de tener efecto alguno. Aparece un archivo de configuración personal que a partir de entonces tiene prioridad. En máquinas compartidas y en CI, estandariza en updmap-sys, y recurre a updmap-user solo cuando quieras sobrescribir a conciencia los ajustes del sistema. El sudo hace falta porque todo lo que hay bajo /usr/local/texlive/2024 pertenece a root.

kanji-config-updmap: elegir qué fuente japonesa se incrusta

Que la elección de la fuente japonesa tenga orden propia tiene su razón. En la ruta de pLaTeX y upLaTeX, qué fuente japonesa se incrusta en el PDF no se decide al componer sino en el paso de dvipdfmx. Por eso se puede cambiar después la fuente incrustada sin tocar el manuscrito, y kanji-config-updmap (de texjporg) es ese interruptor; por debajo ajusta la opción jaEmbed de updmap, antes llamada kanjiEmbed. Empieza por status. En esta máquina respondió CURRENT family for ja: haranoaji (variant: -04) y a continuación enumeró ipa e ipaex entre las familias en espera. Para cambiar, pasa el nombre de familia directamente. Como con updmap, hay una forma -sys y otra -user; en máquinas compartidas, estandarizar en kanji-config-updmap-sys es lo seguro.

terminal
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: por qué la primera ejecución de LuaTeX es lenta

Lo que sorprende en la primera ejecución de LuaLaTeX es la espera. La causa es la base de nombres de luaotfload, construida recorriendo los archivos de fuentes del sistema para asociar nombres con archivos. En esta máquina está en TEXMFVAR/luatex-cache/generic/names/luaotfload-names.luc.gz, unos 390 KB. Lo interesante es que una búsqueda fallida arranca por sí sola una reconstrucción. Dale a \setmainfont un nombre inexistente y el registro muestra luaotfload | db : Reload initiated (formats: otf,ttf,ttc); reason: Font "NoSuchFontXYZ" not found. antes de detenerse en ! Package fontspec Error: The font "NoSuchFontXYZ" cannot be found. Así que «LuaLaTeX no ve la fuente que acabo de instalar» suele curarse con una ejecución más. Para forzarlo, luaotfload-tool --update reconstruye la base y, cuando no hay nada de partida, anuncia Font names database not found, generating new one. y This can take several minutes; please be patient.

terminal
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: reconstruir el .fmt que el motor carga al arrancar

Al ejecutar pdflatex, el motor carga primero un archivo de formato como latex.fmt antes de hacer nada. Ese archivo es una instantánea de todo el estado interno del motor en el momento en que terminó de leer LaTeX entero: el truco que le permite arrancar sin releer miles de líneas de macros cada vez. fmtutil reconstruye esos archivos .fmt. Se necesita pocas veces: solo tras una actualización que afecte a un formato, o cuando un .fmt está dañado y el motor se detiene antes de arrancar. No es algo que haya que ejecutar tras cada instalación de paquete. Para un solo formato, fmtutil-sys --byfmt pdflatex; para todos, fmtutil-sys --all, que tarda varios minutos. La distinción -sys y -user funciona igual que en updmap, y las máquinas compartidas se atienen a -sys.

terminal
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

Qué orden para cada síntoma

OrdenCuándo recurrir a ella
fc-list : familyQuieres confirmar primero si el sistema tiene la fuente y con qué nombre
luaotfload-tool --updateSolo LuaLaTeX no encuentra la fuente y una segunda ejecución no lo arregla
updmap-sys --enable MapSe instaló a mano un paquete de fuente latina pero el PDF sigue con la fuente antigua
kanji-config-updmap-sys statusSolo el texto japonés del PDF está mal; comprueba antes el jaEmbed actual
fmtutil-sys --byfmtEl motor se detiene antes de componer porque no puede cargar su formato
mktexlsrUn archivo está en TEXMFLOCAL y sigue sin encontrarse; ver la página de herramientas de compilación

Para terminar, una herramienta pequeña al margen de este mapa. TeX Live incluye una orden llamada albatross, que su página de manual describe como una herramienta para encontrar fuentes que contengan un glifo Unicode dado, y que por dentro se apoya en fontconfig: otro lugar donde una herramienta del mundo TeX llama a fontconfig. Al ejecutarla aquí, sin embargo, se detuvo en Unable to locate a Java Runtime. Necesita un entorno de ejecución de Java, así que instálalo aparte si quieres usarla. mktexlsr y texhash, junto con kpsewhich, están tratados en detalle en la página de herramientas de compilación.