Métodos de composición japonesa

La primera decisión al componer japonés con LaTeX no es qué paquete cargar, sino qué ruta tomar. Hoy hay tres vivas: upLaTeX + dvipdfmx, LuaLaTeX + LuaTeX-ja y XeLaTeX + zxjatype. El mismo archivo .tex recorre las tres, y las tres incrustan la misma fuente de texto en el PDF. Lo que cambia es la velocidad, qué paquetes siguen funcionando y dónde se rompe todo. El japonés es justamente la razón por la que TeX desarrolló un segundo modelo de composición —pegamento entre caracteres, escritura vertical, prohibición de corte— y estas tres rutas son tres implementaciones de él. Esta página zanja la elección con cifras medidas sobre TeX Live 2024.

Las tres rutas del LaTeX japonés: dónde vive el conocimiento

La diferencia real está en qué capa del sistema guarda el conocimiento japonés. En upLaTeX está dentro del motor: escritura vertical, prohibición de corte y pegamento entre caracteres forman parte de un compositor escrito en C, y por eso es rápido. En LuaLaTeX está en callbacks de Lua: LuaTeX-ja recorre la lista de nodos que LuaTeX acaba de construir y le aplica las reglas japonesas, y por eso es más lento y mucho más fácil de modificar. En XeLaTeX está en un paquete de macros, zxjatype (que carga xeCJK por debajo), un mecanismo CJK general ajustado al japonés más que un motor japonés. Las salidas también difieren: solo upLaTeX pasa por DVI y se lo entrega a dvipdfmx; las otras dos escriben PDF directamente.

En la esquina inferior derecha de esa tabla se esconde un trozo de historia del TeX japonés. dvipdfmx nació como extensión del dvipdfm de Mark A. Wicks con soporte multibyte y CID: una herramienta hecha para el japonés. XeTeX la adoptó luego como su propia etapa de salida y así surgió xdvipdfmx. En una instalación real de TeX Live 2024, dvipdfmx es un enlace simbólico a xdvipdfmx. Un conversor escrito para el japonés se encarga hoy del último paso de todo documento XeTeX, lleve japonés o no.

Cuánta diferencia de velocidad: la misma fuente por las tres rutas

Compilar el mismo documento japonés de diez páginas bajo TeX Live 2024 costó 0,31 s con uplatex + dvipdfmx, 0,59 s con lualatex (ltjsarticle) y 0,74 s con xelatex (bxjsarticle + zxjatype). Es aproximadamente 1 : 1,9 : 2,4, y la proporción se mantiene con un archivo de una página: el grueso de la diferencia está en el arranque y en la composición misma, no en la extensión. Una sola vez, nadie nota 0,3 s frente a 0,6 s; quien use latexmk -pvc y recompile en cada guardado sí lo nota. Eso, más que la nostalgia, es lo que mantiene viva la ruta pLaTeX tras dos décadas. Los tres PDF incrustan como subconjunto la misma Harano Aji Mincho, y pdftotext recupera japonés correcto de los tres: la ruta rápida no es la de menor calidad.

# route 1 -- fastest; DVI in between
uplatex main.tex && dvipdfmx main.dvi
ptex2pdf -l -u main            # the same two steps in one command

# route 2 -- LuaTeX-ja, PDF straight out
lualatex main.tex

# route 3 -- XeTeX via zxjatype
xelatex main.tex

Elegir la clase de documento: jsclasses, jlreq, ltjsclasses, bxjscls

Elegida la ruta, la clase casi se elige sola: jsarticle (de jsclasses) o jlreq para upLaTeX, ltjsarticle (de ltjsclasses) o jlreq para LuaLaTeX, bxjsarticle (de bxjscls) para XeLaTeX. Con una excepción: jlreq admite pLaTeX, upLaTeX y LuaLaTeX, pero no XeLaTeX. Pasar \documentclass{jlreq} a xelatex produce ! Undefined control sequence. y luego cae hasta ! LaTeX Error: Missing \begin{document}. La idea de que fijar la clase permite cambiar de motor libremente es cierta, pero XeLaTeX no está entre los destinos posibles.

La sorpresa que siempre depara la elección de clase es que el mismo 10pt no significa el mismo tamaño. Componga en jsarticle a 10pt, mida un kanji y hallará 9,24683pt de ancho: el archivo de clase incluye \def\Cjascale{0.924690} y carga la fuente japonesa a 0,924690 veces el tamaño latino. Haga lo mismo en jlreq y el kanji mide exactamente 10pt. Cambiar jsarticle por jlreq altera, pues, la longitud de línea, los caracteres por línea y toda la caja de texto. Planifique la migración como una remaquetación, no como una comparación en igualdad de condiciones.

