Wieder mal eine Story aus dem Alltag der Technikredaktion1. Es geht um einen Publikationskanal, den es in der TRK gar nicht mehr geben sollte: Technische Dokumente als PDF. OMG!
Nun kann man sich endlos über die Begrenztheit von PDF auslassen; alleine die Tatsache, dass es eigentlich nur digitalisierte Seiten sind, die Informationen immer nur auf ein virtuelles Blatt begrenzt und die also ab einem gewissen Umfang (Bild, Text,…) nicht mehr auf einen Blick erfassbar sind, sagt schon alles. Oder die Suche. Oder Bewegtbilder mit und ohne Ton. Oder die Aktualisierbarkeit. Oder die Navigation. Oder, oder, oder…: PDF ist suboptimal in vielerlei Hinsicht.2
Und dennoch ist PDF sowohl im Redaktionsalltag nicht wegzudenken (unverzichtbar bei Korrekturläufen), als auch der kleinste gemeinsame Nenner bei der Bereitstellung von technischen Informationen: kein Dokument lässt sich verlustfrei so schnell an die E‑Mail hängen, auf den Server oder den USB-Stick kopieren. Nichts geht verloren, alles wird genauso angezeigt wie es erstellt wurde – kurz: die TRK kommt nicht ohne PDF aus.
Daher jetzt mal ein Exkurs, wie man sich den Alltag mit PDF trotz aller Unzulänglichkeiten zumindest erträglich gestalten kann.
PDF ist eine Seitenbeschreibungssprache, d. h. alle Objekte einer PDF werden auf eine vorher zu definierende Seitengröße „gemalt“. Ein Informationsbaustein wie eine Tabelle, die sich über mehrere Seiten erstreckt, ist für das fertige PDF-Dokument nicht als Einheit erkennbar: Es sind zwei Tabellen auf zwei Seiten ohne Zusammenhang. Seitenende heißt Informationsende. Eine Tabelle aber ist tatsächlich ein einzelner Informationsbaustein, egal über wie viele Seiten sie geht. Ein HAT (Help Authoring Tool, Autorenwerkzeug) wie Flare behandelt daher eine Tabelle immer als Ganzes, unabhängig von der Seitengröße und Anordnung.
Topics
Mit Flare schreibt man Topics. Das sind einzelne Informationsbausteine, die dann in einem Strukturbaum (ähnlich einer Gliederung, passenderweise „Inhaltsverzeichnis“, engl. „Table of contents“, TOC genannt) hintereinander gesetzt werden. Sobald mit Flare ein PDF produziert wird, werden die im Strukturbaum angelegten Topics aneinander gehängt und über die dafür erforderlichen Seiten verteilt. Kommt das Seitenende vor dem Topic-Ende, fügt Flare eine neue Seite an und macht damit so lange weiter, bis alle Topics aus dem Strukturbaum „verbraucht“ sind.
Steuern mit CSS
Zunächst aber ein Hinweis vorab: neben dem „klassischen“ CSS3 hat MadCap in Flare noch ein paar eigene Features eingebaut, die insbesondere die Druckbarkeit, also das Seitenlayout in der PDF beeinflussen. Auf diese Feaures gehe ich in diesem Abschnitt ein. Wer keine PDF erstellt oder keine besonderen Layout-Anforderungen bennötigt, wird diese Features nicht benötigen.3
Zu diesen Features zählen neben den Querverweisen (bei denen Flare unterscheidet, ob sie in der PDF mit Seitenzahl angegeben werden oder im Browser ohne) vor allem die Nummerierungen der Überschriften. Hier liegt auch der größte Unterschied zwischen HTML und PDF, denn die seitenbasierte Struktur der PDF erleichtert zwar die lineare Informationsaufnahme, indem man immer eine Seite vorwärts oder rückwärts „blättert“, sie erschwert aber die Verknüpfung der Informationen, denn das „Springen“ auf ein anderes Ziel (Querverweis) erschwert auch die Navigation zurück.4
Auf dem Papier hat sich daher seit vielen Jahren die Nummerierung der Überschriften als ein recht nützliches Feature etabliert, das ich zwar schon öfter kritisiert habe, das aber in manchem Kontext als sinnvoll erweist. Im Browser ist sie aufgrund der Hyperlinkstruktur unsinnig, in der PDF durchaus sinnvoll. Wie aber macht man das in Flare? Immerhin haben wir ja nur ein Topic (einen Textbaustein), den wir mal mit, mal ohne Nummer publizieren wollen – und von dem wir weder wissen, an welcher Stelle im Text er stehen wird, noch, wie tief er verschachtelt sein kann. Die Verschachtelungstiefe ergibt sich in der Nummerierung durch die Anzahl der Ziffern vor der Überschrift – Ebene 1 ist „1“, Ebene 2 ist „1.1“ usw. – und die Position ergibt sich durch die Ziffer selbst – „1.1“ kommt vor „1.2“.
Das will man aber nicht manuell anpassen, denn es würde ja dem Sinn des Single-Sourcing widersprechen, müsste man für jedes Topic mehrere Varianten vorhalten, die jweils manuell unterschiedlich nummerierte Überschriten besitzen. Deswegen greift man in Flare auf „Targets“ (Publikationsziele) zurück, die jeweils eine spezifische CSS benutzen können. Das ist anfangs vielleicht etwas verwirrend und benötigt ein bisschen Hirnschmalz, funktioniert aber bestechend einfach: jede CSS kennt primär zwei Publikationsziele: Online (HTML) und Druck (PDF).5 Um unterschiedliche Ziele in der PDF anzusprechen, muss man also mehrere CSS anlegen, in denen die Nummerierungsvorgaben unterschiedlich sind. Sobald dann die CSS bei der Publikation auf eine Überschrift (H1 bis H6) trifft, wendet sie die Vorgaben an, die dazu festgelegt wurden. Darüber hinaus kann für jedes Publikationsziel auch ein spezifisches Seitenlayout vorgegeben werden.

