Dieser deutsche Artikel behandelt PDF-Preflight-Prüfungen in Delphi mit HotPDF automatisieren für Teams, die mit Delphi, C++Builder, Lazarus/FPC und losLab-Komponenten arbeiten
Wenn Ihnen der Generator gehört, ist Vorbeugung besser als Prüfung
Klassisches Preflight setzt voraus, dass die Eingabe eine externe Datei unbekannter Qualität ist, und prüft sie im Nachhinein. Wenn das Dokument von Ihrer eigenen Anwendung generiert wird, ist diese Architektur umgekehrt: Jede Eigenschaft, die der Prüfer kontrolliert – wie Schrifteinbettung, Farbraumnutzung, Output-Intent, Metadaten –, wird von Ihrem Code Millisekunden zuvor bestimmt. Das billigste Preflight-Fehlschlagen ist eines, das bei der Generierung gar nicht erst auftreten kann
Klassisches Preflight nimmt eine fremde Datei unbekannter Qualität an und untersucht sie nachträglich. Wenn Ihre eigene Anwendung das Dokument erzeugt, ist diese Architektur verkehrt herum: Jede Eigenschaft, die der Inspektor prüfen würde, Schrifteinbettung, Farbraumnutzung, Output Intents, Metadaten, wurde Millisekunden vorher von Ihrem Code entschieden. Der günstigste Preflight-Fehler ist der, der bereits bei der Generierung unmöglich gemacht wird
Generierungsseite: Konformität als Konfiguration festlegen, nicht als Überprüfungselement
Die Standardeigenschaften von HotPDF bilden die Präventionsebene. Wenn oder vor gesetzt sind, führt die Komponente während der Generierung entsprechende Regeln aus, bettet Schriftarten ein, verfolgt die Verwendung von DeviceRGB und DeviceCMYK zur Deklaration von Ausgabeabsichten und lehnt vom Profil verbotene Funktionen ab. Nach dem Speichern zeichnen diese gleichnamigen Eigenschaften auch die ausgeführte Konfiguration auf, was genau das ist, was das Pipeline-Protokoll benötigt:
// After EndDoc: record the enforced profiles with the run metadata
if Pdf.PDFACompliance <> '' then
Log('Generated as PDF/A level ' + Pdf.PDFACompliance);
if Pdf.PDFXCompliance <> '' then
Log('Generated as PDF/X profile ' + Pdf.PDFXCompliance);Die Standard-Eigenschaften von HotPDF sind die Vorbeugungsschicht. Wenn PDFACompliance oder PDFXCompliance vor BeginDoc gesetzt wird, erzwingt die Komponente die jeweiligen Regeln während der Generierung: Schriften werden eingebettet, DeviceRGB- und DeviceCMYK-Nutzung gegen den deklarierten Output Intent verfolgt, und vom Profil verbotene Funktionen werden abgewiesen. Nach dem Speichern halten dieselben Eigenschaften fest, was erzwungen wurde, und genau das braucht Ihr Pipeline-Log:
Führen Sie vor teuren Prüfungen eine Triage der eingehenden Dateien durch
Viele Pipelines sind nicht rein generativer Art: Kunden laden PDFs hoch, Scanner liefern PDFs und Partner senden PDFs per E-Mail. Die Durchführung einer vollständigen Strukturvalidierung für jede eingehende Datei verschwendet Warteschlangenzeit für Eingaben, die überhaupt nicht geöffnet können. Die Direct File API von HotPDF kann die Dateistruktur lesen, ohne den vollständigen Objektbaum zu laden, und dient daher als kostengünstige erste Barriere:
function TriagePdf(Pdf: THotPDF; const FileName: string): Boolean;
var
Handle, Pages: Integer;
begin
Result := False;
Handle := Pdf.DAOpenFileReadOnly(FileName, '');
if Handle <= 0 then
Exit; // structurally unreadable: quarantine, do not validate
try
Pages := Pdf.DAGetPageCount(Handle);
Result := Pages > 0;
finally
Pdf.DACloseFile(Handle);
end;
end;Viele Pipelines sind nicht rein generativ: Kunden laden PDFs hoch, Scanner legen sie ab, Partner schicken sie per E-Mail. Eine vollständige Strukturvalidierung für jede eingehende Datei verschwendet Warteschlangenzeit auf Eingaben, die sich nicht einmal öffnen lassen. Die Direct File API von HotPDF liest Dateistrukturen, ohne den vollständigen Objektbaum zu laden, und eignet sich dadurch als günstiges erstes Gate:
Validierungsseite: veraPDF als Build-Schritt verwenden
Für PDF/A- und PDF/UA-Deklarationen ist veraPDF ein Validierer, der es wert ist, in die Pipeline integriert zu werden: Er kann ohne GUI ausgeführt werden, Stapeldateien verarbeiten, maschinenlesbares XML oder JSON ausgeben und jeden Fehler nach ISO-Klauselnummern melden, sodass beispielsweise Regelverletzungen nach ISO 19005-1 Klausel 6.2.2 direkt bekannten Generatoreinstellungen zugeordnet werden können. Der Aufruf aus Delphi ist eine normale Prozesssteuerung:
function RunVeraPdf(const PdfFile, ReportFile: string): Cardinal;
var
Cmd: string;
SI: TStartupInfo;
PI: TProcessInformation;
begin
Cmd := Format('cmd /c verapdf.bat --format xml "%s" > "%s"',
[PdfFile, ReportFile]);
FillChar(SI, SizeOf(SI), 0);
SI.cb := SizeOf(SI);
if not CreateProcess(nil, PChar(Cmd), nil, nil, False,
CREATE_NO_WINDOW, nil, nil, SI, PI) then
RaiseLastOSError;
try
WaitForSingleObject(PI.hProcess, 120000); // bound the wait per file
GetExitCodeProcess(PI.hProcess, Result);
finally
CloseHandle(PI.hThread);
CloseHandle(PI.hProcess);
end;
end;Für PDF/A- und PDF/UA-Behauptungen ist veraPDF der Validator, der in die Pipeline gehört: Er läuft headless, verarbeitet Stapel, gibt maschinenlesbares XML oder JSON aus und meldet jeden Fehler mit ISO-Klauselnummer. Ein Befund wie ein Regelverstoß gegen ISO 19005-1 Klausel 6.2.2 lässt sich dadurch direkt einer bekannten Generator-Einstellung zuordnen. Der Aufruf aus Delphi ist gewöhnliche Prozesssteuerung:
Das Timeout ist keine Dekoration. Eine beschädigte Datei kann jeden Parser in pathologisches Gebiet treiben, und ein unbegrenztes Warten in einem Queue-Worker reißt die ganze Warteschlange mit. Begrenzen Sie die Wartezeit, behandeln Sie einen Timeout als Fehler mit eigenem Code und stellen Sie die Eingabe für eine manuelle Prüfung unter Quarantäne. Parsen Sie das XML nach Regelkennungen, statt menschenlesbare Meldungen auszulesen; Regel-IDs bleiben über Validator-Releases stabil, Meldungstexte nicht, und stabile Codes sind das, wonach Supportmitarbeiter in alten Tickets suchen können
Batch-Verhalten verdient dieselbe Sorgfalt wie Einzeldokument-Korrektheit. Starten Sie den Validator als einen Prozess pro Datei statt als einen Prozess pro Stapel, damit eine pathologische Eingabe nur das Timeout dieser Datei kostet und nicht den gesamten Stapel; begrenzen Sie parallele Validator-Prozesse auf die Kernanzahl, weil XML-Berichtserzeugung CPU-gebunden ist; und setzen Sie beim Eingang eine Dateigrößengrenze, weil ein 2 GB großer Scan-Koloss die Warteschlange dominiert, egal wie gutmütig der Parser ist. Nichts davon ist Preflight-Logik, aber es ist der Unterschied zwischen einem Gate, das Monatsendvolumen übersteht, und einem Gate, das beim ersten Blockieren der Pipeline um 2 Uhr morgens deaktiviert wird
Was Berichte enthalten müssen, damit sie erhaltenswert sind
Preflight-Schranken bieten doppelten Nutzen: Erstens, wenn sie fehlerhafte Dateien blockieren, und zweitens Monate später, wenn jemand fragt, warum eine Datei akzeptiert wurde. Der zweite Zweck bestimmt das Berichtsformat. Für jede überprüfte Datei sollten aufbewahrt werden: Eingabe-Hash, Generator-Konformitätsflags und Version aus dem obigen Protokoll, Name und Version des Validierers, das zur Überprüfung verwendete Profil, das Pass- oder Fail-Ergebnis sowie die Liste der fehlgeschlagenen Regel-IDs und Seitenzahlen, die vom Validierer bereitgestellt wurden. Berichte sollten neben den von ihnen beschriebenen Artefakten gespeichert werden, nicht in einem separaten System, das vor dem Archiv ausgemustert wird
Ein Preflight-Gate erzeugt zweimal Wert: einmal, wenn es eine schlechte Datei blockiert, und erneut Monate später, wenn jemand fragt, warum eine Datei akzeptiert wurde. Der zweite Nutzen bestimmt das Berichtsformat. Halten Sie für jede geprüfte Datei fest: den Eingabe-Hash, die Compliance-Flags und Version des Generators aus der oben genannten Logzeile, Name und Version des Validators, das geprüfte Profil, ob das Ergebnis bestanden oder fehlgeschlagen ist, sowie die Liste fehlgeschlagener Regel-IDs mit Seitennummern, sofern der Validator sie liefert. Speichern Sie den Bericht neben dem Artefakt, das er beschreibt, nicht in einem separaten System, das vor dem Archiv außer Betrieb genommen wird
Akzeptierte Abweichungen brauchen ebenfalls Dokumentation. Wenn ein Kunde darauf besteht, eine Datei auszuliefern, die dem Gate missfällt, halten Sie fest, wer sie freigegeben hat, warum und bis wann, und hängen Sie diese Ausnahme an den Bericht, statt die Regel global zu schwächen. Eine Ausnahme mit Verantwortlichem und Ablaufdatum ist ein verwalteter Sonderfall; eine auskommentierte Prüfung ist ein zukünftiger Vorfall
FAQ
Kann HotPDF jedes beliebige Drittanbieter-PDF programmgesteuert validieren?
Nein. Der Preflight-Bericht im Produkt ist eine GUI-Präsentationsfunktion, keine aufrufbare API. Der unterstützte Automatisierungsmodus besteht darin, Einschränkungen auf der Generierungsseite über Konformitätseigenschaften durchzusetzen und eine formelle Entscheidung mit einem externen Validierer wie veraPDF zu treffen
Reicht veraPDF für Druckaufträge aus?
Es deckt PDF/A und PDF/UA ab. Für PDF/X-Druckvorlagen sollten Sie Acrobat Preflight mit dem von der Druckerei angegebenen Profil ausführen und bestätigen, dass der Output-Intent mit der erwarteten Druckcharakterisierung übereinstimmt
Was sollte den Build fehlschlagen lassen: Nur Fehler oder zählen auch Warnungen?
Sie sollten Regelverletzungen des Profils, dessen Konformität Sie beanspruchen, als Sperre nutzen und Warnungen zur Trendüberwachung protokollieren. Jede Warnung zu einem blockierenden Element zu erheben, erzieht die Leute dazu, Sperren zu umgehen, was schlimmer ist als gar keine Sperre
Produktreferenz
Die in dieser Pipeline verwendeten Konformitätseigenschaften und Direct File APIs gehören zur HotPDF-Komponente für Delphi und C++Builder; ihre Dokumentation beschreibt jeden in diesem Artikel gezeigten Aufruf vollständig