PDF-Ausgabe automatisieren: Von der Quelle zum druckfertigen Dokument

Es gibt in jeder Redaktion diesen einen Nachmittag vor der Auslieferung. Das Dokument ist inhaltlich fertig, jetzt muss „nur noch das PDF gemacht werden" – und dann beginnt das Ritual: Felder aktualisieren (hoffentlich alle), exportieren, durchblättern, feststellen, dass das Verzeichnis noch die alten Seitenzahlen zeigt, neu exportieren, feststellen, dass eine Schrift nicht mitgekommen ist, jemanden fragen, der das mal eingestellt hatte. Mal drei Sprachfassungen. Mal vier Produktvarianten. Und beim nächsten Release wieder von vorn.

Das Bemerkenswerte daran: Fast niemand kommt auf die Idee, dass dieser Nachmittag verschwinden könnte. Die PDF-Erzeugung gilt als Handarbeit, weil sie schon immer Handarbeit war – dabei lässt sich jede gängige Werkzeugklasse skriptgesteuert zur Ausgabe überreden, und die eigentliche Arbeit liegt ohnehin woanders: in einer sauberen Quelle und in definierten Prüfungen. Wer beides hat, drückt am Ende keinen Knopf mehr, sondern liest einen Prüfbericht.

Dieser Artikel zeigt die Wege je Werkzeugklasse, das Qualitätssicherungs-Gate, das aus Automatisierung erst Verlässlichkeit macht – und die Zielprofile, die man kennen sollte, bevor der Kunde nach PDF/A fragt.

Warum Handarbeit hier besonders teuer ist

Rechnen wir kurz nach, denn die Größenordnung überrascht. Ein PDF-Ritual von einer Stunde, viermal im Jahr, für sechs Dokumente in drei Sprachfassungen: Das sind zweiundsiebzig Stunden – fast zwei Arbeitswochen, die nirgends als Projekt auftauchen, weil sie sich in Halbstundenhäppchen über den Kalender verteilen. Und diese Rechnung enthält noch keinen einzigen Fehler. Fehler sind der eigentliche Posten: das ausgelieferte Handbuch mit dem Verzeichnis vom Vormonat, das PDF mit fehlender Schrift, das die Druckerei zurückschickt, die Sprachfassung, die niemand erzeugt hat, weil die Liste im Kopf einer Kollegin lebte, die an dem Tag krank war.

Der Kern des Problems ist nicht die Zeit, sondern die Nicht-Reproduzierbarkeit. Handarbeit bedeutet, dass niemand exakt sagen kann, wie das ausgelieferte PDF entstanden ist – welche Einstellungen, welche Vorlage, welcher Quellstand. Für ein Marketing-Faltblatt ist das egal. Für eine Betriebsanleitung, die Teil des Produkts ist und zehn Jahre nachweisbar bleiben muss, ist es ein Nachweisproblem: Wer nicht reproduzieren kann, kann auch nicht belegen. Automatisierung ist deshalb nicht primär eine Effizienz-, sondern eine Verlässlichkeitsfrage – die eingesparten Stunden sind die Zugabe. Wobei zweiundsiebzig Stunden eine ausgesprochen angenehme Zugabe sind, das soll nicht kleingeredet werden.

Dazu kommt ein Aspekt, der mit der EU-Maschinenverordnung an Gewicht gewinnt: Digitale Bereitstellung wird zum Normalfall, und was digital bereitgestellt wird, muss dauerhaft verfügbar bleiben. Ein PDF, das per Handarbeit entstanden ist und dessen Erzeugungsweg niemand mehr kennt, lässt sich nach fünf Jahren nicht ohne Weiteres in gleicher Fassung neu herstellen – etwa wenn eine Korrektur nachgeschoben oder eine Sprachfassung ergänzt werden muss. Reproduzierbarkeit ist damit kein Ingenieurs-Spleen, sondern die praktische Voraussetzung dafür, Pflichten über Jahre zu erfüllen.

Die Pipeline: fünf Stationen statt eines Knopfdrucks

