Cómo funciona el procesamiento (DVI/PDF)

Tome un documento LaTeX de una línea —\documentclass{article}\begin{document}Hi\end{document}— y páselo por pdflatex: obtendrá un PDF de 11 529 bytes. Pase la fuente idéntica por latex y el archivo DVI que sale ocupa 248 bytes. Un factor de cuarenta y seis. Ambos describen la misma página con la misma palabra «Hi», así que ¿adónde va la diferencia? La respuesta explica toda la cadena de procesamiento de TeX. Esta página recorre el camino de la fuente al resultado pasando por el motor, muestra qué contiene realmente un .dvi y explica por qué la vieja ruta por DVI no ha desaparecido, con cifras medidas.

Por qué no es WYSIWYG: la apuesta por el procesamiento por lotes

TeX no repinta la pantalla mientras se escribe porque optimiza el corte de líneas párrafo a párrafo. No va llenando una línea tras otra: evalúa el párrafo completo preguntándose qué combinación de puntos de corte resulta globalmente menos fea y se queda con la solución de coste total mínimo. Consecuencia: añadir un solo carácter al final de un párrafo puede cambiar dónde se corta su primerísima línea. Recalcular cada párrafo en cada pulsación no compensa.

Así que TeX optó por el procesamiento por lotes: leer el original hasta el final y componerlo todo de una vez. Se renuncia a la comodidad de ver la página cambiar mientras se escribe. Se gana una composición globalmente óptima, un formato que no se descompone en documentos largos y la automatización que permite el texto plano: generar la fuente con un guion, compararla en Git, construirla sin supervisión en un servidor. El ritmo de trabajo pasa a ser escribir, compilar, mirar el PDF y repetir. Hacer rápido ese bucle es casi todo lo que se trata a continuación.

Las dos rutas de la fuente a la salida: PDF directo o vía DVI

Un motor o bien escribe PDF directamente, o bien escribe un archivo intermedio llamado DVI. pdflatex, xelatex y lualatex —los motores pdfTeX, XeTeX y LuaTeX respectivamente— escriben PDF; latex y los japoneses platex y uplatex escriben DVI. Escribir un DVI no cierra el trabajo: el archivo se entrega a un programa aparte, un controlador dvi, que lo convierte al formato deseado: dvipdfmx a PDF, dvips a PostScript, dvisvgm a SVG. Un controlador que dibuja en pantalla se llama visor dvi.

# Direct to PDF, one step
lualatex  document.tex        # -> document.pdf
pdflatex  document.tex        # -> document.pdf

# Via DVI, two steps (the Japanese route)
uplatex   document.tex        # -> document.dvi
dvipdfmx  document.dvi        # -> document.pdf

# Other dvi drivers, same input
dvips     document.dvi        # -> document.ps
dvisvgm   document.dvi        # -> document.svg

Lo que se confunde aquí es que «¿pasa por DVI?» y «¿admite Unicode y fuentes del sistema?» son ejes distintos. pdflatex se salta el DVI y escribe PDF directamente, pero trata la entrada a la manera antigua y no se le puede señalar sin más una fuente OpenType instalada en la máquina. xelatex y lualatex, en cambio, leen Unicode tal cual y permiten nombrar una fuente con fontspec. Mantenga separados ambos ejes y la maraña de nombres se ordena sola.

¿Qué hay realmente en un .dvi? Abramos los 248 bytes

DVI son las siglas de device independent, independiente del dispositivo, y su contenido no es más que un flujo de instrucciones que dice qué carácter va en qué posición. dvitype, que viene con TeX Live, lo despliega en algo legible. Esto es lo que había realmente dentro del DVI de 248 bytes generado a partir del documento de una línea anterior.

$ dvitype -output-level=4 one.dvi
numerator/denominator=25400000/473628672
magnification=1000
' TeX output 2026.08.13:1233'
maxv=41484288, maxh=26673152, maxstackdepth=3, totalpages=1
Font 27: cmr10---loaded at size 655360 DVI units

42: beginning of page 1
117: down4 41484288       v:=0+41484288=41484288
140: right3 5046272       h:=0+5046272=5046272
144: fntdef1 27: cmr10
165: fntnum27             current font is cmr10
166: setchar72            h:=5046272+491521=5537793
167: setchar105           h:=5537793+182045=5719838
[Hi]
181: setchar49            h:=15204352+327681=15532033
[ 1]
185: eop

