PDF-Tags aus Coding-Sicht

Worum geht es bei PDF-Tags?

Ein PDF zeigt auf der Seite Glyphen — also visuell positionierte Zeichen. Was es nicht aus sich heraus weiß: Welche Glyphen gehören zu einer Überschrift? Was ist ein Absatz, was eine Tabelle, was eine Bildbeschreibung? Genau diese Information liefert der Struktur-Baum — eine zweite Datenebene, die parallel zum Content-Stream im Dokument hinterlegt ist. Sie sagt assistiven Technologien, was die sichtbaren Glyphen bedeuten.

PDF/UA (ISO 14289) macht diesen Baum zur Pflicht, sobald ein PDF als barrierefrei gelten soll. PDF 2.0 (ISO 32000-2:2020) beschreibt die zugrunde liegenden Strukturen in Abschnitt 14 „Document interchange" und behandelt Tagging als integralen Teil des Formats — nicht mehr als Erweiterung wie noch in PDF 1.7. Der Tagbaum ist also keine Eigenheit eines Tools, sondern Teil der ISO-Norm.

Der Struktur-Baum: StructTreeRoot, StructElem, Kids

Im PDF-Dokumenten-Catalog gibt es einen Eintrag /StructTreeRoot . Dieser zeigt auf das Wurzelobjekt des Struktur-Baums. Von dort verzweigt sich eine Hierarchie aus Struktur-Elementen(PDF-Typ /StructElem ), bis am untersten Ende konkrete Inhalte auf den Seiten referenziert werden.

Jedes Struktur-Element ist ein Dictionary mit einem Typ, einer Rolle (etwa /H1 , /P , /Figure ) und einem Kinder-Array /K . Was im /K steht, regelt ISO 32000-2 Abschnitt 14.7: erlaubt sind eine Ganzzahl (eine MCID, dazu gleich mehr), ein weiteres /StructElem , ein Marked-Content-Reference-Dictionary /MCR , eine Objekt-Referenz /OBJR — oder ein Array beliebiger dieser Varianten.

5 0 obj 
<<
  /Type /StructElem
  /S    /H1 % Rolle: Überschrift Ebene 1 
/P    4 0 R 
 % Parent (Eltern-Element) 
/Pg   2 0 R 
 % Seite, auf der der Inhalt liegt 
/K    [ 0 1 ] % Kinder: zwei MCIDs auf Seite 2 
/Alt  (Kapitel 1 — Einleitung)
>> endobj 

Dieser Knoten sagt: „Ich bin eine H1, mein Elternknoten ist Objekt 4, meine inhaltlichen Glyphen liegen auf der Seite 2 (Objekt 2) mit den Marked-Content-IDs 0 und 1." Genau dort schlägt der Tagbaum die Brücke zur sichtbaren Seite.

MCIDs und der Parent-Tree

MCID steht für Marked Content Identifier. Jeder Inhaltsabschnitt auf einer Seite kann mit einer fortlaufenden Ganzzahl markiert werden. Innerhalb einer Seite sind MCIDs eindeutig; in verschiedenen Seiten können dieselben Zahlen wieder auftauchen. Sie zeigen also nicht global eindeutig auf einen Inhalt — die Eindeutigkeit entsteht erst durch die Kombination aus Seite und MCID.

Damit assistive Technologien von einem Glyph zurück zum Tag finden, gibt es im Struktur-Baum-Wurzel ein zweites Verzeichnis: den /ParentTree . Das ist ein Number-Tree, der pro Seite eine Liste hält. Index in dieser Liste ist die MCID; der Wert ist eine Referenz auf das passende /StructElem . ISO 32000-2 Abschnitt 14.7.5 beschreibt das im Detail. Wer einmal die iText-Dokumentation oder pikepdfs Issue 461 dazu liest, erkennt schnell: der Parent-Tree ist eine der häufigsten Fehlerquellen in selbstgebauten Pipelines, weil seine Index-Logik leicht aus dem Takt gerät.

Marked Content im Stream: BDC und EMC

Die MCID selbst wird im Content-Stream geboren. PDF kennt dafür zwei Operatoren: BDC ( Begin Marked Content with Dictionary ) und EMC ( End Marked Content ). Alles zwischen diesen beiden Markern gehört logisch zur gleichen MCID.

/H1 <</MCID 0>> BDC 
 % Marked Content beginnt, MCID 0 
 BT 
/F1 24 Tf 
72 720 Td 
(Kapitel 1) Tj 
 ET 
 EMC 
 % Marked Content endet 
/P <</MCID 1>> BDC 
 % Nächster Marked-Content-Block, MCID 1 
 BT 
/F2 11 Tf 
72 690 Td 
(Eine kurze Einleitung.) Tj 
 ET 
 EMC 

Der erste Operand vor BDC ist der Tag-Name. Das nachfolgende Dictionary enthält mindestens den Eintrag /MCID . Diese Zahl ist es dann, die im Struktur-Baum-Knoten unter /K auftaucht und im Parent-Tree als Index dient. So schließt sich der Kreis: vom Struktur-Element zur Seite, von der Seite per Parent-Tree zurück zum Struktur-Element.

Role-Mapping und Standard-Strukturtypen

ISO 32000-2 definiert in Abschnitt 14.8 einen Satz an Standard-Strukturtypen. Sie sind in einem Namensraum definiert, der mit PDF 2.0 von /StandardStructureType auf einen einheitlichen Standard-Namespace umgestellt wurde. Eigene Tag-Namen sind erlaubt, müssen aber per /RoleMap auf einen Standardtyp abgebildet werden — sonst weiß die assistive Technologie nicht, was sie damit anfangen soll.

Tooling-Pipelines: wie eigene Tags entstehen

In der Praxis gibt es drei Wege, einen PDF-Tagbaum zu erzeugen — und alle drei sind im DACH-Raum produktiv im Einsatz:

1. Office-Pipelines(Word, LibreOffice, InDesign) liefern getaggte PDFs heraus, sobald die Quelle ordentlich strukturiert ist. Die Programme schreiben den Tagbaum selbst, der Quelltext der Anwender:in steuert die Rollen indirekt über die verwendeten Formatvorlagen.
2. LaTeX-Tagging-Projekt. Ulrike Fischers laufende Implementierung in LaTeX3 (Paket tagpdf ) generiert seit 2020 einen vollständigen Tagbaum aus dem LaTeX-Quelltext heraus. Der TUGboat-Artikel von 2020 beschreibt das Konzept — inklusive der Komplexität rund um den Parent-Tree, die später in einem GitHub-Issue zur Beispiel-Datei dokumentiert wurde.
3. Eigene Toolchain mit Bibliotheken wie pikepdf (Python/qpdf), pdf-lib (JavaScript) oder iText (Java/.NET). Hier baut man Struktur-Elemente, MCIDs und Parent-Tree von Hand — entweder beim Erzeugen eines PDF aus einem anderen Format oder beim Nachträglichen Reparieren bestehender Dateien.