PDF/A – ein Blick auf die technische Seite

Die wichtigsten Ziele und Regeln · Praktische Fragen

Das Langzeitarchivformat PDF/A ist ein relativ neuer Standard, der für viele Branchen und Anwender neue Möglichkeiten eröffnet, wenn es um das Thema geht, digitale Dokumente auch in Jahren noch lesen und verarbeiten zu können. In diesem Beitrag stellen wir einige technische Aspekte von PDF/A in den Mittelpunkt.

Die Themen in diesem Beitrag:

PDF/A – die wichtigsten Ziele und Regeln

PDF/A: Praktische Fragen

Der Standard: ISO 19005-1 (PDF/A-1)

Bei PDF/A-1 handelt es sich – wie der Name schon sagt – um den ersten Teil der ISO-Normenreihe zu PDF/A. Der internationale Standard wurde vom ISO Technical Committee TC 171, SC 2, WG 5 erarbeitet und am 1. Oktober 2005 veröffentlicht. Durch das Technical Corrigendum (2007)wurde ISO 19005-1 nochmals nachgebessert. PDF/A-1a basiert auf PDF 1.4 (das ist die PDF-Version, die mit Acrobat 5 eingeführt wurde)

Bei PDF/A handelt es sich nicht um ein ”neu erfundenes“ PDF, PDF/A ist vielmehr ein ganz normales PDF, das über Mindestanforderungen, Gebote und Verbote maßgeschneidert ist. Herkömmliches PDF muss nicht immer eindeutig sein, PDF/A hat im Gegensatz dazu das erklärte Ziel, dass die Darstellung heute und in Zukunft eindeutig ist.

PDF ist eine Erfindung von Adobe Systems, der Hersteller hat das Format für Standardisierung ausdrücklich frei gegeben.

PDF/A – die wichtigsten Ziele und Regeln

Was will PDF/A? PDF/A will Dateien erreichen, deren Inhalte statisch sind, sodass sie visuell exakt reproduzierbar sind, heute und in vielen Jahren. Die Dateien für die Langzeitarchivierung sollen unabhängig von bestimmten Geräten oder Betriebssystemen funktionieren. Die zukünftige Nutzbarkeit von PDF/A-Dateien muss auch unabhängig von bestimmten Herstellern garantiert sein (auch von Adobe). PDF/A ist komplett, das heißt, diese PDF-Dateien sind in sich vollständig, sie verwenden keine externen Bezüge, oder nicht-PDF-Daten. Die PDF/A-1 Norm beruht auf der PDF-Spezifikation 1.4, bewegt sich also innerhalb der technischen Grenzen der Funktionen, die in Acrobat 5 möglich waren.

Um die oben genannten Ziele zu erreichen, sind bei der Erzeugung von PDF/A eine Reihe von Regeln einzuhalten. So muss man bei der PDF/A-Generierung immer alle Schriften einbetten und die Farben müssen eindeutig angegeben werden. Formulare, Kommentare und Notizen sind nur beschränkt zulässig. Kompressionen sind grundsätzlich erlaubt, bis auf LZW oder JPEG2000. Sowohl transparente Objekte als auch Ebenen (Optional Content Groups) sind nicht erlaubt. PDF/A verwendet Regeln für Metadaten auf der Grundlage von XMP (Extensible Metadata Platform). Schließlich muss sich eine PDF/A-Datei als solche ausweisen.

PDF/A-1-Stufen: a und b (accessible & basic)

