PDF mit Apache-FOP

Unter Verwendung des sogenannten Apache Formatting Objects Processors (FOP) lässt sich auf der Grundlage von spezifischen XSL-FO-Layout-Beschreibungen insbesondere das Ausgabeformat PDF erzeugen. Als freie Java-Anwendung zur Verfügung gestellt wird Apache-FOP von der ehrenamtlich zur Förderung von Apache-Software-Projekten arbeitenden Organisation Apache Software Foundation kontinuierlich weiterentwickelt. Eine allgemeine Einführung sowie eine umfassende Dokumentation zur Syntax von XSL-FO-Dateien auf Deutsch bietet die data2type GmbH.

Der Einsatz von Apache-FOP zur Erzeugung von PDF-Dokumenten, die den Test mit dem Prüftool PDF Accessibility Checker 2024 (PAC) vollständig bestehen, ist insbesondere dann empfehlenswert, wenn die dazu benötigte XSL-FO Preview automatisiert aus einem XML-Dokument generiert werden kann. In diesem Fall können mithilfe von XSL-Transformationen alle benötigten Voreinstellungen eingerichtet und ohne weiteren Anpassungsbedarf für gleichartige PDF-Dokumente genutzt werden. Dazu werden insbesondere die im Folgenden beschriebenen Einstellungen benötigt.

Die Einstellung des Dokumenttitels erfolgt in den fo:declarations:

 1   <fo:declarations>
 2      <x:xmpmeta xmlns:x="adobe:ns:meta/">
 3         <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
 4            <rdf:Description rdf:about="">
 5               <dc:title>
 6                  <rdf:Alt>
 7                     <rdf:li xml:lang="x-default">Dokumenttitel</rdf:li>
 8                  </rdf:Alt>
 9               </dc:title>
10            </rdf:Description>
11         </rdf:RDF>
12      </x:xmpmeta>
13   </fo:declarations>

Die Dokumentation zum Feature Accessibility von Apache-FOP ist diesbezüglich nicht ganz vollständig.

In den fo:declarations könnten weitere Angaben eingetragen werden, wie z. B. zur Dokumentsprache oder zu „creator“ oder auch zu „description“ wie in der Apache-FOP Referenz ausgewiesen. Allerdings kann es dann bei Verwendung des PDF/A-Standards für die Langzeitarchivierung zu Problemen beim Test mit dem Tool veraPDF kommen (siehe auch unten unter Prüfung der Barrierefreiheit sowie Abschnitt Hinweise zu Tools zur Überprüfung der Barrierefreiheit).

Die Einstellung der globalen Dokumentsprache kann direkt im fo:root-Element vorgenommen werden:

1<fo:root language="DE" country="DE">

Den Elementen fo:external-graphic sowie fo:basic-link muss mittels fox:alt-text-Attribut ein Alternativtext zugewiesen werden.

Für die Transformation mit Apache-FOP muss tatsächlich für alle fo:external-graphic- sowie fo:basic-link-Elemente ein Alternativtext bereitgestellt werden. D. h. insbesondere auch dann, wenn sich die Elemente in einem Bereich befinden, der als sogenanntes Artefakt gekennzeichnet ist (siehe auch unten unter Kopf- und Fußzeilen). Die Prüfung auf Vorhandensein von Alternativtexten und die Kennzeichnung als Artefakt erfolgen unabhängig voneinander.

Das Feature Accessibility muss in der Konfiguration eingetragen werden:

1   <accessibility>true</accessibility>
2   <renderers>
3      <renderer mime="application/pdf">
4         <pdf-ua-mode>PDF/UA-1</pdf-ua-mode>  
5      </renderer>
6   </renderers>

Einige im Programmcode bereitgestellten Bestandteile (wie insbesondere Alternativtexte) werden erst mit dieser Einstellung bei der Transformation in das PDF-Dokument übertragen. Darüber hinaus werden mit dieser Einstellung bei der Transformation konkrete Fehlermeldungen erzeugt, die zur weiteren Optimierung genutzt werden können.

