PDF albo spełnia PDF/A-3, albo nie. Po co więc sprawdzać ten sam plik w dwóch walidatorach?

Bo w praktyce specyfikacja jest na tyle obszerna, że dwie poprawne implementacje mogą różnić się na granicznych przypadkach. W procesie audytowym pojedynczy “Pass” to światło żółte, nie zielone.

PDF/A nie jest jednym prostym algorytmem

PDF/A obejmuje kilka części ISO 19005: PDF/A-1, PDF/A-2, PDF/A-3 i PDF/A-4, wraz z poziomami b, a, u, e i f. Wszystko opiera się też na bazowej specyfikacji PDF, ISO 32000. Łącznie to tysiące stron tekstu normatywnego.

Typowe miejsca rozbieżności:

Przezroczystość w PDF/A-2/3: dozwolona w określonych warunkach, ale granice bywają różnie interpretowane.
Profile ICC: obowiązkowe, zalecane czy niewystarczające — rygor walidatorów się różni.
Metadane załączników w PDF/A-3: AFRelationship, referencje /AF i XMP muszą się zgadzać.
Font subsetting: fonty CID i częściowe subsety często tworzą przypadki brzegowe.

To nie zawsze są błędy. Tak wygląda niezależna implementacja złożonego standardu. Branże regulowane wolą więc mieć niezależne potwierdzenie.

Silnik referencyjny i druga opinia

veraPDF to implementacja referencyjna utrzymywana przez PDF Association. Jeśli veraPDF zwraca “Pass”, jest to najmocniejszy pojedynczy sygnał dla PDF/A.

Ale najmocniejszy pojedynczy sygnał to jeszcze nie dowód audytowy. Banki, archiwa medyczne, administracja i systemy długoterminowego przechowywania często wymagają drugiego silnika, bo:

Odbiorca może używać innego walidatora.
Błąd jednego silnika nie zostanie wykryty przez uruchomienie tego samego silnika ponownie.
Dwa niezależne potwierdzenia to znana praktyka compliance.

gPdf łączy veraPDF z własnym silnikiem w Rust + WebAssembly. To niezależna implementacja tej samej specyfikacji. Gdy oba przechodzą, wniosek jest dużo silniejszy; gdy się różnią, wiadomo, gdzie zacząć analizę.

Dwa raporty pod jednym adresem

Workflow jest bezpłatny na gpdf.com/validator/. Bez logowania: przesyłasz plik, veraPDF i edge engine gPdf działają równolegle, a wyniki pojawiają się obok siebie.

Typowe użycie:

Przed wysyłką PDF/A: prześlij plik, potwierdź dwa “Pass”, zachowaj JSON jako evidence QA.
Jeden silnik przechodzi, drugi nie: porównaj raporty; często chodzi o XMP, referencję /AF albo metadata załącznika.
Oba zawodzą: popraw generowanie u źródła.
Audyt partii archiwum: sprawdź próbki i dołącz wyniki do dokumentacji.

Plik nie jest zapisywany. Jest przetwarzany w pamięci na Cloudflare Workers i usuwany po wygenerowaniu raportu.

Ten sam wzorzec dla e-faktur

W Factur-X / ZUGFeRD trzeba sprawdzić nie tylko PDF/A-3, ale też osadzony XML CII zgodny z EN 16931. Validator gPdf używa do tego Mustang i pokazuje wynik obok raportu PDF/A.

To nie brak zaufania do narzędzia. To budowanie mocniejszego dowodu dzięki niezależnym implementacjom.

TL;DR

Pojedynczy “Pass” jest żółtym światłem. Dwa niezależne “Pass” są dużo mocniejsze. Użyj validator, pobierz dwa raporty i dołącz je do QA lub audytu. Jeśli PDF powstał przez gPdf API, validator jest publicznym potwierdzeniem zgodności.