Eine belastbare PDF-Produktion hat fünf Stationen, und keine davon ist verhandelbar. Station eins ist die Quelle: konsistent formatiert, versioniert abgelegt, mit einem eindeutigen Stand, auf den man zeigen kann. Station zwei ist die Erzeugung nach einem definierten Rezept – Vorlage, Exporteinstellungen, Zielprofil – das als Datei existiert und nicht als Erinnerung. Station drei ist das QS-Gate: die automatische Prüfung des Ergebnisses, bei der ein Befund den Prozess anhält, statt ihn zu begleiten. Station vier ist die Freigabe durch einen Menschen, dokumentiert mit Datum und Namen. Und Station fünf ist die Verteilung – an Kunde, Portal oder Produktion – plus die parallele Archivierung des ausgelieferten Stands.

Zwei Prinzipien halten diese Kette zusammen. Erstens: Korrigiert wird immer in der Quelle, nie im PDF. Das PDF ist ein Erzeugnis; wer darin nacharbeitet, hat beim nächsten Lauf wieder denselben Fehler und weiß nicht mehr, welche Fassung stimmt – dieselbe eiserne Regel wie bei der Word-Ausgabe aus dem RoboHelp-Beitrag, und sie gilt hier genauso. Zweitens: Das Gate ist ein Tor, kein Hinweisschild. Eine Prüfung, deren Befunde man übergehen kann, wird binnen weniger Releases übergangen; eine, die den Lauf abbricht, erzieht den Prozess. Klingt streng und spart erfahrungsgemäß die meisten Peinlichkeiten.

Was gehört ins Rezept der zweiten Station? Mehr als der Exportdialog vermuten lässt: der Quellstand mit Ablageort, die verwendete Vorlage oder das Ausgabe-Preset, die Exporteinstellungen samt Zielprofil, das Dateinamensschema mit Version und Sprache – und die Zielorte für Verteilung und Archiv. Gerade das Dateinamensschema wird gern unterschätzt: Ein sprechender Name mit Dokumentkennung, Version und Sprachkürzel ist der Unterschied zwischen einer geordneten Ablage und drei Dateien namens „Handbuch_final_neu2", von denen niemand mehr weiß, welche ausgeliefert wurde.

Abb.: Fünf Stationen von der Quelle bis zur Archivierung – mit dem QS-Gate als Stopppunkt statt Hinweisschild.

Die Wege je Werkzeugklasse

Wie die Erzeugung konkret aussieht, hängt vom Werkzeug ab – automatisierbar sind sie alle. In der Word-Welt liefert der eingebaute Export die Basis: PDF mit Lesezeichen aus den Überschriften-Vorlagen, Links aktiv, Dokumenteigenschaften als Metadaten. Für den Stapelbetrieb gibt es zwei etablierte Wege – Skripte, die Word fernsteuern und eine Liste von Dokumenten abarbeiten, oder serverseitige Konvertierung ohne Office-Installation, wie sie in Dokumenten-Plattformen üblich ist. Entscheidend ist nicht der Weg, sondern die Voraussetzung: Ohne die Vorlagen-Disziplin aus dem Word-Beitrag erzeugt jede Automatik nur schneller schlechte PDFs. Lesezeichen entstehen aus Überschriften-Vorlagen; direkt formatierter Fettdruck liefert keine.

In der Help-Authoring-Welt ist PDF ein Ausgabeziel neben Online-Hilfe und Word, konfiguriert als Preset oder Target – und die Ausgabegenerierung lässt sich über die Kommandozeile ansteuern, sodass Builds als geplanter Task oder in einer Automatisierungskette laufen. Bei den Langdokument-Spezialisten wie FrameMaker erzeugt man PDF buchweit mit Lesezeichen und funktionierenden Querverweisen; für wiederkehrende Läufe stehen Skript-Schnittstellen bereit. Und in der DITA- und XML-Welt ist die Automatisierung ohnehin der Normalfall: Die Publishing-Kette erzeugt PDF aus der Map, ist von Haus aus skriptgesteuert und fügt sich in jede CI-Pipeline – der Preis dafür ist, dass die Gestaltung des PDF Stylesheet-Arbeit bedeutet, wie schon der Oxygen-Beitrag angemerkt hat.