Apache-FOP sorgt mit eingeschaltetem Feature Accessibility automatisch für das Tagging der einzelnen Elemente. Es ist möglich, manuell einzugreifen und das Tagging bewusst zu steuern. Zu diesem Zweck lässt sich das role-Attribut einsetzen, um dem jeweils zugehörigen Element eine passende Rolle zuzuweisen. Manuelles Nachbessern könnte insbesondere bei einem komplexen Design zwingend erforderlich sein.

Lesezeichen lassen sich mittels fo:bookmark-tree-Element einfügen (siehe Dokumentation zur Umsetzung von Lesezeichen mit Apache-FOP).

Kopf- sowie Fußzeilen lassen sich mithilfe von fo:static-content-Elementen umsetzen. Wenn es sich dabei um Design- bzw. „Schmuckelemente“ ohne relevante Inhalte handelt, sollten diese Elemente als Artefakt gekennzeichnet werden (siehe Präsentationsfolien zur Vorstellung des Praxisbeispiels MAK Collection bei der 111. BiblioCon im barrierefreien PDF-Format, 2023, S.7).

Dazu werden die betroffenen fo:static-content-Elemente folgendermaßen mittels role-Attribut ausgezeichnet:

1<fo:static-content flow-name="header" role="artifact">

Die Kennzeichnung als Artefakt (Englisch: „artifact“) wird insbesondere bei fo:static-content- sowie fo:wrapper-Elementen übertragen. Dabei ist an dieser Stelle die Kleinschreibung entscheidend – insbesondere im Unterschied zur Schreibweise mit einem Großbuchstaben in allen anderen Fällen.

Die Transformation kann z. B. mithilfe des Oxygen XML Editor oder auch als Job in der GitLab Pipeline ausgeführt werden.

Ein möglicher Aufruf im Linux-Terminal (unter Verwendung geeigneter Pfadangaben) könnte folgendermaßen aussehen, wobei die Datei „in.xml“ alle benötigten XSL-FO-Auszeichnungen enthält und die Datei „out.pdf“ die Ausgabedatei im Ausgabeformat PDF darstellt:

1docker run --user $(id -u):$(id -g) -v $(pwd):/src -w /src -it --rm chrwahl/fop -c fop_cfg.xml in/in.xml -pdf out/out.pdf

Bei der Datei „fop_cfg.xml“ handelt es sich um die entsprechend eingerichtete Konfigurationsdatei.

Der Programmierung eines automatisierten Workflows – ausgehend von einem Ausgangs-XML-Dokument, das ggf. aus einer Word-Datei extrahiert wird, über ein XML-Dokument, das alle benötigten XSL-FO-Auszeichnungen enthält, bis hin zum Ausgabeformat PDF – sind dabei keine Grenzen gesetzt.

Das PDF-Dokument sollte bereits während des Erzeugungsprozesses sowie abschließend mit dem PDF Accessibility Checker (PAC) getestet werden. axes4 bietet eine webbasierte Version von PAC, die entsprechend nicht nur unter Windows nutzbar ist.

Da die Nutzbarkeit mit einem starken Vergrößerungsfaktor für Menschen mit Sehbeeinträchtigung entscheidend ist, sollte bei der Prüfung eines PDF-Dokuments außerdem testweise ein Vergrößerungsfaktor von z. B. 300% eingestellt werden. Insbesondere im Zusammenhang mit der Nutzung des PDF/A-Standards (zusätzlich zu PDF/UA) ließ sich diesbezüglich eine fatale Auswirkung auf den Auslösebereich bei internen Verlinkungen beobachten: ein Schrumpfen auf die obere linke Ecke (siehe Präsentationsfolien zur Vorstellung des Praxisbeispiels MAK Collection bei der 111. BiblioCon im barrierefreien PDF-Format, 2023, S.7).