PDF/A-1 gibt es in zwei Ausrichtungen: PDF/A-1a und PDF/A-1b. Diese beiden Konformitätslevel berücksichtigen, dass unterschiedliche Anwenderkreise verschiedene Anforderungen an ein Dateiformat für die Langzeitarchivierung haben und dass sich das Ausgangsmaterial zum Teil stark unterscheidet.

  • Das einfacher zu erzeugende PDF/A-1b (basic) garantiert die visuelle Reproduzierbarkeit der Inhalte.
  • PDF/A-1a (accessible/zugänglich) erfordert in der Regel einen höheren Aufwand bei der Erstellung, bietet dafür jedoch den erweiterten Zugriff auf Inhalte (vor allem Text). Die Struktur von PDF/A-1a hat den Vorteil, dass die Wiederverwendung von Text – etwa per Export – in der Regel ohne Probleme (verschobene Absätze, zerhackte Wörter) zu bewerkstelligen ist. Auch Suchfunktionen profitieren von PDF/A-1a. (Um Missverständnisse zu vermeiden: auch PDF/A-1b-Dateien bieten durchsuchbaren Text.) Schließlich bekommen Anwender, die barrierefreie PDF-Dokumente erstellen wollen, mit PDF/A-1a ein Format an die Hand, das bestens für diese Anforderung gerüstet ist.

Was muss PDF/A mitbringen, um PDF/A-1a zu sein?

Damit PDF/A-1a die oben genannten Vorteile bieten kann, müssen diese PDF-Dateien zusätzliche Voraussetzungen erfüllen:

  • Als Grundlage für die exakte Durchsuchbarkeit muss der Text nach Unicode abbildbar sein. Unicode ist ein System, das erlaubt, Zeichen (Buchstaben, Ziffern, Symbole in internationalen und auch historischen Schriftsystemen) ganz genau per Code zuzuordnen.
  • Die Dokumentstruktur wird in PDF-1a durch tagged PDF erzielt.
    • Tagged PDF hilft dabei, barrierefreie Dokumente zu erzeugen, die durch Software vorgelesen werden können, zum Beispiel mit der Vorlesefunktion von Adobe Reader oder Acrobat.
    • Die Dokumentstruktur ermöglicht auch eine bessere Konvertierung der PDF-Dateien in andere Formate.
    • Ein weiterer Vorteil ist das Umfließen von Text (Neuformatierung von Seiten zur Anpassung an Bildschirm/Fenster). So lassen sich PDF-Dateien auch gut auf kleinen Geräten (Handheld, Mobiltelefon) lesen.
    • Schließlich ist die Erhaltung der Semantik auch für die Langzeitarchivierung wichtig.

Nach PDF/A-1 kommt PDF/A-2. Was bedeutet das in der Praxis?

Für für Ende 2008 beziehungsweise Anfang 2009 wird PDF/A-2 erwartet. Diese PDF/A-Norm erlaubt Transparenz und neuere PDF-Features, da es auf PDF 1.7 basiert (PDF/A-1 basiert auf PDF 1.4). Dazu zählen: JPEG2000, PDF-Ebenen (Optional Content Groups), UserUnits (Seitenskalierung), seit PDF 1.4 neu eingeführte Kommentar-Typen sowie Unicode-Pfade für Hyperlinks.

PDF/A-2 legt strengere Maßstäbe an Glyphen in eingebetteten Schriften an. Mit PDF/A-2 ist die Verwendung von .notdef-Glyphen unzulässig und die so genannten ‘leeren’ Glyphen sind nur für ‘white space’ erlaubt.

PDF/A-2 wird es in drei Konformitätsstufen geben:

  • a: wie bisher (a = accessible)
  • b: wie bisher (b = basic)
  • u: Neu, der Text kann nach Unicode abgebildet werden (u = Unicode)

Heute in PDF/A-1 abgelegte Dokumente bleiben auch nach der Einführung von PDF/A-2 gültig. Kommende PDF/A-Versionen werden immer rückwärtskompatibel sein.

PDF/A: Praktische Fragen

Einige Bereiche von PDF müssen bei PDF/A bestimmten Voraussetzungen entsprechen, damit sie eindeutig und damit zukunftssicher sind.

Thema Text

Text wird über Schriften realisiert. PDF/A stellt einige Anforderungen an Schriften, um eine exakte Wiedergabe von Inhalt jetzt und über lange Zeiträume zu gewährleisten.

