Technische Konzepte

Technische Konzepte von PDF/A

Grundlegende PDF/A-Anforderungen

PDF/A erfordert bestimmte PDF-Features and verbietet andere:

  • Um die genaue visuelle Reproduzierbarkeit von Text zu gewährleisten, müssen alle in einem Dokument verwendeten Fonts eingebettet sein.
  • Um die genaue Farb-Reproduzierbarkeit zu gewährleisten, müssen alle in einem Dokument verwendeten Farben in einer geräteunabhängigen Art und Weise definiert sein.
  • Metadaten müssen im XMP-Format eingebettet sein. Die PDF/A-Komformitätsstufe muss mit bestimmten XMP-Properties beschrieben worden sein.
  • Verschlüsselung darf nicht verwendet werden, um sicherzustellen, dass auf Dokumentinhalte ohne jede Einschränkung immer zugegriffen werden kann.
  • Bestimmte Anforderungen an Anmerkungen und Formularfelder garantieren, dass die Visualisierung unverändert bleibt und dass Bildschirm- und Druckausgabe identisch sind.

Zusätzlich zu diesen einfachen Anforderungen erfordert PDF/A jedoch verschiedene andere PDF-Features (z.B. bestimmte Einträge in den Font-Datenstrukturen) und verbietet einige kritische Strukturen (z.B. bestimmte Kombinationen von TrueType-Fonts und -Encodings). Es gibt viele Aspekte, die umgesetzt und von Software-Entwicklern überprüft werden müssen, damit ein standardkonformes PDF/A-Produkt daraus entsteht, denn PDF/A ist viel mehr als einfach nur »PDF mit eingebetteten Fonts und ohne Verschlüsselung«!

Weitere Einschränkungen in PDF/A-1

PDF/A-1 leidet ein bisschen darunter, dass es der erste Standard in der PDF/A-Familie war: Die Norm wurde zu einer Zeit erstellt, als wichtige PDF-Konzepte noch nicht ausgereift waren. Als Ergebnis sind die folgenden Funktionen in PDF/A-1 verboten, aber in den neueren Teilen PDF/A-2 und PDF/A-3 erlaubt:

  • Alle Funktionen, die PDF 1.5 oder höher erfordern, z.B. JPEG-2000-Kompression und Ebenen (optionale Inhalte).
  • Transparenz: Obwohl Transparenz in PDF 1.4 möglich ist, wurde es für die Archivierung zu der Zeit als ungeeignet angesehen, weil es keine konsistente Beschreibung und Umsetzung für Transparenz-Unterstützung gab. Da identisches Verhalten nicht für alle PDF-Viewer garantiert werden konnte, wurde Transparenz in PDF/A-1 generell untersagt. Erst nach der Veröffentlichung von PDF/A-1 wurde die genaue Semantik der PDF-Transparenz geklärt und in ISO 32000-1 standardisiert; spätere Standards erlauben daher von vornherein die Verwendung von Transparenz.
  • Dateianhänge waren in PDF/A-1 verboten, um alle Dokumentinhalte voll archivierbar zu machen. Obwohl Dateianhänge in PDF/A-2 erlaubt sind, werden sie hier auf PDF/A-1- oder PDF/A-2-konforme Dateien beschränkt, damit angehängte Dateien auf jeden Fall eindeutig reproduziert werden können. Bei PDF/A-3 werden diese Regeln weiter gelockert, hier sind beliebige Dateitypen als Anhang erlaubt.

Geräteunabhängige Farbspezifikation

Um eine konsistente Farbwiedergabe über Ausgabegeräte und Zeit hinweg sicherzustellen, verlangt PDF/A die Verwendung von geräteunabhängigen Farben. In der Regel wird dies über ICC-Profile oder CIE-Lab-Farbspezifikationen realisiert. Die optionale Ausgabebedingung beschreibt die Farbeigenschaften des Dokuments. Während diese Konzepte in der grafischen Industrie weit verbreitet sind, sind PDF-Entwickler in einem Unternehmen nicht unbedingt mit Farbmanagement vertraut und müssen sich erst mit ICC-Profilen und verwandten Konzepten beschäftigen.

Rasterbilder wie TIFF und JPEG spielen in der Dokumenterstellung eine entscheidende Rolle. Eingescannte Papierdokumente und Fotos aus Digitalkameras sind gängige Beispiele für Rasterbilddaten in Dokument-Workflows. In vielen Fällen sind Rasterbilddaten in modernen Arbeitsabläufen heute bereits geräteunabhängig, meist durch ein eingebettetes ICC-Farbprofil oder standardisierte Farbräume wie sRGB. Solche Bilder sind für den Einsatz in PDF/A bereits vorbereitet. Ältere Bilddaten sind dagegen in vielen Fällen geräteabhängig, wie Schwarzweiß- oder RGB-Scans ohne zugehöriges ICC-Profil.

XMP-Metadaten und Extension-Schemas

Extensible Metadata Platform (XMP) ist ein XML-basiertes Format, das auf Basis von RDF (Resource Description Framework) modelliert wurde, der Grundlage der semantischen Web-Initiative des W3C. Im Jahr 2012 wurde XMP als ISO 16684-1 standardisiert. PDF/A verlangt für die Speicherung von Informationen über ein Dokument die Verwendung von XMP Metadaten innerhalb der PDF-Datei. XMP bietet ein leistungsstarkes und flexibles Framework für die Speicherung von vor- und benutzerdefinierten Eigenschaften für Metadaten. (Siehe separates Whitepaper zu XMP).