Der gemeinsame Nenner lohnt die Betonung: In jeder Klasse liegt die Qualität an einer anderen Stelle – bei Word in den Formatvorlagen, im Help-Authoring im Ausgabe-Preset, bei FrameMaker im Vorlagensatz, in der XML-Welt im Stylesheet –, aber in keiner Klasse liegt sie im Klickvorgang. Genau deshalb ist der Klickvorgang der Teil, der verschwinden darf. Wenn ein Mensch zum Erzeugen klicken muss, ist das keine Ausgabe, sondern ein Ritual.

In der Praxis existiert oft eine gemischte Landschaft: das Hauptwerk im Spezialwerkzeug, die Datenblätter in Word, die Online-Hilfe im Help-Authoring-Werkzeug – und aus allen dreien sollen PDFs fallen, die zueinander passen. Das ist machbar, verlangt aber eine bewusste Entscheidung darüber, was „zueinander passen" heißt: Gleiches Corporate Design und gleiche Metadaten-Konventionen sind realistisch, pixelgleiche Layouts sind es nicht. Wer diese Erwartung früh klärt, spart sich die Diskussion darüber, warum das Datenblatt-PDF andere Kopfzeilenabstände hat als das Handbuch – Web und Seite sind verschiedene Medien, verschiedene Werkzeuge erst recht.

Abb.: Vier Werkzeugklassen, vier Wege – automatisierbar sind alle, nur die Stellschraube für Qualität wandert.

Zielprofile: nicht jedes PDF ist dasselbe PDF

Ein verbreiteter Denkfehler lautet: Ein Dokument, ein PDF. Tatsächlich braucht dasselbe Handbuch je nach Verwendung unterschiedliche Erzeugnisse – und das ist kein Luxus, sondern folgt aus den Anforderungen: Was für den Bildschirm klein sein soll, muss für den Druck groß sein; was fürs Archiv autark sein muss, darf fürs Portal verlinkt bleiben. Die gute Nachricht ist, dass automatisierte Erzeugung diese Vervielfachung erst praktikabel macht: Drei Profile aus einer Quelle sind per Skript ein Dreizeiler und von Hand ein Nachmittag.

Bevor Rezepte geschrieben werden, gehört eine Frage geklärt, die erstaunlich oft übersprungen wird: Wofür ist dieses PDF eigentlich? Vier Zielprofile decken die Praxis ab, und sie stellen unterschiedliche Anforderungen. Das Bildschirm-PDF für Portal, Mail und digitale Auslieferung will Lesezeichen, funktionierende Links, moderate Bildauflösung und eine handliche Dateigröße – der Alltagsfall. Das Druck-PDF für Druckerei oder Beilagenproduktion braucht hohe Auflösung, den vereinbarten Farbraum und gegebenenfalls Beschnittzugaben – wobei die Vorgaben grundsätzlich von der Druckerei kommen und nicht geraten werden; ein kurzes Gespräch spart hier mehr als jede Recherche.

Das dritte Profil ist das für Technische Dokumentation strategisch wichtigste: das Archiv-PDF nach PDF/A. Hinter dem Kürzel steht eine Norm-Familie für die Langzeitarchivierung, deren Grundidee simpel ist – ein PDF/A-Dokument enthält alles, was zur originalgetreuen Darstellung nötig ist, und verbietet, was von der Umgebung abhängt: Schriften sind eingebettet, keine externen Verweise, keine Funktionen, die in zwanzig Jahren niemand mehr ausführen kann. Genau das braucht man für die Aufbewahrungspflicht: Technische Unterlagen zu Maschinen sind mindestens zehn Jahre nach dem Inverkehrbringen vorzuhalten, und zwar in der ausgelieferten Fassung. Ein gewöhnliches PDF mit Systemschriften und Verweisen ins Firmennetz ist dafür ein Risiko; das Archivprofil ist die Versicherung. Welche Variante der Familie zum eigenen Prozess passt, klärt man einmal mit dem Archiv- oder Compliance-Verantwortlichen und schreibt es ins Rezept.

