Dieser deutsche Artikel behandelt PDF/A, PDF/X und PDF/UA-Ausgabe in Delphi: HotPDF-Leitfaden für Teams, die mit Delphi, C++Builder, Lazarus/FPC und losLab-Komponenten arbeiten
Drei ISO-Standards, drei verschiedene Versprechen
PDF/A (ISO 19005) verspricht, dass Dokumente auch nach Jahrzehnten noch auf dieselbe Weise gerendert werden, und erfordert daher vollständige Eigenständigkeit: Einbettung aller Schriftarten, geräteunabhängige Farben über OutputIntent, vollständige XMP-Metadaten und das Verbot aller umgebungsabhängigen Verhaltensweisen einschließlich Verschlüsselung und JavaScript. PDF/X (ISO 15930) verspricht einen blinden Austausch zwischen Designer und Druckerei, weshalb sich die Regeln auf Farbe und Geometrie konzentrieren: Charakterisierung der Druckbedingungen, obligatorischer -Schlüssel, Definition von Trim- und Bleed-Geometrie und Verbot von Live-Transparenz in der X-1a-Variante. PDF/UA (ISO 14289) verspricht, dass assistive Technologien das Dokument lesen können, und erfordert daher eine logische Struktur: vollständigen Tag-Baum, korrekte Lesereihenfolge, Deklaration der Dokumentsprache und Alternativtexte für Nicht-Text-Inhalte
PDF/A (ISO 19005) verspricht, dass eine Datei auch in Jahrzehnten noch identisch gerendert werden kann. Deshalb verlangt das Profil vollstaendige Selbststaendigkeit: alle Schriften eingebettet, jede Farbe ueber einen OutputIntent geraeteunabhaengig beschrieben, vollstaendige XMP-Metadaten und ein Verbot fuer alles, dessen Verhalten von der Umgebung abhaengt, einschliesslich Verschluesselung und JavaScript. PDF/X (ISO 15930) verspricht den blinden Austausch zwischen Gestaltung und Druckerei; seine Regeln drehen sich daher um Farbe und Geometrie: charakterisierte Druckbedingungen, ein verpflichtender /Trapped-Schluessel, definierte Trim- und Bleed-Geometrie und in der Variante X-1a keine Live-Transparenz. PDF/UA (ISO 14289) verspricht, dass assistive Technologien das Dokument lesen koennen. Daraus wird eine Anforderung an die logische Struktur: vollstaendiger Tag-Baum, korrekte Lesereihenfolge, deklarierte Dokumentsprache und Alternativtexte fuer nichttextliche Inhalte
PDF/A in HotPDF: OutputIntent ist der Schlüssel
Die Rückweisung der obigen Archivierung liegt letztendlich an einer fehlenden Struktur, und es ist genau die Struktur, die die meisten Generatoren vergessen, da kein sichtbarer Inhalt von ihr abhängt. ISO 19005 erfordert einen OutputIntent: Ein eingebettetes ICC-Profil, das den Gerätefarben eine eindeutige Bedeutung verleiht. HotPDF nimmt dieses Profil als explizite Eingabe an:
var
Pdf: THotPDF;
ICC: TFileStream;
begin
Pdf := THotPDF.Create(nil);
try
Pdf.FileName := 'invoice-archival.pdf';
Pdf.PDFACompliance := 'B'; // level B: visual fidelity
Pdf.Lang := 'en-US';
Pdf.StandardFontEmulation := False; // embed real fonts, no Base-14 emulation
ICC := TFileStream.Create('sRGB.icc', fmOpenRead);
try
Pdf.AddPDFAOutputIntent('sRGB IEC61966-2.1', '', ICC, 3, 'DeviceRGB');
finally
ICC.Free;
end;
Pdf.BeginDoc;
Pdf.CurrentPage.SetFont('Arial', [], 11);
Pdf.CurrentPage.TextOut(50, 760, 0, 'Archival invoice body');
Pdf.EndDoc;
finally
Pdf.Free;
end;
end;Die Archivablehnung aus dem Einstieg lief auf genau eine fehlende Struktur hinaus, und gerade diese Struktur vergessen Generatoren haeufig, weil nichts Sichtbares von ihr abhaengt. ISO 19005 verlangt einen OutputIntent: ein eingebettetes ICC-Profil, das Geraetefarben eindeutig beschreibt. HotPDF macht dieses Profil zu einer ausdruecklichen Eingabe:
Drei Konfigurationsdetails entscheiden ueber Bestehen oder Scheitern. StandardFontEmulation muss deaktiviert sein, denn emulierte Base-14-Schriften sind definitionsgemaess nicht eingebettet, und Einbettung ist unter ISO 19005 nicht verhandelbar. Verschluesselung muss aus bleiben; kombinieren Sie PDFACompliance nicht mit ActivateProtection, weil eine verschluesselte Archivdatei ein Widerspruch ist, den der Validator findet. Ausserdem muss die an AddPDFAOutputIntent uebergebene Komponentenanzahl zum Profil passen: 3 fuer ein RGB-Profil wie sRGB IEC61966-2.1. HotPDF verfolgt die Verwendung von DeviceRGB und DeviceCMYK waehrend der Generierung gegen den deklarierten Intent, sodass eine CMYK-Fuellung in einem Dokument mit RGB-Intent als Validierungsproblem sichtbar wird und nicht als stille Inkonsistenz weiterlaeuft
Druckorientiertes PDF/X: Trapped, CMYK und Druckprofile
Druckvorlagen kehren die Farbregeln um: Die Druckmaschine benötigt charakterisiertes CMYK, während der Standard darauf besteht, dass Sie deklarieren, ob Trapping bereits durchgeführt wurde. Der -Schlüssel ist obligatorisch, selbst wenn die ehrliche Antwort lautet, dass Sie es nicht wissen:
Pdf.PDFXCompliance := 'X-1a';
Pdf.Trapped := 'Unknown'; // mandatory key under ISO 15930
ICC := TFileStream.Create('FOGRA39.icc', fmOpenRead);
try
Pdf.AddPDFXOutputIntent('FOGRA39 (ISO 12647-2:2004)', '', ICC, 4, 'DeviceCMYK');
finally
ICC.Free;
end;
Pdf.BeginDoc;
// draw with CMYK-safe colors, no transparency, no encryption
Pdf.EndDoc;Druckmaster drehen die Farblogik um: Die Druckmaschine erwartet charakterisiertes CMYK, und der Standard verlangt eine Aussage, ob Trapping angewendet wurde. Der /Trapped-Schluessel ist auch dann Pflicht, wenn die ehrliche Antwort lautet, dass Sie es nicht wissen:
PDF/UA: Strukturen entstehen bei der Generierung und können nicht nachträglich hinzugefügt werden
Barrierefreiheit ist der Standard, den Teams am häufigsten erst ganz am Ende hinzuzufügen versuchen, und es ist der Standard, der bei einer nachträglichen Ergänzung am ehesten scheitert, da der Tag-Baum die logische Reihenfolge bei der Inhaltserstellung widerspiegeln muss. In HotPDF schaltet das Festlegen von die getaggte Ausgabe ein, und die Struktur-API bindet jeden Zeichenaufruf an seine semantische Rolle:
Pdf.PDFUACompliance := True; // auto-enables tagged PDF
Pdf.Lang := 'en-US'; // set explicitly; empty falls back to 'en'
Pdf.BeginDoc;
Root := Pdf.AddStructureElement(sstDocument, nil);
H1 := Pdf.EmitTaggedHeading(1, Root, 50, 700, 'Quarterly Report');
Para := Pdf.BeginTaggedContent('P', Root);
Pdf.CurrentPage.TextOut(50, 650, 0, 'Revenue grew in all regions.');
Pdf.EndTaggedContent;
Pdf.EndDoc;Accessibility ist der Standard, den Teams am haeufigsten am Ende noch anfuegen wollen, und genau hier scheitert Nachruesten am haertesten, weil der Tag-Baum die logische Reihenfolge widerspiegeln muss, in der Inhalte erzeugt wurden. In HotPDF aktiviert PDFUACompliance die Tagged-PDF-Ausgabe, und die Struktur-API verknuepft jeden Zeichenaufruf mit seiner semantischen Rolle:
Validierung: Vertrauen Sie dem Validierer, nicht dem Viewer
Die Lehre aus dem Rechnungs-Vorfall ist einfach: Integrieren Sie Werkzeuge zur Strukturprüfung statt zur Rendering-Prüfung in den Freigabepfad. Für PDF/A und PDF/UA ist veraPDF ein offener Validierer auf Referenzniveau und meldet Fehler nach ISO-Klauseln, sodass seine Ausgabe direkt den oben gezeigten Konfigurationen zugeordnet werden kann. Für PDF/X ist das Preflight-Profil von Adobe Acrobat weiterhin eine praktische Prüfung, da es bei Druckbedingungen sowohl um Syntax als auch um Farb-Intent geht. Intern gleicht HotPDF beim Speichern Funktionsflags mit der konfigurierten PDF-Version ab und stuft Inhalte, die die Version nicht ausdrücken kann (z. B. AES-256 unter PDF 1.7), stillschweigend herab. Gleichzeitig löst die Konformitätsprüfung in bei harten Konflikten (z. B. der Kombination von mit Verschlüsselung) direkt Ausnahmen aus. Beides ersetzt keinen externen Validierer; zusammen verhindern sie, dass unmögliche Konfigurationen den Validierer erreichen
Die Rechnungsgeschichte hat eine einfache Lehre: Bauen Sie Verifikation in den Releasepfad ein, und verwenden Sie Werkzeuge, die Struktur pruefen, nicht Rendering. Fuer PDF/A und PDF/UA ist veraPDF der offene Validator auf Referenzniveau und meldet Fehler nach ISO-Klausel, wodurch die Ausgabe direkt auf die oben gezeigte Konfiguration abbildbar ist. Fuer PDF/X bleiben die Preflight-Profile in Adobe Acrobat der praktische Test, weil Druckbedingungen ebenso sehr eine Frage der Farbabsicht wie der Syntax sind. Innerhalb des Generators gleicht HotPDF Feature-Flags beim Speichern mit der konfigurierten PDF-Version ab und stuft still herunter, was die Version nicht ausdruecken kann, etwa AES-256 unterhalb PDF 1.7. Harte Widersprueche loesen dagegen in EndDoc Fehler aus, etwa wenn PDFACompliance zusammen mit Verschluesselung gesetzt ist. Keiner dieser Checks ersetzt den externen Validator; zusammen verhindern sie, dass unmoegliche Konfigurationen ihn ueberhaupt erreichen
Versionieren Sie die gesamte Compliance-Konfiguration gemeinsam: HotPDF-Version, Vorlagenrevision, ICC-Profil-Pruefsumme und Validatorversion, die die Ausgabe freigegeben hat. Konformitaet driftet, sobald sich eines dieser Teile unter den anderen veraendert. Die schmerzhaftesten Audits sind diejenigen, in denen niemand mehr sagen kann, welche Kombination eine fuenf Jahre alte Archivdatei erzeugt hat. Ein einzelner Konfigurationsdatensatz pro Charge schliesst diese Frage dauerhaft
FAQ
Kann ein PDF gleichzeitig PDF/A- und PDF/X-konform sein?
Manchmal ja, aber es lohnt sich selten, zwischen den Einschränkungen hin- und herzupendeln: Die Archivierungskonfiguration erfordert geräteunabhängige Farben und vollständige Metadaten, während die Druckkonfiguration charakterisiertes CMYK und Trapping-Deklarationen erfordert. Es sollte für jeden Kanal separat aus denselben Quelldaten generiert werden, anstatt eine Datei zu zwingen, beide Seiten zu bedienen
Warum lehnt veraPDF Dateien ab, die alle Viewer problemlos öffnen können?
Viewer sind bewusst tolerant; Validierer sind bewusst streng. Fehlender OutputIntent, nicht eingebettete Schriftarten und fehlende XMP-Metadaten beeinträchtigen das Rendering nicht, weshalb nur Strukturvalidierer sie melden
Sollte eine Rechnung PDF/A Level A oder Level B verwenden?
Level B garantiert die visuelle Reproduktion und ist die Anforderung der meisten Archivierungsinstitutionen an gescannte oder generierte Geschäftsdokumente. Level A fügt Tagged-Structure-Anforderungen hinzu und zieht effektiv den PDF/UA-Aufwand mit ein; dies ist die richtige Wahl, wenn Barrierefreiheitsverpflichtungen für die Archivierung selbst gelten
Weiterführende Literatur
Die Konformitätseigenschaften, der Output-Intent und die Tagging-API in diesem Artikel gehören zur HotPDF-Komponente für Delphi und C++Builder; die Produktseite verlinkt auf die vollständige Referenz für jeden hier verwendeten Aufruf