Zuerst muss sichergestellt sein, dass alle verwendeten Schriften in die PDF-Datei eingebettet sind. Es müssen alle verwendeten Glyphen im PDF selbst hinterlegt werden – eine bloße Referenzierung (”hier Font xyz hinzuladen”) reicht bei PDF/A nicht aus. Eine weitere Anforderung ist, dass die Zeichensatz-Kodierung in Ordnung sein muss, damit die beabsichtigte Darstellung von Text auch ausgeführt werden kann. Auch wenn die Laufweite in sich nicht stimmig ist, kann die PDF-Datei keine exakte Wiedergabe liefern, sie ist also nicht PDF/A-fähig.

Probleme mit Glyphen

Bei Glyphen handelt es sich um die grafische Form von Zeichen (Buchstaben, Ziffern, Symbole). Wohl jeder hat schon Beispiele gesehen, wenn es mit der Darstellung von Schriftzeichen Probleme gibt. So sind komplett fehlende Zeichen die Folge von einem fehlerhaften Subsetting bei TrueType-Fonts – es ist nur ein “leerer” Glyph zu sehen.

 

Das fehlende ”ä“ wird durch ein fehlerhaftes Subsetting bei TrueType verursacht.

Das fehlende ”ä“ wird durch ein fehlerhaftes Subsetting bei TrueType verursacht.

Bei Type-1-Schriften hingegen findet ein Rückgriff auf ein .notdef Glyph (Ersatzzeichen) statt. Dabei handelt es sich oftmals ein Kästchen mit Xwie die Abbildung zeigt.

 

X statt Lücke: Type-1-Fonts greifen auf ein Ersatzzeichen für undefinierte Zeichen zurück.

X statt Lücke: Type-1-Fonts greifen auf ein Ersatzzeichen für undefinierte Zeichen zurück.

Eine inadäquate Mehrfachverwendung von Subset Fonts ist in der Regel ein Effekt, der durch Probleme bei der PDF-Generierung entstehen kann.

Auch Bugs im Viewer beziehungsweise Drucker können zu falschen Darstellungen führen: Ein falsches Caching einer Fontinstanz kann negative Folgen haben.

  • Bei unterschiedlichen Subsets desselben Font wird das erste Subset für alle weiteren genutzt.
  • Gleiche Fonts werden mit unterschiedlichem Encoding verwendet.
  • Unterschiedliche Subsets haben den gleichen “eindeutigen” Namen und den gleichen Basefont.
  • Gegenmittel: jeder Font in einem PDF hat einen eindeutigen Namen (auch für den Basefont).

Encoding – richtig falsch?

Es können Probleme vor beziehungsweise bei der Erstellung des PDFs auftauchen. Ein PDF/A kann formal korrekt, aber mit falschen Glpyhen ausgestattet sein. Hier hilft nur eine genaue Sichtkontrolle. Da Erstellungsprobleme Auswirkungen auch auf das Unicode-Mapping haben, fällt dies in der Sichtkontrolle des extrahierten Texts auf.

Die Text/Schriftverwendung ist in PDF/A eindeutig genug spezifiziert, sie kann in sich nicht falsch sein.

Wenn Viewer oder Drucker keine vollständige Unterstützung für Encodings bieten, kann dies zu Problemen in Bezug auf PDF/A führen.

Glyphbreiten: PDF versus Font

Bezüglich der Glyphbreitenangaben kann es zu Unstimmigkeiten kommen. Damit dies nicht geschieht, müssen die Angaben im PDF Font Dictionary den Angaben im eingebetteten Font entsprechen. In der Realität sind geringe Abweichungen durch unterschiedliche Bemaßung unvermeidbar (und zu tolerieren). Angaben im Width-Array im PDF sind üblicherweise ganzzahlig, müssen es aber nicht sein.

PDF-Erstellung: Zu Problemen kommt es, wenn die Laufweitenangaben auf einem anderen als dem tatsächlich eingebetteten Font basieren. Daher ist übrigens auch die nachträgliche Einbettung von Fonts riskant.