Das vierte Profil gewinnt an Bedeutung: barrierefreie PDF-Dokumente, für die es mit PDF/UA einen eigenen Standard gibt. Verlangt wird eine getaggte Struktur – das Dokument weiß, was Überschrift, Absatz, Tabelle und Liste ist –, dazu Alternativtexte für Abbildungen, eine definierte Lesereihenfolge und eine gesetzte Dokumentsprache. Öffentliche Auftraggeber fragen zunehmend danach, und der europäische Rechtsrahmen für die Barrierefreiheit digitaler Angebote weitet den Kreis der Betroffenen aus; wer Verbraucherprodukte oder digitale Dienste anbietet, sollte die eigene Betroffenheit prüfen lassen. Die gute Nachricht: Ein sauber ausgezeichnetes Quelldokument liefert den Löwenanteil davon automatisch – Überschriften als Überschriften, Bilder mit Alternativtext, Sprache gesetzt. Aus einem chaotischen Dokument macht dagegen kein Zielprofil ein gutes PDF.

Zum Schluss der Zielprofil-Runde ein pragmatischer Hinweis zur Werkzeugfrage: Konformität gegen Archiv- oder Barrierefreiheits-Profile prüft man nicht mit Augenmaß, sondern mit einem Prüfwerkzeug, das einen Bericht ausgibt – vom kommerziellen Preflight-Programm bis zu freien Validierern, wie sie im Archivumfeld verbreitet sind. Welches davon zum Haus passt, ist eine Frage von Budget und Integrierbarkeit in die eigene Kette; wichtig ist nur, dass das Ergebnis maschinenlesbar zurückkommt und im Prüfschritt landet statt in einem Screenshot.

Abb.: Vier Zielprofile mit gemeinsamer Wurzel – die Qualität entsteht in der Quelle, nicht im Exportdialog.

Ein häufiger Einwand an dieser Stelle: „Bei uns ändert sich das Layout ständig, da lohnt kein Rezept." Erfahrungsgemäß ist das Gegenteil richtig – gerade bei häufigen Änderungen zahlt sich ein geschriebenes Rezept aus, weil die Änderung dann an einer Stelle passiert statt in den Gewohnheiten von vier Kollegen. Ein Rezept ist kein Beton; es ist eine Textdatei, die man ändert. Was es verhindert, ist nicht die Anpassung, sondern die unbemerkte Abweichung.

Der Multiplikator: Sprachen, Varianten, Stände

Richtig interessant wird Automatisierung dort, wo sich Ausgaben multiplizieren – und das ist in der Technischen Dokumentation die Regel, nicht die Ausnahme. Fünf Sprachen mal drei Produktvarianten mal zwei Zielprofile ergeben dreißig Dateien je Release; das ist von Hand nicht nur teuer, sondern praktisch garantiert fehlerhaft, weil niemand dreißigmal exakt dieselben Einstellungen trifft. Die Automatisierung dreht diese Rechnung um: Der Aufwand steckt einmalig im Aufbau, danach kostet die einunddreißigste Datei fast nichts – dieselbe Ökonomie wie beim Übersetzungsworkflow aus dem RoboHelp-Beitrag, nur eine Etage weiter hinten in der Kette.

Damit die Multiplikation nicht ins Chaos führt, braucht sie eine Matrix statt einer Liste im Kopf: eine schlichte Aufstellung, welche Kombination aus Dokument, Sprache, Variante und Zielprofil tatsächlich erzeugt wird und wohin sie geht. Diese Matrix ist gleichzeitig die Vollständigkeitsprüfung – am Ende eines Laufs wird abgeglichen, ob alle erwarteten Dateien existieren und plausible Größen haben. Fehlende Kombinationen sind der häufigste stille Fehler mehrsprachiger Produktion: Niemand vermisst ein PDF, nach dem gerade niemand fragt – bis der finnische Kunde anruft.