Einstellung der Nutzung des PDF/A-Standards zusätzlich zu PDF/UA in der FOP-Konfiguration:

1   <accessibility>true</accessibility>
2   <renderers>
3      <renderer mime="application/pdf">
4         <pdf-ua-mode>PDF/UA-1</pdf-ua-mode>  
5         <pdf-a-mode>PDF/A-1a</pdf-a-mode>
6      </renderer>
7   </renderers>

Um sich die unterschiedlichen Stärken einzelner Tools zunutze zu machen, ist es darüber hinaus generell empfehlenswert, mehrere Tools zur Begutachtung hinzuzuziehen. Vergleiche dazu auch den Abschnitt Hinweise zu Tools zur Überprüfung der Barrierefreiheit.

Die besten Ergebnisse hinsichtlich des PDF/A-Standards konnten ohne weitere Deklaration der Version erzielt werden. Informationen zu den bislang in Apache-FOP implementierten Versionen liefert die Dokumentation unter https://xmlgraphics.apache.org/fop/2.10/configuration.html.

Mit einer Ligatur für z. B. die Kombination aus dem Großbuchstaben T mit einem direkt darauf in Kleinschreibung folgenden Buchstaben h soll ein gefälliges Erscheinungsbild im Schriftsatz sichergestellt werden. Der senkrechte Strich im kleingeschriebenen Buchstaben h soll dabei insbesondere nicht über den Querbalken des Großbuchstaben T hinausragen. Ziel ist eine Verbesserung der Lesbarkeit des visuellen Erscheinungsbildes.

Die Zeichencodierung von Ligaturen ist jedoch in vielen Schriftarten oftmals nicht eindeutig. Dies hat zur Folge, dass die betroffene Ligatur von einem Screenreader nicht korrekt ausgelesen werden kann: Die in dieser Ligatur zusammengefassten Buchstaben werden in einem solchen Fall übersprungen und das Wort wird unverständlich.

Visuell lassen sich die Fehlerquellen in einer geeigneten Screenreader-Vorschau (z. B. callas) aufspüren. Oder aber indem Sie den Text aus dem in Adobe Acrobat geöffneten PDF-Dokument herauskopiert und in einen Windows-Editor einfügen. In der Screenreader-Vorschau von callas und auch im Windows-Editor erscheinen Zeichen mit uneindeutiger Codierung in Form eines „Kästchens“. Im Prüftool PAC führt das Vorkommen von Zeichen, deren Codierung sich nicht eindeutig zuordnen lässt, (derzeit) nicht zu einem Fehler.

Einen möglichen Lösungsansatz bietet in diesem Fall der Einsatz des geschützten Leerzeichens ohne eigene Breite () als Bindehemmer. Unter Verwendung der 14 Basis Fonts von Adobe konnte diese Problematik bislang nicht beobachtet werden. Achtung: Mit jeder neuen Version für Apache-FOP können weitere Ligaturen hinzukommen. Dabei ist dann ggf. auch nur ein Buchstabe der Ligatur nicht auslesbar.

Für grundlegende Abhilfe sorgt die folgende Einstellung in der Konfiguration:

1<complex-scripts disabled="true"/>

Bei der Transformation mit Apache-FOP kann eine automatische Silbentrennung verwendet werden. Alternativ könnten auch manuell bedingte Trennzeichen (­) eingefügt werden.

Bei der Kombination einer Schriftart, die nicht den 14 Basis Fonts entspricht, mit (automatischer bzw. manueller) Silbentrennung und dem Feature Accessibility konnte folgendes Phänomen beobachtet werden: Beim Herauskopieren von Text aus dem in Adobe Acrobat geöffneten PDF-Dokument in einen Windows-Editor kam es bei allen Zeilen, die mit einer Silbentrennung enden, zu zahlreichen Doppelungen. Beim Herauskopieren in ein Microsoft-Programm wie Word sowie beim Herauskopieren aus dem in einem Browser geöffneten PDF-Dokument in einen Windows-Editor kam es nicht zu Doppelungen.