Damit haben wir drei Faktoren, die beliebig gemischt werden können:
- Publikationsziel (PDF, HTML, …)
- Stylesheet (CSS) mit der Unterscheidung nach Druck (print) und Online (einschließlich Fensterbreitenunterscheidung)
- Seitenlayout mit Rändern und Spalten, einseitig oder doppelseitig, …
Durch die Kombination aus CSS-Definitionen, Seitenlayouts und Publikationszielen lässt sich damit eine Vielzahl sehr unterschiedlicher PDF produzieren.
Überschriftennummerierung
Wer sich mit „Nummernkreisen“ in Adobe FrameMaker (oder InDesign) auskennt, für den ist die Einrichtung von Überschriftennummerierungen kalter Kaffee. Alle anderen sollten sich kurz mit der Idee vertraut machen, dass Nummerierungen in einem Text mehreren Systemen folgen: eine Überschriftnummerierung folgt einer anderen Ssystematik als eine Bild- oder Tabellennummerierung: während erstere beispielsweise bei jedem Kapitel neu beginnen soll („1“ – „1.1“- „1.2“ – … – „2“ – „2.1“ – …), werden Tabellen oder Bilder einfach durchgehend nummeriert oder nach Kapitel getrennt nummeriert, wobei ein Bild natürlich durchgehend gezählt wird, selbst wenn dazwischen eine Tabelle steht („Abb.1“- „Tab.1“ – „Abb.2“ – „Abb.3“ – „Tab.2“ – „Abb.4“ – …). Entsprechend gilt das für Tabellen. Und natürlich automatisch, klar.
Daher gibt es auch in Flare in der CSS für „Print“ eine eigene Definition für jeden Nummernkreis, gekennzeichnet durch zwei Großbuchstaben in der CSS (hier am Beispiel einer Überschrift der ersten Ebene H1 ein „GH“). Ein Bild bekomt dementsprechend einen anderen Nummernkreis – beispielsweise „GI“ – und eine Tabelle „GT“.

Wer möchte, kann in der CSS noch ein eigenes Format für die Nummererung der Überschriften festlegen (eine so genannte „Klasse“), in unserem Beispiel „sectionnumber“.
Als Ergebnis zeigt die Voransicht der PDF für das gleiche Topic „Connect the camera“ dann folgende Unterschiede:


In einer HTML dagegen sähe das Topic dann so aus:

Verschachtelungstiefe
Für die Profis lässt sich dieses Spiel noch eine Windung weiter drehen: In Flare können die Vorgaben des Stylesheets für Überschriften von der Verschachtelung im Inhaltsverzeichnis abhängig sein. Das bedeutet, dass das Stylesheet seine Vorgaben für die Festlegungen der Überschriften unabhängig davon anwendet, was in der jeweiligen Überschrift definiert ist. Man kann also getrost jede Überschrift mit H1 festlegen, in der Ausgabe wird dann das Format angewendet, das für die Verschachtelungstiefe gültig ist: eine H1 im Topic wird in der zweiten Ebene als H2 formatiert.
Das ist natürlich sehr praktisch, wenn ein Topic in unterschidlichen Inhaltsverzeichnissen an unterschiedlichen Stellen in der Hierarchie steht.
Fazit
Wer mit der Trennung von Inhalt, Form und Struktur zurecht kommt, kann sich im Leben und im Beruf sehr viel Ärger ersparen.
Das gilt natürlich vor allem in Flare…
Ich spiele mit dem Gedanken, den Begriff „Technikredaktion“ mit „TRK“ abzukürzen: TRK für „Technische Redaktion und Kommunikation“, denn der Job besteht ja nicht alleine daraus, technische Inhalte zielgruppengerecht und verständlich aufzubereiten, sondern vor allem auch zu kommunizieren. ↩
Klar kann man vieles davon einbetten, scripten oder verlinken, aber es verbessert nicht die Usability, wenn man dazu aus einem Programm zur PDF-Anzeige in anderes Programm zur Filmwiedergabe springen muss – und zurück. ↩
Im Editor sind sie mit „mc-“ markiert, also leicht von den Funktionen zu unterscheiden, die vom WWW-Konsortium als plattformunabhängiger Mindeststandard gefodert werden, mithin von jedem Browser darstellbar sein müssen. ↩
Wer sich damit intensiver auseinandersetzen möchte, findet vor allem bei Nielsen et al. näheres. ↩
Online erlaubt noch eine weitere Unterscheidung nach einer beliebig großen Aufteilung in Bildschirmbreiten aber das ist eine Besonderheit des CSS3, nicht von Flare, und soll hier auch nicht berücksichtigt werden. ↩