Ein Wort zu sprachspezifischen Eigenheiten, weil sie regelmäßig übersehen werden: Textexpansion verändert Umbrüche und Seitenzahlen, sodass Layoutprüfungen je Sprache nötig sind statt nur in der Ausgangssprache; Sprachen mit anderen Schriftsystemen brauchen passende, eingebettete Schriften; und die Dokumentsprache muss je Fassung korrekt gesetzt sein, sonst leiden Suche und Barrierefreiheit. Nichts davon verhindert Automatisierung – aber alles davon gehört ins Rezept und ins Gate, sonst produziert die Automatik die Eigenheiten zuverlässig falsch, dafür aber in allen Sprachen gleichzeitig. Die Prüfung je Sprachfassung ist deshalb kein Misstrauen gegen die Automatik, sondern ihr notwendiges Gegenstück.

Das QS-Gate: Automatisierung ohne Prüfung ist eine Fehlerkopiermaschine

Jetzt zum wichtigsten Kapitel, denn hier entscheidet sich, ob Automatisierung Segen oder Beschleuniger ist. Ein automatischer Lauf, der ungeprüft veröffentlicht, produziert Fehler nicht seltener, sondern schneller und in mehr Sprachfassungen gleichzeitig. Das Gegenmittel ist ein Prüfschritt zwischen Erzeugung und Freigabe, der maschinell abarbeitet, was maschinell prüfbar ist – und das ist mehr, als die meisten vermuten.

Sechs Prüfungen decken die Praxis ab. Vollständigkeit: Ist die Seitenzahl plausibel gegenüber dem letzten Stand, sind alle erwarteten Kapitel enthalten, fehlen Anhänge, stehen noch Platzhalter im Text? Verweise und Navigation: Ist das Verzeichnis aktuell – der Klassiker der vergessenen Feldaktualisierung –, sind Lesezeichen vorhanden, laufen Querverweise und Links ins Ziel? Schriften und Bilder: Sind alle Schriften eingebettet, stimmen Auflösung und Farbraum zum Zielprofil? Format-Konformität: Erfüllt die Datei das gewählte Profil – Archivtauglichkeit, Barrierefreiheit, Druckvorgaben –, geprüft mit einem Werkzeug, das einen Bericht ausgibt. Metadaten: Sind Titel, Sprache, Version und Dokumentstand gesetzt? Und schließlich die Sichtprüfung als kurze Stichprobe: Deckblatt, ein Kapitelanfang, eine Tabelle, eine Abbildung, die letzte Seite – fünf Minuten, in denen der Mensch das prüft, was keine Maschine beurteilt.

Der Aufbau eines solchen Gates ist übrigens kein Großprojekt. Er beginnt als Checkliste, die ein Mensch abarbeitet – allein das beseitigt die Hälfte der typischen Auslieferungspannen, weil aus Erinnerung ein Verfahren wird. Dann wandert Prüfung für Prüfung in die Automatik: erst die Konformitätsprüfung, weil es dafür fertige Werkzeuge mit Berichtsausgabe gibt, dann die einfachen Zählungen und Existenzprüfungen. Was am Ende beim Menschen bleibt, ist die Stichprobe und die Freigabeentscheidung – und genau dort gehört er hin. Alles andere ist Buchhaltung, und Buchhaltung macht die Maschine schneller, gründlicher und ohne schlechte Laune am Freitagnachmittag.

Was das Gate nebenbei liefert, ist der Nachweis. Jeder Lauf hinterlässt ein Protokoll: welcher Quellstand, welches Rezept, welche Prüfergebnisse, welche Freigabe durch wen und wann. Wird dieses Protokoll zusammen mit dem archivierten PDF abgelegt, entsteht genau die Dokumentationskette, nach der im Ernstfall gefragt wird – bei einer Produkthaftungsfrage ebenso wie bei einem Audit. Der Aufwand dafür ist minimal, weil die Informationen ohnehin anfallen; man muss sie nur aufheben statt wegwerfen. Wie die Aufbewahrungsseite dieser Kette aussieht, behandelt der Beitrag zu den Aufbewahrungspflichten.

Abb.: Sechs Prüfungen vor der Freigabe – fünf davon wandern in die Automatik, eine bleibt beim Menschen.

Der Einstieg: vom Ritual zum Rezept