Die XMP-Spezifikation umfasst mehr als ein Dutzend vordefinierte Schemas mit Hunderten sogenannter Properties für gängige Dokument- und Bildeigenschaften. Das am weitesten verbreitete vordefinierte XMP-Schema heißt Dublin Core. Es beinhaltet Eigenschaften wie Titel, Autor, Thema und Beschreibung.

XMP ist seinem Wesen nach erweiterbar, d.h. unternehmens- oder branchenspezifische Anforderungen an Metadaten können durch die Erstellung benutzerdefinierter Schemas erfüllt werden. PDF/A unterstützt dieses Konzept. Für eine automatisierte Abfrage verlangt PDF/A jedoch, dass zusätzlich eine maschinenlesbare Beschreibung der benutzerdefinierten Metadaten in das Dokument eingebettet ist. Dies wird durch eine »XMP-Extension-Schema-Beschreibung« erreicht: ein standardisierter Teil der XMP-Metadaten beschreibt den Aufbau der benutzerdefinierten Properties der XMP Metadaten.

Konformität zu Level A: Tagged PDF

PDF/A-1a, PDF/A-2a und PDF/A-3a erfordern Tagged PDF. Während einfaches PDF lediglich den sichtbaren Inhalt auf einer Seite wiedergibt, muss für Tagged PDF die logische Dokumentstruktur innerhalb der Struktur-Hierarchie gespeichert werden. Tagged PDF bietet vordefinierte Strukturelement-Typen für die üblichen Teile eines Dokuments wie Überschriften, Tabellen und Listen. Sogenannte markierte Inhaltselemente können als Äquivalent des getaggten Inhalts in Markup-Sprachen betrachtet werden. Sie beziehen sich auf Elemente in diesem Strukturbaum. Ähnlich wie HTML und XML unterstützt Tagged PDF Attribute für Strukturelemente. Zum Beispiel können Tabellenelemente Attribute für die Eigenschaften von Zeilen- oder Spaltenbreite einer Tabellenzelle tragen.

Die Konformität zu Level A erfordert auch, dass für den gesamten Text im Dokument Unicode-Semantik zur Verfügung steht und dass logische Wörter durch Leerzeichen getrennt sind.

PDF/UA-1 (Universal Accessibility, Barrierefreiheit oder Zugänglichkeit) ist ein neuer Standard, der viele Aspekte von Tagged PDF klärt. Er wurde im Jahr 2012 als ISO 14289 veröffentlicht. Obwohl es keine direkte Beziehung zwischen beiden Normen gibt, kann ein PDF/A-Dokument gleichzeitig konform zu einem PDF/UA-Dokument sein. Wir empfehlen sogar, die PDF/UA-Anforderungen einzuhalten, wenn Sie PDF/A mit Konformitätsstufe A erstellen möchten, um die Zugänglichkeit zu verbessern. Weitere Informationen hierzu können Sie unserem Whitepaper zu PDF/UA entnehmen.

Die folgende Einschränkung gilt für kombinierte PDF/A- und PDF/UA-Dokumente: Da PDF/UA das in PDF 1.4 und damit in PDF/A-1 fehlende Tabellenattribut Scope verlangt, können Tabellen mit Kopfzeilen nicht ordnungsgemäß getaggt werden. Bei der Verwendung von Tabellen empfehlen wir daher, statt PDF/A-1a die neueren Standards PDF/A-2a oder PDF/A-3a zu verwenden.

Konformität zu Level U: Unicode-Anforderungen

PDF/A-2 und PDF/A-3 bieten neben der Konformität zu Level A und B auch die Konformität zu Level U. Level U verlangt korrekte Unicode-Semantik für den gesamten Text im Dokument, jedoch kein Tagged PDF. Diese Anforderung rührt daher, dass PDF eine Vielzahl von Font- und Encoding-Techniken unterstützt, die nicht alle Unicode-fähig sind. Zum Beispiel unterstützt PDF die in den 1980er Jahren eingeführten PostScript-Type-1-Fonts, während das Unicode-Konsortium seine Arbeit erst im Jahr 1991 aufnahm. Für Level A und U müssen zusätzliche Unicode-Werte für alle Zeichen von solchen Fonts enthalten sein, die diese Angaben nicht schon intern enthalten. Aber nicht alle Unicode-Werte sind akzeptabel: Werte in der Private Use Area (PUA) sind nicht erlaubt, da sie keine allgemeingültige Interpretation (Semantik) haben.

Symbolfonts wie Fonts mit Logos oder Piktogrammen sind ein wichtiger Anwendungsbereich dieser PDF/A-Anforderung. Da standardisierte Unicode-Werte für benutzerdefinierte symbolische Glyphen nicht verfügbar sind, muss geeignete Unicode-Semantik in einem als »ActualText« markierten Inhaltsattribut für den Text übergeben werden. Obwohl dieses Attribut üblicherweise nur in Tagged PDF verwendet wird, kann es auch in Dokumenten ohne Tags hinterlegt werden - genau das verlangt die Konformität zu Level U. »ActualText« kann einer einzelnen Glyphe oder einer Folge von mehreren Glyphen zugeordnet werden. Es kann aus einer beliebigen Unicode-Zeichenfolge bestehen.

Als Beispiel nehmen wir Code 0x1A aus dem gängigen Font Wingdings. Dieses Zeichen zeigt das Bild einer Computer-Tastatur mit dem Glyphnamen keyboard und dem PUA-Unicode-Wert U+F037. Der Glyphname könnte für die Erzeugung eines passenden ActualText verwendet werden, so zum Beispiel »Symbol für Keyboard«. Anzumerken ist, dass das programmatische Erzeugen von ActualText eine Notlösung bleibt; von einem menschlichen Bearbeiter ausgewählte Texte sind maschinengeneriertem ActualText immer vorzuziehen.