% route 1: uplatex main.tex && dvipdfmx main.dvi
\documentclass[uplatex,dvipdfmx]{jsarticle}
\begin{document}
日本語と English を混ぜた段落です。約物（かっこ）も混じります。
\end{document}

% route 2: lualatex main.tex
\documentclass{ltjsarticle}
\usepackage{luatexja-fontspec}
\setmainjfont{Harano Aji Mincho}
\setsansjfont{Harano Aji Gothic}
\begin{document}
日本語と English を混ぜた段落です。約物（かっこ）も混じります。
\end{document}

Lo que cuesta la ruta pLaTeX: fontspec, unicode-math, microtype

El precio de esa velocidad es que la ruta pLaTeX deja fuera en bloque a los paquetes modernos basados en OpenType. \usepackage{fontspec} se detiene con ! Fatal Package fontspec Error: The fontspec package requires either XeTeX or (LuaTeX en la línea siguiente), y unicode-math responde ! Package unicode-math Error: Cannot be run with uptex!. El caso traicionero es microtype: no da error. Escribe Package microtype Warning: You don't seem to be using pdftex, luatex or xetex. en el registro y luego no hace nada en silencio: cargado pero inerte, la avería más difícil de advertir. En cambio graphicx, hyperref y tikz funcionan con normalidad si el driver encaja, así que no es cuestión de que "solo sirvan los paquetes viejos". La frontera pasa justo por OpenType y la microtipografía.

Marcadores del PDF ilegibles: hyperref y pxjahyper

Escriba un título de sección en japonés bajo (u)pLaTeX con hyperref y solo los marcadores del PDF salen ilegibles: el texto del cuerpo es perfecto y el panel de esquema, un galimatías. La causa es que hyperref vuelca los bytes UTF-8 del título tal cual en una cadena UTF-16BE. El archivo .out generado contiene \376\377\000\346\000\227\000\245…, cada byte rellenado con un cero. Añada \usepackage{pxjahyper} y el mismo título pasa a ser \376\377\145\345\147\054\212\236…, es decir 0x65E5 0x672C 0x8A9E, los tres caracteres de 日本語. Si usa hyperref en (u)pLaTeX, considere pxjahyper obligatorio. Bajo LuaLaTeX con LuaTeX-ja, hyperref a secas ya emite UTF-16BE correcto y este paso sobra.

% (u)pLaTeX: load pxjahyper AFTER hyperref, or the outline panel is garbage
\documentclass[uplatex,dvipdfmx]{jsarticle}
\usepackage{hyperref}
\usepackage{pxjahyper}
\begin{document}
\section{日本語の見出し}
本文。
\end{document}

Entonces, ¿qué ruta elegir?

Para cualquier documento nuevo, elija LuaLaTeX con LuaTeX-ja (ltjsarticle o jlreq). A cambio de un tercio de segundo obtiene Unicode de principio a fin, acceso a fuentes del sistema, fontspec, unicode-math y microtype operativos, y marcadores sencillamente correctos. Si la plantilla de tesis del departamento o un archivo de estilo de congreso presupone jsclasses, o si el tiempo de compilación pesa de verdad en un ciclo de edición apretado, siga en upLaTeX + dvipdfmx: no es la vía heredada, sigue siendo la más rápida. XeLaTeX + zxjatype se elige cuando ya existe un documento XeLaTeX al que hay que añadir japonés; solo por el japonés hay poco motivo. Y ya no hay razón para empezar un documento nuevo con platex a secas: uplatex amplía el repertorio de caracteres componibles (diferencia tratada en «Codificación de caracteres y saltos de línea»).

• Documento nuevo y sin condicionantes institucionales → lualatex con ltjsarticle (o jlreq); Unicode, fuentes del sistema y microtype disponibles.
• Una plantilla existente presupone jsclasses, o importa la velocidad de compilación → uplatex + dvipdfmx; ptex2pdf -l -u lo reúne en un solo comando.
• Ya existe un documento XeLaTeX → bxjsarticle + zxjatype + zxjafont; jlreq no funciona bajo XeLaTeX.
• ¿hyperref en (u)pLaTeX? Cargue pxjahyper. «Solo los marcadores salen ilegibles» casi siempre es esto.
• microtype es inerte en (u)pLaTeX: avisa y no hace nada. Si lo quiere, tome la ruta Lua o Xe.