Wie kommt man dahin, ohne ein Automatisierungsprojekt aufzusetzen? In vier Schritten, von denen die ersten beiden schon den größten Teil des Nutzens liefern. Schritt eins: das Rezept aufschreiben. Was wird aus welcher Quelle mit welchen Einstellungen für welches Ziel erzeugt, wie heißt die Datei, wohin geht sie? Eine Seite je Dokumentfamilie – und schon ist der Prozess reproduzierbar, auch wenn die Kollegin krank ist. Schritt zwei: die Prüfliste. Die sechs Prüfungen als Checkliste, abgehakt und mit dem Freigabevermerk archiviert. Beides zusammen kostet einen Vormittag und beseitigt den Großteil der Pannen – noch bevor eine einzige Zeile Skript existiert.

Schritt drei: automatisieren, was am meisten weh tut. Meist ist das die Wiederholung über Sprachen oder Varianten – ein Skript, das die Liste abarbeitet, statt dass ein Mensch zwölfmal denselben Dialog bedient. Dann die Konformitätsprüfung, weil sie zuverlässig Befunde liefert, die niemand von Hand findet. Schritt vier: den Lauf terminieren und melden lassen – nächtlich, wöchentlich oder ereignisgesteuert, mit Rückmeldung an einen benannten Verantwortlichen. Ab hier ist der Nachmittag vor der Auslieferung Geschichte; was bleibt, ist ein Blick in den Prüfbericht und die Freigabe.

Womit gebaut wird, ist erfreulich zweitrangig – und genau deshalb kein Grund zum Zögern. In der Microsoft-Welt greifen Teams typischerweise zu Skripten und geplanten Aufgaben, ergänzt um die Automatisierungsdienste der Plattform, wenn Ablage und Benachrichtigung in Microsoft 365 leben; in entwicklungsnahen Umgebungen läuft dieselbe Kette als Auftrag in der ohnehin vorhandenen Build-Infrastruktur. Wichtig sind nur drei Eigenschaften: Der Lauf ist wiederholbar ohne menschliches Zutun, er hinterlässt ein Protokoll, und er meldet sich bei Problemen. Alles andere ist Geschmack und Hausstandard.

Eine organisatorische Zutat gehört dazu, sonst verwaist die schönste Kette: eine benannte Verantwortung. Jemand ist für das Ausgabe-Rezept zuständig – pflegt es, wenn sich Vorlage, Zielprofil oder Ablageort ändern –, und jemand bekommt die Meldungen der Läufe. Das darf dieselbe Person sein, und es kostet im Betrieb Minuten; ohne Namen dahinter wird aus der Automatik binnen Monaten ein Blackbox-Skript, das niemand anzufassen wagt. Dieselbe Governance-Logik wie bei Vorlagen und Strukturmodellen in dieser Serie: Betriebsmittel brauchen Besitzer.

Und noch ein Wort zum Zusammenspiel mit der Ablage, denn dort endet die Kette: Ein erzeugtes PDF, das in einem Netzlaufwerk-Unterordner landet, ist erst halb ausgeliefert. Die tragfähige Variante legt die Datei mit ihren Metadaten in eine geordnete Bibliothek – Dokumentkennung, Version, Sprache, Freigabedatum als Eigenschaften, nicht nur im Dateinamen –, sodass Suche, Berechtigungen und Aufbewahrungsregeln greifen können. Wie diese Ablageseite aussieht, ist Thema eigener Beiträge dieser Serie; für die Ausgabekette genügt der Merksatz: Der Zielort gehört ins Rezept, und er heißt selten „Desktop".

Fazit

Die PDF-Ausgabe ist der am häufigsten übersehene Automatisierungskandidat der Technischen Redaktion – nicht weil sie schwierig wäre, sondern weil ihre Handarbeit so selbstverständlich geworden ist, dass sie niemand mehr sieht. Dabei liegt der Weg offen: eine saubere Quelle, ein aufgeschriebenes Rezept, ein QS-Gate, das anhält statt hinzuweisen, und ein Zielprofil, das zum Zweck passt – mit dem Archivzweig als eigener, oft vergessener Pflichtübung. Automatisiert wird dann Schritt für Schritt, beginnend bei dem, was am meisten nervt. Und der Nebeneffekt ist der eigentliche Gewinn: Aus einer Erinnerungsleistung einzelner Kollegen wird ein Verfahren, das auch dann funktioniert, wenn diese Kollegen im Urlaub, im Projekt oder in Rente sind.