Ese es el archivo entero. setchar72 dice «pon aquí el código de carácter 72 (H)», setchar105 dice «pon el 105 (i)» y setchar49 es el 1 del número de página impreso al pie. right3 y down4 mueven el punto actual, y la unidad —un DVI unit es un sp, es decir, 1/65536 pt— explica que cmr10 a «655360 DVI units» sea exactamente 10 pt. La línea decisiva es fntdef1 27: cmr10: el DVI se limita a llamar a la fuente por su nombre. En ninguna parte del archivo se dice qué aspecto tiene cmr10.

El PDF es justo lo contrario. Mire dentro del PDF de 11 529 bytes que produjo pdflatex y verá la fuente incrustada, con el nombre UNYBJV+CMR10. El prefijo de seis letras la marca como subconjunto: la prueba de que solo se extrajeron los glifos realmente usados. El objeto que contiene esa fuente reza /Length1 1394 /Length2 8300 /Length3 0 /Length 9259: 9259 bytes incluso después de comprimir, cuatro quintas partes de los 11 529 bytes del archivo. Ahí es, en esencia, adonde fue el factor cuarenta y seis. Donde el DVI puede escribir «la H de cmr10», el PDF tiene que llevar consigo el contorno de esa H. Es el precio de la promesa del PDF: verse igual dondequiera que vaya.

Un matiz, eso sí. «El DVI es pequeño porque no lleva fuente» es correcto; «el PDF ocupa 11 529 bytes porque sí la lleva» no lo explica todo. Pase ese mismo DVI de 248 bytes por dvipdfmx y el PDF resultante ocupa 1950 bytes. También incrusta la fuente, pero la convierte a la forma mucho más compacta /Subtype/Type1C, en la que ocupa solo 546 bytes. Así que una página con una sola palabra sale a 248, 1950 u 11 529 bytes según únicamente cómo se la describa. Cuando el tamaño del archivo importa, la ruta elegida se nota de verdad.

Por qué la ruta DVI sigue viva: el japonés y .xdv

La razón práctica más fuerte de que el DVI siga vivo es que constituye la ruta estándar de la composición japonesa. platex y uplatex emiten DVI, y dvipdfmx lo convierte en PDF al final. Ese programa nació del dvipdfm de Mark A. Wicks y se amplió para satisfacer los requisitos japoneses; la copia incluida en TeX Live 2024 lleva fecha de marzo de 2024. Su trabajo es traducir las órdenes de posicionamiento del DVI en operaciones de dibujo de PDF y localizar e incrustar las fuentes que el DVI referencia. Pase por upLaTeX un documento japonés de una línea y un DVI de 396 bytes se convierte en un PDF de 5998 bytes, con la fuente japonesa HaranoAjiMincho incrustada como fuente CID.

Y el mecanismo está más vigente de lo que parece. Compruebe qué es realmente dvipdfmx en TeX Live 2024 y resulta ser un enlace simbólico a xdvipdfmx, el programa que lee los archivos .xdv que produce XeTeX. Dicho de otro modo, XeTeX emite internamente un DVI ligeramente extendido y se lo entrega a un controlador para convertirlo a PDF: exactamente la ruta DVI. Puede demostrarlo con xelatex -no-pdf, que se detiene antes de la conversión y deja el .xdv. Para el documento de una línea el .xdv ocupa 436 bytes; al pasarlo por xdvipdfmx da un PDF de 2329 bytes, exactamente el mismo tamaño que produce xelatex a secas sobre la misma fuente. Partir el trabajo en dos a mano solo hace visible lo que xelatex ya hacía por dentro.

$ readlink $(which dvipdfmx)
xdvipdfmx

$ xelatex -no-pdf one.tex     # stop before the driver stage
$ ls -l one.xdv
-rw-r--r--  1 user  staff  436 one.xdv

$ xdvipdfmx one.xdv           # run the driver by hand
$ ls -l one.pdf
-rw-r--r--  1 user  staff  2329 one.pdf