Anzeige/Ausgabe von PDF/A: Problematisch bei der Anzeige oder Ausgabe von PDF ist es, wenn der Viewer beziehungsweise Drucker nicht den eingebetteten Font verwendet, sondern eine Ersatzschrift.

 

Stimmen die Laufweitenangaben nicht, so lässt sich Text nicht ordentlich darstellen.

Stimmen die Laufweitenangaben nicht, so lässt sich Text nicht ordentlich darstellen.

Eindeutige Farbe

Farbverfälschungen können zu einer völlig anderen (Bild-) aussage führen, als ursprünglich geplant. Daher ist es für PDF/A wichtig, dass Farbe verlässlich wiedergegeben werden kann. Für diese Aufgabe sind Farbprofile geeignet, die als eine Art Beipackzettel Auskunft darüber geben, wie Farben zu behandeln sind.

 

Farben sind eine emotionale Sache – die korrekte Farbdarstellung kann für die Botschaft eines Bildes entscheidend sein.

Farben sind eine emotionale Sache – die korrekte Farbdarstellung kann für die Botschaft eines Bildes entscheidend sein.

Die genaue Farbdarstellung über Farbmanagement ist nicht nur für Fotografien in PDF/A wichtig, sondern auch für Schrift oder Grafik, man denke nur an die CI eines Unternehmens.

PDF/A hält mehrere Optionen bereit, wie eine exakte Farbwiedergabe ermöglicht werden kann.

  • PDF/A kann Quellprofile nutzen (oder CalGray/CalRGB/Lab) oder ein Zielprofil im OutputIntent (auch Ausgabebedingung genannt). Sind alle Farbräume mit Quellprofil (oder über CalGray/CalRGB/Lab) qualifiziert, dann ist ein OutputIntent nicht erforderlich.
  • Geräteabhängige Graustufe (DeviceGray) wird mittels Zielprofil – entweder Graustufen, RGB oder CMYK – “abgedeckt”.
  • Kommen sowohl geräteabhängiges RGB (DeviceRGB) als auch geräteabhängiges CMYK (DeviceCMYK) im Dokument vor, kann nur eines von beiden über den OutputIntent abgedeckt werden.

Bei der Verwendung von CMYK ist zu bedenken, dass die ICC-Profile recht groß sein können, vor allem ‘prtr’-Profile (Ausgabeprofile für Drucker/Druckmaschine) können durchaus einen Speicherbedarf von 500 kB bis 2 MB zusätzlich bedeuten.

Achtung: Bei Separation/DeviceN-Farbräume: Der so genannte alternate space unterliegt den gleichen Anforderungen wie die Prozessfarbräume.

Kommentare/Annotations

Es sind einige Kommentare erlaubt, es gibt aber auch Kommentartypen, die verboten sind. Unzulässig sind Kommentare in Form von Movie, Audio, Dateianhang (hier werden zusätzliche Programme für die Darstellung benötigt, die in Zukunft möglicherweise nicht im Zugriff sind). Außerdem ist alles was nach PDF 1.4 eingeführt wurde nicht PDF/A-kompatibel, wie etwa Polygon, PolyLine, Caret, Screen, Watermark und 3D. Erlaubt, aber nicht immer praktikabel ist die Highlight-Markup-Annotation, denn diese verwendet meistens Transparenz – was wiederum in PDF/A-1 nicht erlaubt ist.

Aus dem Bereich Hyperlinks ist der spezielle Annotation-Typ “Link” mit oder ohne Appearance erlaubt. Grundsätzlich sind URL-Links oder andere Links zulässig, sie müssen von einem PDF/A-Viewer ‘irgendwie’ dargestellt werden, aber nicht unbedingt ausgeführt werden. Ob ein Link zu einem gültigen Ziel führt ist für die Erfüllung des Standards nicht von Bedeutung.

Formularfelder: mit Einschränkungen erlaubt

Grundsätzlich sind alle Formularfelder erlaubt, sie dürfen bestimmte Aktionen, aber niemals JavaScript ausführen. Es darf nur ein Erscheinungsbild (Appearance) vorkommen, so dass zum Beispiel keine Rollover-Effekte möglich sind. PDF/A-taugliche Fomularelemente dürfen nicht verborgen sein, das heißt, sie müssen auf sichtbar und auf druckend gesetzt sein.