Einen möglichen Lösungsansatz bietet in diesem Fall der Einsatz eines speziellen Schutzes für das bedingte Trennzeichen gemeinsam mit den beiden umgebenden Buchstaben innerhalb eines separaten inline-Elements.

Für grundlegende Abhilfe sorgt auch in diesem Fall die folgende Einstellung in der Konfiguration:

1<complex-scripts disabled="true"/>

Ein fo:inline-container-Element wird nicht in Form einer separaten Ebene in den Strukturbaum übernommen. Es scheint vielmehr ein Feature zu sein, dass fo:inline-container-Elemente durch einen leeren Bereich voneinander abgesetzt werden.

Um ein Annotation-Element zu erzeugen, genügt die folgende Auszeichnung:

role="Annot"

Ein Annotation-Element benötigt zwingend einen Alternativtext. Apache-FOP überträgt die Angaben für das fox:alt-text-Attribut (derzeit) nicht in einem fo:block-Element und auch nicht in fo:wrapper-Elementen.

Bei Verwendung von Apache-FOP Version 2.7 bietet der Einsatz eines fo:basic-link-Elements mit einem nicht-existierenden Ziel einen möglichen Lösungsansatz. Bei der Transformation wird Ihnen in diesem Fall eine entsprechende Warnung dazu angezeigt, dass eine Verlinkung ins Leere weist. Nachdem Sie sich vergewissert haben, dass die Warnungen auf genau die Stellen hinweisen, bei denen Sie sich bewusst für diesen Lösungsansatz entschieden haben, um einen Alternativtext übertragen zu können, können Sie diese Warnung in Kauf nehmen. Warnungen, die sich auf andere Stellen beziehen, sollten sorgsam geprüft und korrigiert werden. Im folgenden Beispiel wird das Annotation-Element genutzt, um eine formatierte Zahlenangabe mit Maßangabe mit einem geeigneten Alternativtext zu versehen.

1<fo:basic-link role="Annot" internal-destination="Null" fox:alt-text="1234 Quadratmeter">1 234 m²</fo:basic-link>

Ohne Textalternative wird die formatierte Zahlenangabe „1 234 m²“ von einem Screenreader ggf. folgendermaßen vorgelesen: eins zweihundertvierunddreißig m zwei. Diese Ausgabe ist insbesondere dann zu erwarten, wenn die hochgestellte Zwei durch Formatierung realisiert wurde. Alternativ könnte dafür das spezifische Zeichen aus dem Unicode-Zeichensatz verwendet werden, der dann von einem Screenreader ggf. als „hochgestellte Zwei“ ausgelesen wird.

Mit VoiceOver wird bei einem Annotation-Element das gelesen, was im PDF-Dokument sichtbar ist. NVDA liest bei einem Annotation-Element den Alternativtext.

In der Screenreader-Vorschau von PAC erscheint ein Annotation-Element innerhalb eines regulären P-Tags wie ein Span-Inline-Element. Angezeigt wird der im PDF-Dokument dargestellte Text. Der zugehörige Alternativtext ist nicht ersichtlich.

Um ein Formula-Element zu erzeugen, genügt die folgende Auszeichnung:

role="Formula"

Ein Formula-Element benötigt ebenfalls zwingend einen Alternativtext.

Ein möglicher Lösungsansatz wurde für das Annotation-Element beschrieben.

Mit VoiceOver wird ein Formula-Element als Bild gekennzeichnet, gelesen wird der Alternativtext. NVDA liest den Alternativtext zu einem Formula-Element ggf. nur nach manueller Bearbeitung beispielsweise mit Adobe Acrobat Pro vor. Dafür muss insbesondere ein Eintrag im Feld „Originaltext“ vorgenommen werden. Die Übertragung eines Eintrags für Originaltext bei der Transformation mit Apache-FOP ist bislang nicht gelungen. Getestet wurde u. a. das fox:actual-Attribut:

