Re:VIEW und Veröffentlichungs-Workflows

Re:VIEW wirbt damit, dass man kein LaTeX schreiben muss. Öffnet man jedoch die config.yml, findet sich dort ein Schlüssel dvicommand mit dem Wert dvipdfmx; und die Klassendatei für das PDF deklariert \DeclareOptionX{bleed_margin}[3mm] sowie eine Option tombopaper für Schnittmarken. LaTeX ist nicht verschwunden. Es wurde in die Abteilung versetzt, die mit der Druckerei spricht. Diese Seite betrachtet dieses Publikationssystem – ein leichtgewichtiges .re-Markup, PDF und EPUB aus derselben Quelle – von der Seite seines LaTeX-Backends her.

Was Re:VIEW ist und was es ausgeben kann

Re:VIEW ist ein in Ruby geschriebenes buchorientiertes Konvertierungssystem; das Manuskript entsteht in einem leichtgewichtigen Markup in Dateien mit der Endung .re. Aus diesem einen Manuskript konvertiert es nach EPUB, LaTeX, InDesign (IDGXML), Markdown, reinen Text und Web-HTML. Geschaffen hat es Minero Aoki, gepflegt wird es von Kenshi Muto (kmuto), auf der Copyright-Zeile stehen zudem Masayoshi Takahashi und Masanori Kado (2006–2024). Die Lizenz ist LGPL. Zum faktischen Standard des japanischen technischen Selbstverlags wurde es aus einem Grund: Ein druckfertiges PDF und ein E-Book aus einem einzigen Manuskript ist genau das, was dort gebraucht wird.

= 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]{
//}

Ein Projekt besteht aus den .re-Dateien – eine je Kapitel – und zwei YAML-Dateien. config.yml trägt die Metadaten: Titel, Autor, Format, die LaTeX-Einstellungen; catalog.yml trägt die Reihenfolge der Kapitel über Vorspann, Hauptteil und Anhang hinweg. Die Manuskriptdateien selbst enthalten keine Ordnungsinformation, Umstellen von Kapiteln heißt also: Zeilen in catalog.yml verschieben. Der Gedanke gleicht dem Umsortieren einer Liste von \include-Zeilen in LaTeX, nur ist diese Liste ein Verzeichnis und keine Satzanweisung – und wirkt darum ebenso unmittelbar auf das Inhaltsverzeichnis des EPUB.

Installieren und bauen: das steckt nicht in TeX Live

Re:VIEW ist ein Ruby-Gem, kein TeX-Live-Paket. Auf einer Maschine mit vollständiger TeX-Live-2024-Installation findet sich trotzdem kein review-pdfmaker; installiert wird es gesondert mit gem install review. Die Anforderung gilt auch umgekehrt: Die Dokumentation sagt „To generate PDF, you should install TeXLive 2012 or later.“ – für das PDF braucht es also zusätzlich eine TeX-Live-Installation. Das System läuft erst, wenn zwei voneinander unabhängige Werkzeugketten bereitstehen; wer das übersieht und rake pdf aufruft, starrt auf einen Fehler, ohne zu wissen, welche Hälfte fehlt.

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 steckt nicht in TeX Live – woher File not found kommt

Nimmt man das von Re:VIEW erzeugte .tex aus dem Projektverzeichnis heraus und übersetzt es, bleibt TeX Live 2024 stehen bei ! LaTeX Error: File ‘review-jsbook.cls’ not found., gefolgt von ! Emergency stop. Der Grund ist einfach: Diese Klasse liegt im Gem und gehört nicht zu TeX Live. kpsewhich jsbook.cls und kpsewhich jlreq.cls liefern einen echten Pfad zurück; review-jsbook.cls und review-jlreq.cls liefern nichts. Die Eltern stecken in TeX Live, die Kinder nicht. Die beiden Klassen kamen mit Re:VIEW 3.0; davor benutzte das System jsbook.cls unverändert.

$ 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

Ein Blick in die Klasse zeigt sofort, wohin diese Familie schaut. Die Kennzeile von \ProvidesClass lautet „Re:VIEW pLaTeX class modified for jsbook.cls“ – also eine pLaTeX-Klasse, was zusammen mit dvicommand gleich dvipdfmx den Druckweg (u)pLaTeX → DVI → dvipdfmx ergibt. Und die deklarierten Optionen sind schlicht das Vokabular einer Druckerei: \DeclareOptionX{tombopaper} für Papier im Format mit Schnittmarken, \DeclareOptionX{bleed_margin}[3mm] für den Anschnitt, voreingestellt auf 3 mm, \DeclareOptionX{hiddenfolio} für eine im fertigen Buch verborgene Seitenzahl und \DeclareOptionX{media}[print] – dessen Vorgabewert print mehr über den Standort dieser Familie sagt als jede Dokumentation. Für die elektronische Ausgabe stellt man auf media=ebook um.

Ein zweiter PDF-Weg ohne LaTeX: Vivliostyle, seit 5.1

Version 5.1.0 legte eine zweite Straße an, diese mit CSS-Satz gepflastert. rake vivliostyle:build ruft das Vivliostyle-CLI auf und erzeugt ein PDF direkt aus HTML und CSS; rake vivliostyle:preview zeigt es im Browser. Dasselbe Manuskript kann nun durch beide Türen hinaus. Was sich darin zeigt, ist Re:VIEWs architektonische Position: LaTeX ist eines von mehreren Ausgabeformaten. Weil das Manuskript in .re und die Gestalt in einer Klasse oder einem Stylesheet steckt, lässt sich die gesamte hintere Hälfte austauschen. Welche Tür die richtige ist, hängt von den Satzanforderungen ab; für feine Kontrolle des japanischen Satzes und eine Druckabgabe mit Schnittmarken hat der LaTeX-Weg derzeit das vollständigere Werkzeug.

Re:VIEW oder reines LaTeX: worin das Buch schreiben

Re:VIEW, wenn ein EPUB gebraucht wird, sonst reines LaTeX – damit ist die Entscheidung im Wesentlichen getroffen. Wer in LaTeX beginnt und trotzdem ein EPUB schuldet, schreibt am Ende die HTML-Konvertierung selbst, und genau die wird zum schwersten Teil des Projekts. Wer umgekehrt ohne EPUB-Bedarf zu Re:VIEW greift, hat bloß eine zusätzliche Abstraktionsschicht gekauft: Bei jeder Satzkorrektur ist erst zu klären, ob sie in die .re, ins LaTeX oder dazwischen gehört. Der zweite Entscheidungsfaktor sind die Mitautoren. Wer Markdown kennt, liest .re-Markup in wenigen Minuten; eine LaTeX-Präambel ist weniger gastfreundlich.

Eines noch, das man behalten sollte: Re:VIEW zu benutzen entbindet nicht davon, LaTeX zu kennen. Eine Abbildung, die verrutscht, ein japanischer Durchschuss, der zu eng geworden ist, ein \usepackage, das fehlt – all das entscheidet sich letztlich in der Klassendatei und im .sty, und was man in diesem Moment zu Rate zieht, ist nicht die Re:VIEW-Dokumentation, sondern das eigene LaTeX-Wissen. Die drei Schlüssel texdocumentclass, texcommand und dvicommand in der config.yml sind genau als Tür in diese Ebene hinab gedacht.