Hello LaTeX, My Old Friend; I’ve Come to Write With You Again

Vom Wiederentdecken eines Schreibwerkzeugs

Auch in der vermeintlich so schnelllebigen IT-Welt, in der im Quartalsrhythmus neue Säue (wie Programmiersprachen, Frameworks etc) durch’s Dorf getrieben werden, haben bestimmte Technologien eine gewisse Beharrlichkeit: Die Kernprotokolle des Internets sind Jahrzehnte alt. Unix, das uns in verschiedenen Inkarnationen vom IoT-Device über das Smartphone bis hin zur Serverfarm begleitet, stammt aus den späten Sechziger Jahren. Ein weiterer Kandidat dieser Liste, wenn auch weniger exponiert, ist das Textsatzsystem TeX, bzw. dessen besser benutzbare Variante LaTeX. Ursprünglich ab 1977 von Donald Knuth entwickelt, um seine Werkreihe „The Art of Computer Programming“ damit zu setzen, hat sich dieses System zu einer festen Größe im akademischen Umfeld entwickelt: Vermutlich alle Studierenden eines MINT-Fachs sind schonmal mit TeX in Berührung gekommen, ein Großteil der Publikationen in diesem Umfeld entstehen mit TeX.

Das markante typographische Erscheinungsbild der mit TeX gesetzten Texte  löst bei vielen Erinnerungen an die Studienzeit aus — denn für die meisten Nutzer dieses Systems endet der Einsatz mit der Graduation. Im Unternehmensumfeld hat TeX kaum eine Bedeutung. Zu groß sind die Unterschiede zur „klassischen“ Textverarbeitung mit ihrem WYSIWYG Ansatz. Zu gering scheint der Nutzen und zu unwichtig sind die herausragenden typographischen Eigenschaften dieses Textsatzsystems.

Für n-design hat sich LaTeX (fassen wir TeX und LaTeX hier mal großzügig zusammen) zu einer veritablen Alternative für die IT-Sicherheitsdokumentation des Konnektors entwickelt. Das Zertifizierungsverfahren nach Common Criteria verlangt vom Hersteller die Erstellung umfangreicher Dokumentation. Es müssen eine Spezifikation der Sicherheitsvorgaben, eine funktionale Spezifikation, eine Design-Spezifikation, eine Beschreibung der Sicherheitsarchitektur und verschiedene Begleitdokumente erstellt werden. Über den Daumen gepeilt sprechen wir beim von n-design mitentwickelten Konnektor von einer Dokumentation im Umfang zwischen 4.000 und 5.000 Seiten.

Eine besondere Herausforderung ist, die Struktur unserer Software auf die Struktur der Common Criteria abzubilden: Von der Softwareseite her sprechen wir von Repositories, Bundles und Interfaces. Die Common Criteria kennt als technologieneutrale Beschreibungsebene nur Subsysteme, Module und Schnittstellen. Hier sicherzustellen, dass diese Abbildung über die gesamte Dokumentation hin konsistent erfolgt, ist eine Schwierigkeit für sich. Das Autorenwerkzeug muss hier unterstützen, ansonsten gehen die Autoren unter.

Der bisherige, klassische Ansatz, die Dokumentation mit Microsoft Word zu verfassen, schien aufgrund verschiedener Punkte nicht tragfähig für ein Unterfangen dieser Größe und Komplexität:

Die Kollaborationsmöglichkeiten sind eingeschränkt: Nur eine Person kann gleichzeitig an einem Dokument arbeiten. Gleichzeitig ist es mit Bordmitteln schwer, einen Text auf mehrere Dateien aufzuteilen. Das manuelle Zusammenführen von Arbeitsergebnissen ist ein Albtraum und die Dokumente lassen sich nicht gut mit üblichen Versionierungssystemen (Git) verwalten. Typographische Vorgaben lassen sich nur schwer verpflichtend umsetzen. Das mag nicht schwerwiegend erscheinen, aber bei der schieren Menge des Textes muss der Leser Verlässlichkeit in den Formatierungen haben: Gleiche Dinge müssen nicht nur gleich heißen, sondern auch gleich aussehen. Fairerweise muss natürlich angemerkt werden, dass Microsoft und seine Partner mit Sicherheit Lösungen anbieten, mit denen sich zumindest einige dieser Punkte beseitigen lassen. Doch diese Lösungen stehen im Projekt nicht zur Verfügung.