fox:actual="Originaltext"

Die Screenreader-Vorschau von PAC zeigt ein unbearbeitetes Formula-Element als (leeres) Bild mit zugehörigem Alternativtext. Der im PDF-Dokument dargestellte Text ist nicht ersichtlich. Ein bearbeitetes Formula-Element erscheint als reguläres P-Tag ohne weitere Kennzeichnung. Angezeigt wird der zugehörige Originaltext. Weder der zugehörige Alternativtext, noch der im PDF-Dokument dargestellte Text sind ersichtlich.

Ein fo:footnote-Element wird von Apache-FOP automatisch als Note-Element getaggt.

Ein Note-Element benötigt zwingend eine id. Die Übertragung eines entsprechenden Eintrags für ein fo:footnote-Element bei der Transformation mit Apache-FOP ist bislang nicht gelungen.

Ein möglicher Lösungsansatz, um die Funktionalität von Fußnoten dennoch nutzen zu können, besteht darin, das fo:footnote-Element zu kaschieren, und zwar beispielsweise folgendermaßen:

1<fo:footnote role="Span">

Eine interne Verlinkung mit dem Alternativtext „intern zu Fußnote“ sowie der zugehörigen Fußnotenziffer soll weitere Orientierungshilfe bieten (siehe dazu auch den Hinweis im direkt folgenden Abschnitt).

NVDA liest den Fußnotentext bei einer mit Apache-FOP erzeugten Fußnote direkt im Anschluss an die zugehörige Fußnotenziffer vor. Es ist daher dringend ratsam, Fußnoten nur dann innerhalb eines Satzes zu platzieren, wenn der Einschub den Kontext nicht zerreißt. Dass dieser Abschnitt im PDF-Dokument als Fußnote umgesetzt ist, wird lediglich über einen entsprechenden Hinweis bei einer zugehörigen internen Verlinkung gekennzeichnet.

• Hinweise zu Tools zur Überprüfung der Barrierefreiheit

• Apache Formatting Objects Processors (FOP) (The Apache Software Foundation)
• The Apache Software Foundation (The Apache Software Foundation)
• Dokumentation zur XSL-FO-Syntax von Apache-FOP (data2type GmbH)
• Dokumentation zum Feature Accessibility von Apache-FOP auf Englisch (The Apache Software Foundation)
• Dokumentation zur Umsetzung von Lesezeichen mit Apache-FOP auf Englisch (data2type GmbH)
• Präsentationsfolien zur Vorstellung des Praxisbeispiels MAK Collection bei der 111. BiblioCon im barrierefreien PDF-Format (Anja Ziemer)
• Oxygen XML Editor (SyncRO Soft SRL)
• PDF Accessibility Checker (PAC) (axes4)
• webbasierte Version des PDF Accessibility Checkers (PAC) (PAC, gewartet von axes4)
• Dokumentation zur Konfiguration von Apache-FOP auf Englisch (The Apache Software Foundation)
• callas pdfToolbox Desktop (callas software GmbH)
• Dokumentation zu den 14 Basis Fonts bei Adobe (Oracle)
• Screenreader NVDA (NV Access)

• Praxisbeispiel MAK Collection - Tagungsbeitrag zur automatisierten Erstellung von Journal-Ausgaben bei ZB MED im barrierefreien PDF-Format (Anja Ziemer, o-bib. Das offene Bibliotheksjournal)

Informationen zu diesem Artikel

Verfasst von:

Anja Ziemer

Datum:

22.10.2025

Lizenz:

CC-BY-SA 4.0

Version:

2.0

Gerne können Sie uns Feedback per E-Mail zu unserer Handreichung senden!