Re:VIEW y flujos de publicación

Re:VIEW se vende con la promesa de no tener que escribir LaTeX. Abra, sin embargo, su config.yml: hay una clave dvicommand cuyo valor es dvipdfmx; abra la clase que usa para el PDF y declara \DeclareOptionX{bleed_margin}[3mm] y una opción tombopaper para las marcas de corte. LaTeX no ha desaparecido. Lo han trasladado al departamento que habla con la imprenta. Esta página mira ese sistema de publicación —un marcado ligero .re, PDF y EPUB desde la misma fuente— desde el lado de su motor LaTeX.

Qué es Re:VIEW y qué puede producir

Re:VIEW es un sistema de conversión orientado al libro escrito en Ruby; el manuscrito se escribe en un marcado ligero, en archivos con extensión .re. Desde ese único manuscrito convierte a EPUB, LaTeX, InDesign (IDGXML), Markdown, texto plano y HTML web. Lo creó Minero Aoki y lo mantiene Kenshi Muto (kmuto); en la línea de copyright figuran además Masayoshi Takahashi y Masanori Kado (2006–2024). La licencia es LGPL. Se convirtió en la opción de facto de la autoedición técnica japonesa por una razón: sacar de un solo manuscrito un PDF listo para imprenta y un libro electrónico es exactamente lo que ese mundo necesita.

= Getting started

Ordinary body text. Inline emphasis is written @<b>{like this},
and a cross-reference to a listing is @<list>{hello}.

//list[hello][A first program]{
puts "hello"
//}

//image[diagram][The system, in outline]{
//}

Un proyecto son los archivos .re, uno por capítulo, más dos archivos YAML. config.yml lleva los metadatos —título, autor, formato, ajustes de LaTeX— y catalog.yml lleva el orden de los capítulos entre preliminares, cuerpo y finales. Los archivos del manuscrito no contienen información de orden, así que reordenar capítulos consiste en mover líneas en catalog.yml. La idea es la de reordenar una lista de \include en LaTeX, salvo que esta lista es un catálogo y no una instrucción de composición: por eso gobierna con igual inmediatez el índice del EPUB.

Instalar y compilar: esto no está en TeX Live

Re:VIEW es una gema de Ruby, no un paquete de TeX Live. En una máquina con una instalación completa de TeX Live 2024 sigue sin aparecer review-pdfmaker por ninguna parte; se instala aparte con gem install review. La exigencia va también en sentido contrario: la documentación dice «To generate PDF, you should install TeXLive 2012 or later.», de modo que hace falta además una instalación de TeX Live. El sistema solo funciona cuando están presentes dos cadenas de herramientas independientes; ejecutar rake pdf sin haberlo advertido deja frente a un error sin saber cuál de las dos mitades falta.

gem install review          # the Ruby side
# TeX Live is a separate prerequisite for the PDF route

review-init hello           # create a project skeleton
cd hello

rake pdf                    # PDF, through LaTeX
rake epub                   # EPUB
rake web                    # HTML
rake text                   # plain text
rake idgxml                 # InDesign

# the same jobs without rake:
review-pdfmaker config.yml
review-epubmaker config.yml

review-jsbook.cls no está en TeX Live: de dónde sale File not found

Saque del directorio del proyecto el .tex que Re:VIEW generó, compílelo, y TeX Live 2024 se detiene en ! LaTeX Error: File ‘review-jsbook.cls’ not found., seguido de ! Emergency stop. La razón es simple: esa clase viaja dentro de la gema y no forma parte de TeX Live. kpsewhich jsbook.cls y kpsewhich jlreq.cls devuelven una ruta real; review-jsbook.cls y review-jlreq.cls no devuelven nada. Los padres están en TeX Live; los hijos no. Esas dos clases llegaron con Re:VIEW 3.0; antes el sistema usaba jsbook.cls tal cual.

$ uplatex rv.tex
! LaTeX Error: File `review-jsbook.cls' not found.
! Emergency stop.

$ kpsewhich jsbook.cls
/usr/local/texlive/2024/texmf-dist/tex/platex/jsclasses/jsbook.cls
$ kpsewhich jlreq.cls
/usr/local/texlive/2024/texmf-dist/tex/latex/jlreq/jlreq.cls
$ kpsewhich review-jsbook.cls
$                                  # nothing: it lives in the gem

Un vistazo dentro de la clase y queda claro hacia dónde mira esta familia. La línea de identificación de \ProvidesClass dice «Re:VIEW pLaTeX class modified for jsbook.cls»: una clase de pLaTeX, lo que, junto a un dvicommand que vale dvipdfmx, convierte la ruta de impresión en (u)pLaTeX → DVI → dvipdfmx. Y las opciones que declara son sencillamente el vocabulario de una imprenta: \DeclareOptionX{tombopaper} para papel dimensionado con marcas de corte, \DeclareOptionX{bleed_margin}[3mm] para el sangrado, con 3 mm por defecto, \DeclareOptionX{hiddenfolio} para un folio que el libro terminado oculta, y \DeclareOptionX{media}[print], cuyo valor por omisión print dice más sobre la posición de esta familia que cualquier documentación. Para la edición electrónica se cambia a media=ebook.

Una segunda ruta al PDF que no es LaTeX: Vivliostyle, desde 5.1

La versión 5.1.0 abrió una segunda vía, pavimentada esta con composición CSS. rake vivliostyle:build llama al CLI de Vivliostyle y fabrica un PDF directamente desde HTML y CSS, con rake vivliostyle:preview para revisarlo en un navegador. El mismo manuscrito puede salir ahora por cualquiera de las dos puertas. Lo que esto ilustra de verdad es la posición arquitectónica de Re:VIEW: LaTeX es un formato de salida entre varios. Como el manuscrito vive en .re y la apariencia vive en una clase o una hoja de estilo, toda la mitad posterior se puede sustituir. Qué puerta usar depende de lo que exija la composición; para un control fino de la composición japonesa y una entrega a imprenta con marcas de corte, la ruta LaTeX dispone por ahora del utillaje más completo.

Re:VIEW o LaTeX normal: en cuál escribir el libro

Re:VIEW si hace falta el EPUB, LaTeX normal si no — con eso está tomada casi toda la decisión. Empezar en LaTeX debiendo todavía un EPUB acaba en escribir uno mismo la etapa de conversión a HTML, que se convierte en la parte más pesada del proyecto. A la inversa, recurrir a Re:VIEW sin EPUB a la vista es haber comprado una capa de abstracción de más: cada retoque de composición empezará por averiguar si la corrección va en el .re, en el LaTeX o en medio. El otro criterio son los coautores: quien conoce Markdown lee el marcado .re en pocos minutos; un preámbulo LaTeX no es tan hospitalario.

Una última cosa que conviene retener: usar Re:VIEW no exime de conocer LaTeX. Una figura que se desplaza, una interlínea japonesa que se ha cerrado, un \usepackage que hay que añadir: todo eso se resuelve en última instancia en el archivo de clase y en el .sty, y lo que se consulta en ese momento no es la documentación de Re:VIEW sino el propio conocimiento de LaTeX. Las tres claves texdocumentclass, texcommand y dvicommand de config.yml existen precisamente como puerta de bajada a ese nivel.