Technischer Artikel

PDF/A-, PDF/X- und PDF/UA-Ausgabe in Delphi: HotPDF-Leitfaden

Ein Regierungsarchiv wies einmal eine komplette Einlieferung von 1.400 Rechnungen zurueck, die aus dem Delphi-Abrechnungssystem eines Kunden stammten. Jede Datei liess sich in allen getesteten Viewern fehlerfrei oeffnen; veraPDF lehnte sie alle aus demselben einzelnen Grund ab: Es fehlte ein OutputIntent. Genau darin liegt die Kernaussage standardsicherer PDF-Arbeit: Visuelle Korrektheit beweist nichts, weil PDF/A, PDF/X und PDF/UA Anforderungen an die interne Dateistruktur stellen, nicht an das, was am Bildschirm sichtbar ist. HotPDF, die native VCL-PDF-Bibliothek von losLab, verankert diese Anforderungen bereits in der Dokumenterzeugung, sodass Konformitaet vor der ersten Seite konfiguriert wird und nicht spaeter nachtraeglich angeflickt werden muss.

Drei ISO-Standards, drei unterschiedliche Zusagen

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.

Diese Zusagen ziehen in unterschiedliche Richtungen. Ein interaktives Formular ist fuer PDF/UA legitim, laesst sich aber nicht mit den Archivbeschraenkungen fuer dynamisches Verhalten kombinieren; ein reiner CMYK-Druckmaster ist genau die falsche Ausgabe fuer Screenreader-Anwender, die Farbe nie sehen. Entscheiden Sie pro Ausgabekanal, welcher Standard fuehrt, statt eine einzelne Datei erzwingen zu wollen, die alles gleichzeitig erfuellt.

PDF/A in HotPDF: Der OutputIntent entscheidet

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:

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;

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.

Behandeln Sie das ICC-Profil selbst als versioniertes Deployment-Artefakt, nicht als Datei, die irgendwann einmal auf den Build-Server kopiert wurde. Die Profilbytes werden in jedes erzeugte Dokument eingebettet. Ein beschaedigtes oder abgeschnittenes Profil vergiftet daher eine ganze Charge auf einmal, und der Fehler wird erst bei der Validierung sichtbar. Liefern Sie das Profil mit dem Installer aus, protokollieren Sie seine Pruefsumme im Laufprotokoll und laden Sie es wie oben ueber TFileStream, damit eine fehlende Datei bereits bei der Generierung laut fehlschlaegt und nicht erst am Archivtor.

PDF/X fuer den Druck: Trapped, CMYK und das Druckprofil

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.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;

Beachten Sie, dass die Komponentenanzahl fuer das CMYK-Druckprofil auf 4 gewechselt hat. X-1a schliesst ausserdem Live-Transparenz aus. Pruefen Sie daher jeden Zeichencode, der durchscheinende Ebenen uebereinanderlegt; was ein Viewer am Bildschirm zusammensetzt, ist genau das, was ein RIP nicht erraten soll. Wenn Ihre Druckerei Ihnen eine andere Charakterisierung gibt, tauschen Sie Profil und Identifier aus, aber behalten Sie dieselbe Struktur bei.

PDF/UA: Struktur wird erzeugt, nicht nachgeruestet

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:

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;

Das Fehlermuster, auf das Sie achten muessen, ist Inhalt, der ausserhalb eines BeginTaggedContent/EndTaggedContent-Paars gezeichnet wird: Er rendert normal und bleibt fuer Screenreader unsichtbar. Das ist die schlechteste Fehlerart, weil kein sehender Tester sie bemerkt. Wenn Ihre Vorlagen eigene Strukturrollennamen verwenden, ordnen Sie sie mit AddStructRoleMap('MyHead', 'H1') dem Standardsatz zu, damit konforme Reader sie interpretieren koennen. ISO 14289 verlangt ausserdem eine deklarierte Sprache; HotPDF setzt 'en' ein, wenn Lang leer ist. Das ist ein Sicherheitsnetz, keine Ausrede, die echte Dokumentsprache nicht zu setzen.

Verifikation: Dem Validator vertrauen, nicht dem Viewer

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.

Fuehren Sie den Validator auf echter Produktionsausgabe aus, nicht auf einem handgebauten Beispiel. Die relevanten Fehler kommen aus Daten: ein Kundenlogo, das als CMYK ankommt, obwohl der Intent RGB sagt; eine Vorlagenrevision, die eine nicht eingebettete Schrift einfuehrt; ein neuer Codepfad, der ungetaggten Text zeichnet. Bewahren Sie pro frueherem Vorfall eine bekannte Fehlerdatei als Regressionseingabe auf, dann bleibt das Compliance-Gate ehrlich. Fuer die Rendering-Seite solcher Pipelines siehe unseren Artikel ueber Reportausgabe, Schriften und Bilder mit HotPDF; fuer die Einbindung von Validatoren in einen Build siehe den Begleitartikel zur Automatisierung von PDF-Preflight-Pruefungen.

FAQ

Kann ein PDF gleichzeitig PDF/A- und PDF/X-konform sein?

Manchmal, aber der Zwang ist selten lohnend: Das Archivprofil verlangt geraeteunabhaengige Farbe und vollstaendige Metadaten, das Druckprofil charakterisiertes CMYK und Trapping-Deklarationen. Erzeugen Sie pro Kanal aus denselben Quelldaten eine passende Datei, statt eine Datei fuer beide Aufgaben zu verbiegen.

Warum lehnt veraPDF eine Datei ab, die in jedem Viewer korrekt geoeffnet wird?

Viewer sind absichtlich tolerant; Validatoren sind absichtlich streng. Fehlende OutputIntents, nicht eingebettete Schriften und fehlende XMP-Metadaten beeinflussen das Rendering nicht, deshalb meldet sie nur ein Strukturvalidator.

Sollten Rechnungen PDF/A Level A oder Level B verwenden?

Level B garantiert visuelle Reproduktion und ist fuer gescannte oder generierte Geschaeftsdokumente die haeufigste Archivanforderung. Level A fuegt die Anforderungen an getaggte Struktur hinzu, zieht also praktisch die PDF/UA-Arbeit in das Archivprofil hinein, und ist richtig, wenn Accessibility-Pflichten fuer das Archiv selbst gelten.

Weiterfuehrende Hinweise

Die Compliance-Eigenschaften, OutputIntents und Tagging-APIs aus diesem Artikel gehoeren zum Standardumfang von HotPDF Component fuer Delphi und C++Builder; die Produktseite fuehrt zur vollstaendigen Referenz fuer jeden hier verwendeten Aufruf.