Der beste erste Schritt kostet einen Vormittag: Rezept und Prüfliste aufschreiben, für eine Dokumentfamilie. Alles Weitere ergibt sich daraus fast von selbst. Wenn du dabei Unterstützung willst – von der Prozessaufnahme über den Aufbau der Ausgabe- und Prüfkette bis zur Anbindung an die Ablage in Microsoft 365: Genau dabei unterstütze ich dich gern; die Details findest du auf der Beratungsseite zur Technischen Dokumentation.

Häufige Fragen zur automatisierten PDF-Ausgabe

Lässt sich PDF-Erzeugung auch aus Word automatisieren?

Ja. Der eingebaute Export liefert PDF mit Lesezeichen aus den Überschriften-Vorlagen; für den Stapelbetrieb gibt es Skripte, die Word fernsteuern und Dokumentlisten abarbeiten, sowie serverseitige Konvertierungswege ohne lokale Office-Installation. Die Voraussetzung ist allerdings nicht technischer Natur: Ohne konsequente Formatvorlagen-Nutzung entstehen PDFs ohne Navigation und ohne Struktur – die Automatik erzeugt dann nur schneller schwache Ergebnisse.

Was ist PDF/A – und brauchen wir das?

PDF/A ist die Norm-Familie für die Langzeitarchivierung von PDF-Dokumenten (ISO 19005). Der Grundgedanke: Alles zur originalgetreuen Darstellung Nötige steckt in der Datei, externe Abhängigkeiten sind ausgeschlossen. Für Technische Dokumentation ist das hochrelevant, weil technische Unterlagen zu Maschinen mindestens zehn Jahre nach dem Inverkehrbringen vorzuhalten sind – und zwar in der ausgelieferten Fassung. Welche Variante der Familie passt, klärt man einmal mit dem Archiv- oder Compliance-Verantwortlichen und hält sie im Ausgabe-Rezept fest.

Wie stellen wir sicher, dass automatisch erzeugte PDFs korrekt sind?

Mit einem QS-Gate zwischen Erzeugung und Freigabe, das den Lauf bei Befunden anhält. Sechs Prüfungen decken die Praxis ab: Vollständigkeit, Verweise und Navigation, Schrifteinbettung samt Bildqualität, Konformität gegen das Zielprofil, Metadaten – und eine kurze menschliche Sichtprüfung als Stichprobe. Wichtig ist der Charakter des Gates: Eine Prüfung, deren Befunde man übergehen kann, wird binnen weniger Releases übergangen.

Müssen unsere PDFs barrierefrei sein?

Das hängt von Auftraggebern und Produktkontext ab – öffentliche Auftraggeber fragen zunehmend danach, und der europäische Rechtsrahmen zur Barrierefreiheit digitaler Angebote weitet den Kreis der Betroffenen aus; die eigene Betroffenheit sollte rechtlich geprüft werden. Technisch ist der Zielstandard PDF/UA: getaggte Struktur, Alternativtexte, definierte Lesereihenfolge, gesetzte Sprache. Der Löwenanteil davon entsteht automatisch, wenn die Quelle sauber ausgezeichnet ist – ein weiteres Argument für Formatvorlagen-Disziplin.

Wo fangen wir an, wenn heute alles Handarbeit ist?

Nicht beim Skript, sondern beim Aufschreiben: ein Ausgabe-Rezept je Dokumentfamilie – Quelle, Vorlage, Einstellungen, Zielprofil, Dateiname, Zielorte – plus die Prüfliste. Das kostet einen Vormittag und macht den Prozess reproduzierbar, unabhängig von einzelnen Personen. Automatisiert wird danach in der Reihenfolge des Schmerzes: zuerst die Wiederholung über Sprachen und Varianten, dann die Konformitätsprüfung, zuletzt der terminierte Lauf mit Rückmeldung an einen benannten Verantwortlichen.