LaTeX hingegen hat genau diese Probleme nicht: Dokumente lassen sich beliebig in kleinere Dateien aufteilen. Diese Dateien können unabhängig voneinander von mehreren Autoren bearbeitet werden. Die Dokumente werden als einfacher Text geschrieben und eignen sich somit hervorragend für die Verwaltung mit Git. Typographisch lässt TeX kaum Wünsche offen und dass es auch für große Textmengen geeignet ist, hat es durch den jahrzehntelangen Einsatz im Bereich des wissenschaftlichen Publizierens bewiesen. Dafür ist die Lernkurve entsprechend steiler. Doch die designierten Autoren sind Softwareentwickler und somit ist ihnen der Workflow „schreiben -> kompilieren -> testen“ nicht ganz fremd.

Bleibt das Problem des Umstiegs. Doch auch hier gibt es interessante Verfahren. Mit pandoc lassen sich Word-Dokumente passabel nach LaTeX konvertieren. Ausgehend davon kann die Modularisierung in Angriff genommen werden: Die Dokumente werden in sinnvolle Module aufgeteilt und durch „\input{}„ Anweisungen in ein Rahmendokument eingebunden.

Nun werden die Dokumente umformatiert. Das bedeutet im Wesentlichen, eigene Makros zu schreiben. Diese Makros sollen — im Sinne der Trennung von Form und Inhalt — möglichst an der Domäne des Dokuments orientiert sein. Ein Beispiel: Die Sicherheitsanforderungen (SFR) an das Dokument sollen immer in kursiver Schrift gesetzt werden. Das erreicht man in LaTeX dadurch, dass man den Text in die geschweiften Klammern des das Makros „\textit{}„ einschließt. In unserem Fall aber haben wir ein Makro „\sfr{}„ definiert, das intern wiederum „\textit{}„ aufruft. Diese Indirektion erlaubt uns, zu einem späteren Zeitpunkt die Formatierung anzupassen, ohne im Text alle Vorkommen eines SFR zu ändern. Wir sprechen hier von einer semantisch orientierten Auszeichnung. Durch umfangreiche Makros lassen sich die komplexen LaTeX-Makros so abstrahieren, dass ein Autor gar kein LaTeX-Profi mehr sein muss, sondern nur noch spezifisches Wissen über die Domäne des Dokuments braucht. Das verringert die Einstiegsaufwand für neue Autoren.

Die Überschrift deutet ein  „Wiederentdecken“ eines Schreibwerkzeugs an. Das äußerte sich für mich vor allem darin, dass es spannend war, knapp 18 Jahre nach der eigenen universitären Abschlussarbeit zu sehen, wie lebendig das System nach wie vor ist und wie vielfältig die Weiterentwicklungen sind, die LaTeX in den vergangenen Jahren erfahren hat.

Bemerkenswert hier sind vor allem die Möglichkeiten der relativ neuen Implementierung LuaTeX, die — wie der Name andeutet — einen Interpreter für die Programmiersprache Lua bietet. Über diese Schnittstelle können während des Textsatzprozesses Lua-Programme aufgerufen werden. Diese Funktion nutzen wir, um Mappings der Entitäten unserer Software auf die Begriffe der Common Criteria aus einer relationalen Datenbank auszulesen und in den Text einzubringen. So können wir automatisch Tabellen im Dokument generieren lassen, deren fortwährende Pflege im Rahmen einer sehr dynamischen Dokumentationsphase (immerhin wird das System noch weiterentwickelt) höchst aufwendig und fehlerträchtig wäre.

Viele Vorteile, die sich im Projekt ergeben haben, können wir hier nicht im Detail aufführen. Stichwortartig zu nennen sind hier:

  • Die Wiederverwendung identischer Texte in verschiedenen Dokumenten
  • An Software-Engineering angelehnte Verfahren zum automatischen Erstellen der Dokumente mit Build-Werkezugen wie „make„
  • PDF als Zielformat, das jederzeit an den Evaluator auslieferbar ist
  • Automatisches Generieren von Hyperlinks für die non-lineare Navigation durch den Text
  • Gemeinsame Literaturverwaltung für alle Dokumente
  • Hohe Produktivität durch LaTeX Plugins in Editoren
  • Schnelle Einsetzbarkeit durch Deployment in einer portablen virtuellen Maschine

Alle diese Eigenschaften haben dazu geführt, dass wir von einer Dokumentationsplattform sprechen. Diese Plattform kann in vielen Projektkontexten verwendet werden, in denen sehr strukturierte, stark formalisierte Dokumente geschrieben und langfristig gepflegt werden müssen.