PDF albo spełnia PDF/A-3, albo nie. Dlaczego więc ktokolwiek miałby uruchamiać dwa walidatory na tym samym pliku?

Krótka odpowiedź: ponieważ specyfikacja jest na tyle duża, że dwie poprawne implementacje mogą różnić się na brzegach, a proces audytowy traktuje pojedynczy wynik “Pass” jako żółte światło, nie zielone. Oto dłuższa wersja.

PDF/A to stos uzgodnionych reguł, nie jeden algorytm

PDF/A jest zdefiniowany w wielu częściach ISO 19005: PDF/A-1, PDF/A-2, PDF/A-3, PDF/A-4. Każda ma poziomy podrzędne, takie jak b, a, u, e i f, a wszystko buduje się na bazowej specyfikacji PDF, czyli ISO 32000. Łączna powierzchnia to kilka tysięcy stron tekstu normatywnego.

Kilka przykładów miejsc, w których zgodne implementacje historycznie potrafiły się różnić:

Przezroczystość w PDF/A-2/3: jest dozwolona pod określonymi warunkami; te warunki są zapisane proceduralnie i różne walidatory implementują sprawdzenie inaczej.
Osadzone profile kolorów: kiedy profil ICC jest “wymagany”, a kiedy tylko “zalecany”? Różne walidatory potrafiły nazwać ten sam plik raz “Pass”, raz “Fail” na tej osi.
Metadane osadzonych plików w PDF/A-3: AFRelationship, referencje /AF i osadzone XMP są dobrze opisane, ale rygor egzekwowania bywa różny.
Podzestawianie fontów: PDF/A wymaga, aby wszystkie fonty były osadzone z ich faktycznym kodowaniem. Przypadki brzegowe wokół fontów CID-keyed z częściowymi subsetami prowadziły do rozbieżności walidatorów.

To niekoniecznie są błędy. To naturalna konsekwencja złożonej specyfikacji implementowanej przez niezależne zespoły na podstawie tekstu normatywnego. Konserwatywne podejście, a zarazem podejście większości branż regulowanych, wymaga wielu niezależnych potwierdzeń.

Silnik referencyjny i druga opinia

veraPDF to implementacja referencyjna utrzymywana przez PDF Association, czyli organizację standaryzacyjną publikującą PDF/A. Jest open-source, audytowana przez branżowe grupy robocze, a jej zestaw reguł jest kanoniczną interpretacją tekstu ISO 19005. Jeśli veraPDF mówi “Pass”, to najmocniejszy sygnał, jaki można dostać od pojedynczego silnika.

Ale “najmocniejszy sygnał z pojedynczego silnika” to nie to samo co “dowód, który przejdzie audyt”. Audytorzy w instytucjach regulowanych, takich jak banki, archiwa dokumentacji medycznej czy archiwa administracji publicznej, często wymagają drugiego niezależnego potwierdzenia, ponieważ:

interpretacja jednej reguły przez veraPDF może różnić się od walidatora, którego odbiorca używa wewnętrznie, co prowadzi do późniejszego odrzucenia;
błąd w dowolnym pojedynczym silniku, nawet referencyjnym, nie zostanie wykryty przez uruchomienie tego samego silnika dwa razy;
zasada zakupowa “dwóch niezależnych potwierdzeń” jest szeroko stosowana w obszarach zgodności, a PDF/A dziedziczy to oczekiwanie ze swoich zastosowań archiwalnych.

Wybór drugiego silnika zależy od dostępności:

Adobe Acrobat Preflight jest płatny i zamkniętoźródłowy; dobrze sprawdza się jako silnik potwierdzający, ale ogranicza możliwość ponownej weryfikacji.
callas pdfaPilot jest płatny i de facto wybierany przez enterprise, ale również ogranicza niezależną ponowną weryfikację.
Drugi silnik open-source: istnieje kilka, zwykle mniej kompletnych niż veraPDF.

W gPdf zbudowaliśmy własny silnik w Rust + WebAssembly jako celową “niezależną reimplementację”: ta sama specyfikacja, te same reguły, kod pisany od zera przez inny zespół. Gdy oba silniki przepuszczają ten sam plik, wniosek jest znacznie mocniejszy niż w przypadku każdego z nich osobno. Gdy się różnią, masz konkretny błąd do zbadania: w jednym z silników albo w samym pliku.

Validator, który pokazuje oba raporty pod jednym adresem

Oba silniki hostujemy na gpdf.com/validator/: bezpłatnie, bez logowania. Plik przechodzi równolegle przez veraPDF oraz nasz silnik edge, a raporty wracają obok siebie. Typowe przypadki użycia:

Generujesz PDF/A i chcesz go wysłać: wrzuć plik do validatora, oba silniki przechodzą, dołącz raporty JSON jako dowód QA. Gotowe.
Jeden silnik nie przechodzi, drugi przechodzi: masz precyzyjny błąd; porównaj raporty i znajdź problematyczne pole. Często to subtelny szczegół, taki jak niespójny timestamp XMP albo brak referencji /AF w PDF/A-3.
Oba nie przechodzą: plik jest rzeczywiście uszkodzony; napraw go u źródła.
Audyt partii archiwum przychodzącego: wrzuć losowo próbkowane PDF, zapisz URL-e raportów i dołącz je do dokumentacji audytowej. “Zweryfikowaliśmy przez veraPDF i niezależny silnik” to mocniejsze twierdzenie niż “uruchomiliśmy checker naszego dostawcy”.

Plik, który przesyłasz, nie opuszcza żądania: silniki działają w pamięci na Cloudflare Workers, a plik jest usuwany po wyrenderowaniu raportu. Bez logowania, bez trwałego przechowywania, bez limitu kwoty.

Ten sam wzorzec, szerzej

To nie dotyczy tylko PDF/A. Wzorzec “dwóch niezależnych potwierdzeń” obejmuje też:

E-faktury Factur-X / ZUGFeRD: gpdf.com/validator/ uruchamia Mustang (mustangproject.org) dla osadzonego XML CII EN 16931, obok kontroli PDF/A opisanej wyżej. Artykuł Walidacja ZUGFeRD w Mustang: co przechodzi, co odpada omawia ten proces.
Certyfikaty TLS: każdy współczesny log CA jest sprawdzany krzyżowo przez wiele monitorów.
Powtarzalność buildów: dwa niezależne przebudowania z tego samego źródła powinny dać bajtowo identyczne wyniki.

Świat zgodności robi to od dekad. PDF/A po prostu nadgania.

TL;DR

Pojedynczy “Pass” jest żółtym światłem. Podwójny “Pass” jest zielonym. Oba silniki są bezpłatne w validator: wrzuć plik, pobierz dwa raporty i dołącz je do dowodów QA. Jeśli plik został wygenerowany przez gPdf, validator jest publicznym potwierdzeniem, że API dostarczyło deklarowaną zgodność.

Jeśli budujesz na API gPdf, dokumentacja API e-invoice (§5) pokazuje, jak bezpośrednio emitować PDF/A-3 Factur-X / ZUGFeRD. Validator potwierdza to potem z zewnątrz. Dwa silniki, jeden upload: to wzorzec audytowy.