La regla práctica es sencilla. Si empieza de cero en inglés o en otra lengua de escritura latina, tome la ruta de PDF directo (pdflatex o lualatex): una etapa menos es un problema potencial menos. Si trabaja en japonés con material previo o con una costumbre de laboratorio detrás, la ruta DVI (uplatex más dvipdfmx) sigue siendo una elección sólida, con un largo historial en escritura vertical y reglas japonesas de corte. La argumentación completa corresponde a la página sobre la elección de motor; en cualquier caso, no hay por qué rehuir el DVI solo por ser antiguo.

Archivos auxiliares y número de pasadas: el cuadro con BibTeX y makeindex

«Ejecutar el motor una vez y listo» solo vale para un documento sin referencias, sin índice, sin bibliografía y sin índice alfabético. Durante una pasada el motor escribe .aux (números y páginas) y .toc (el índice), y la pasada siguiente los relee. Repetir hasta que eso se estabilice es la forma básica, y en cuanto aparece un solo \ref hacen falta al menos dos pasadas. Las bibliografías y los índices meten en el bucle programas distintos del motor: BibTeX lee el .aux y escribe un .bbl (o biber lee un .bcf), y makeindex lee el .idx y escribe un .ind. El motor debe leer luego esas salidas, de donde sale el orden de ejecución de abajo.

# A document with cross-references, a bibliography and an index
pdflatex   thesis      # writes .aux, .idx; references still print as ??
bibtex     thesis      # reads .aux  -> writes .bbl
makeindex  thesis      # reads .idx  -> writes .ind
pdflatex   thesis      # pulls .bbl and .ind in; numbering shifts again
pdflatex   thesis      # everything settles

# Or simply
latexmk -pdf thesis    # figures out the order and the count on its own

Dejar de contar pasadas: latexmk, editores y SyncTeX

latexmk vigila los archivos auxiliares y repite la ejecución exactamente tantas veces como el documento necesite. Cuando el contenido de .aux y compañía sale igual que la vez anterior, da la construcción por estabilizada y se detiene, llamando de paso a BibTeX/biber o makeindex si hacen falta. Por omisión repite como mucho cinco veces ($max_repeat = 5) antes de concluir que hay un bucle. Los documentos reales prácticamente nunca alcanzan ese techo. Si quiere la ruta DVI, anótela en un archivo de configuración de latexmk y la misma orden única seguirá bastando.

latexmk -pdf      document.tex   # pdfLaTeX, as many passes as needed
latexmk -lualatex document.tex   # LuaLaTeX
latexmk -pv       document.tex   # build, then open the viewer
latexmk -c                       # remove .aux, .log, .toc and friends
latexmk -C                       # the same, and remove the PDF too

LaTeX Workshop en VS Code, TeXShop, TeXstudio y Overleaf suelen llamar a latexmk por debajo, así que pulsar «compilar» ya le ha resuelto el problema del recuento. Lo otro que conviene activar es SyncTeX, que registra en un archivo .synctex.gz de qué línea de la fuente procede cada punto del PDF. Con él activado puede hacer clic en un punto del PDF y aterrizar en la línea correspondiente de la fuente, y saltar también en sentido inverso. Cuanto más largo sea el documento, más rinde.

Cuando la compilación se detiene, qué etapa sospechar

La etapa de la que procede un mensaje indica dónde buscar. Un error del motor en el .log significa que el problema está en la fuente; una queja del controlador dvi apunta a una imagen o una fuente tipográfica; una salida de BibTeX o biber apunta al .bib. El síntoma más desconcertante es «mi imagen no aparece», y ahí se transparenta directamente la diferencia de rutas: la ruta DVI acepta EPS sin problema y la de PDF directo acepta PDF, PNG y JPEG, así que intentar incluir un PNG en un documento compilado con latex es una entrada muy habitual a este problema. La lectura del registro en sí se trata a fondo en la página sobre la persecución de errores.

• Cuando solo fallan las referencias cruzadas, no borre archivos auxiliares: deje que latexmk repita tantas veces como haga falta.
• Cuando solo faltan las imágenes, compruebe si la ruta en uso es PDF directo o DVI y convierta el archivo a un formato que esa ruta acepte.
• Cuando un síntoma persiste sin explicación, y solo entonces, borre .aux, .toc y .out y reconstruya (latexmk -c). Si la causa eran auxiliares obsoletos, queda resuelto.
• Cuando cambian las fuentes en un PDF japonés, sospeche de la configuración de incrustación de dvipdfmx. Es asunto del controlador, no del motor.