Texera

Der strukturierte Text wird in ein LuaTeX-kompatibles Format übersetzt. Bilder werden zusammengesammelt, Styles entsprechend eingesetzt, bevor ein PDF erzeugt wird. Das waren die einfachen Teile — komplexer wurde es mit Kundenanpassungen:

• Section-Header mit Datumsformat
• Titelblätter
• customized Aufzählungslisten
• dynamisch erzeugtes Impressum und Disclaimer
• farbige Texte und Tabellen mit farbigen Rahmen, wie es der jeweilige Redakteur wünscht
• ein Referenzsystem für Fußnoten

Gewachsener Code, hunderte Quelldateien. Ein Testkorpus aus konkreten Praxisbeispielen mit jeweils erwartetem LaTeX-Output deckt bewusst viele unterschiedliche Anforderungen ab. Anfangs behielt ich noch leicht den Überblick bei den JUnit-Tests. Erst mit der Bibliothek pdfcompare (Maven Central) ließen sich die PDF-Ausgaben automatisiert vergleichen. Klingt nach Fleißarbeit. Zahlt sich aber aus: ein Test schlägt automatisch fehl, sobald sich eine PDF-Datei verändert.

Es kam mehr als einmal vor, dass eine Änderung am HTML-Code — ähnlich wie man an einem Faden eines Netzes zieht — unverhofft Änderungen in anderen Teilen der Ausgabe nach sich zog. Damit war klar, wo die Grenzen der Veränderbarkeit liegen — und dass man sich auf ein grünes Testergebnis verlassen kann.

Der Kundenwunsch, die PDFs barrierefrei zu haben (PDF/⁠UA-2), führte dazu, dass die gesamte Bibliothek nochmals angepasst und optimiert wurde — sofern es die JUnit Tests zuliessen.

Was ich aus dieser Arbeit mitgenommen habe? Sieben Jahre mit unterschiedlichen Übersetzungsproblemen — und ein Gespür dafür, wo man bei einem neuen Fall nicht bei null anfangen muss. Wenn am Ende ein PDF/⁠UA-2 stehen muss, das nicht nur validiert, sondern auch den gesetzlichen Vorgaben entsprechen soll — sprich mich an.