Möchte man ein Formular mit kritischen Funktionen dennoch in PDF/A wandeln, so kann man Formularfelder “flatten”. Eine Reduzierung/Verflachung stellt auf jeden Fall die gewünschte PDF/A-1-Konformität her, man verliert aber die Zuordnung von Inhalten zu den Formularfeldern. Als Alternative bleibt die Möglichkeit, problematischen Komponenten im Vorfeld mit anderen Mitteln beizukommen:

  • bestimmte Aktionen sowie stets JavaScript entfernen
  • alle Appearances außer der Default Appearence entfernen (sich auf eine Darstellung festlegen)
  • unsichtbare Felder entfernen
  • das Formular einheitlich auf sichtbar und druckend setzen

Aktionen und JavaScript

Zu den explizit verbotenen Aktionen zählen:

  • Launch (Programm Starten), Sound (Tondatei abspielen), Movie (Filmdatei abspielen), ResetForm (Formular zurücksetzen), ImportData (Datenimport) und JavaScript.
  • set-state (seit einigen PDF-Versionen nicht mehr gebräuchlich) und no-op (wurde mit PDF 1.2 beschrieben, doch nicht implementiert).
  • Named actions (benannte Aktionen) außer NextPage (nächste Seite), PrevPage (vorherige Seite), FirstPage (erste Seite) und LastPage (letzte Seite).

Immer verboten sind JavaScript und Additional Actions (AA).

Implizit verbotene Aktionen (weil sie nach PDF 1.4 eingeführt wurden) sind:

  • SetOCGState (Status für Optional Content Groups bzw. PDF-Layer setzen), Rendition (kontrolliert das Abspielen von Multimedia-Inhalten), Trans (Seitenübergang), GoTo3DView (Wechseln zur 3D-Darstellung).

Eine weitere implizit verbotene Aktionen ist:

  • Hide (Kommentare Verbergen, die Ausführung würde das PDF/A ungültig machen)

Es gibt aber auch erlaubte Aktionen:

  • GoTo (Go to a destination = gehe zum Ziel), GoToR (Go to remote, go to a destination in another document = gehe zum Ziel in einem anderen Dokument), GoToE (Go-to embedded, Go to a destination in an embedded file = gehe zum Ziel in einer eingebetteten Datei), Thread (Gehe zu einem bestimmten Artikel-Strang), URI (Uniform Resource Identifier = einheitlicher Bezeichner für Ressourcen), SubmitForm (Formular einreichen)
  • und wie bereits oben benannt: die named actions NextPage, PrevPage, FirstPage und LastPage

Metadaten (auf Dokumentebene)

Die einzige zwingend erforderliche Angabe in den Metadaten ist die PDF/A-1-Eigenschaft plus Konformitätslevel (PDF/A-1a oder PDF/A-1b) in “Metadata” (XMP). Sämtliche weiteren Metadaten sind optional.

Bei Verwendung nicht in der XMP-Spezifikation vordefinierter Schemata muss das betreffende Schema mit im XMP eingebettet werden.

Falls eine herkömmliche “Dokument-Info” vorhanden ist muss diese in den XMP-Metadaten gespiegelt sein, damit die PDF/A-Konformität gewahrt wird. Dies gilt für: Title (Titel), Author (Verfasser), Subject (Thema), Keywords (Stichwörter), Creator (Anwendung), Producer (PDF erstellt mit…), CreationDate (Erstellt am) sowie ModDate (Geändert am).

Die Bereiche Namespace und Metadaten-Spiegelung sind im Standard unklar formuliert. Die verbesserte Erklärung ist im Technical Corrigendum zu finden (vgl. TechNotes 0001 und 0003).

Olaf Drümmer, callas software/aoe

About PDF/A Competence Center

The first of the PDF Association's Competence Centers.

Hinterlasse eine Antwort