Een PDF voldoet aan PDF/A-3 of niet. Waarom zou iemand hetzelfde bestand dan door twee validators halen?

Het korte antwoord: omdat de specificatie groot genoeg is dat twee correcte implementaties op de randen van elkaar kunnen verschillen, en een auditwaardige werkwijze een single-engine “Pass” behandelt als geel licht, niet als groen licht. Dit is de langere uitleg.

PDF/A is een stapel afgestemde regels, geen enkel algoritme

PDF/A is gedefinieerd in meerdere delen van ISO 19005: PDF/A-1, PDF/A-2, PDF/A-3 en PDF/A-4. Elk deel heeft subniveaus voor conformiteit, zoals b, a, u, e en f, en al die niveaus bouwen voort op de onderliggende PDF-specificatie ISO 32000. Samen is dat enkele duizenden pagina’s normatieve tekst.

Een paar voorbeelden waar conforme implementaties historisch uiteenliepen:

Transparantie in PDF/A-2/3: toegestaan onder specifieke voorwaarden; die voorwaarden zijn procedureel beschreven en verschillende validators implementeren de controle anders.
Ingesloten kleurprofielen: wanneer is een ICC-profiel “verplicht” en wanneer “aanbevolen”? Verschillende validators hebben hetzelfde bestand op deze as zowel “Pass” als “Fail” gegeven.
Metadata van ingesloten bestanden in PDF/A-3: AFRelationship, /AF-referenties en ingesloten XMP zijn goed gespecificeerd, maar de strengheid van handhaving varieert.
Font-subsetting: PDF/A vereist dat alle fonts zijn ingesloten met hun daadwerkelijke encoding. Randgevallen rond CID-keyed fonts met gedeeltelijke subsets hebben validatorverschillen veroorzaakt.

Dat zijn niet automatisch bugs. Het is een natuurlijk gevolg van een complexe specificatie die door onafhankelijke teams vanuit normatieve tekst wordt geïmplementeerd. De conservatieve positie, en de positie van veel gereguleerde sectoren, is om meerdere onafhankelijke bevestigingen te vragen.

Referentie-engine plus tweede mening

veraPDF is de referentie-implementatie die wordt onderhouden door de PDF Association, de standaardenorganisatie achter PDF/A. veraPDF is open source, wordt door werkgroepen uit de industrie beoordeeld en de regelset geldt als de canonieke interpretatie van ISO 19005. Als veraPDF “Pass” zegt, is dat het sterkste signaal dat u uit één engine kunt krijgen.

Maar het sterkste signaal uit één engine is niet hetzelfde als auditwaardig bewijs. Auditors bij gereguleerde instellingen, zoals banken, archieven voor medische dossiers en overheidsarchieven, vragen vaak een tweede onafhankelijke bevestiging, omdat:

de interpretatie van een regel door veraPDF kan verschillen van een andere validator die de gecontroleerde organisatie intern gebruikt, wat downstream tot afwijzing kan leiden;
een bug in één engine, zelfs de referentie-engine, niet zichtbaar wordt door dezelfde engine twee keer te draaien;
het inkoopprincipe “twee onafhankelijke bevestigingen” breed wordt toegepast in nalevingsdomeinen, en PDF/A die verwachting erft uit archiefscenario’s.

De keuze voor een tweede engine hangt af van wat beschikbaar is:

Adobe Acrobat Preflight is betaald en closed source. Dat werkt als bevestigingsengine, maar beperkt wie opnieuw kan verifiëren.
callas pdfaPilot is betaald en de de-facto enterprise-keuze, maar beperkt onafhankelijke herverificatie eveneens.
Een tweede open-source engine is mogelijk; er zijn er een paar, meestal minder compleet dan veraPDF.

Wat we bij gPdf hebben gedaan, is onze eigen engine in Rust + WebAssembly bouwen als bewuste onafhankelijke herimplementatie: dezelfde specificatie, dezelfde regels, vanaf nul geschreven door een ander team. Als beide engines hetzelfde bestand goedkeuren, is de conclusie veel sterker dan elk afzonderlijk resultaat. Als ze verschillen, hebt u een duidelijk probleem om te onderzoeken: in een van de engines of in het bestand.

De validator die beide op één URL zet

We hosten beide op gpdf.com/validator/: gratis, zonder login. Het bestand gaat parallel door veraPDF en onze edge-engine, waarna beide rapporten naast elkaar terugkomen. Typische toepassingen:

U genereert een PDF/A en wilt die uitleveren: upload het bestand, beide engines slagen, voeg de JSON-rapporten toe als QA-bewijs. Klaar.
Eén engine faalt en de andere slaagt: u hebt een precieze fout om te onderzoeken. Vergelijk de rapporten en zoek het veld dat afwijkt. Vaak is het iets subtiels, zoals een XMP-tijdstempel die niet klopt of een ontbrekende /AF-referentie in PDF/A-3.
Beide falen: het bestand is echt defect; corrigeer de bron.
Audit van een inkomende archiefbatch: valideer steekproefsgewijs PDF’s, log de rapport-URL’s en voeg ze toe aan het auditdossier. “We hebben geverifieerd met veraPDF en een onafhankelijke engine” is sterker dan “we hebben de checker van onze leverancier gedraaid”.

Het bestand dat u uploadt verlaat de request niet: de engines draaien in-memory op Cloudflare Workers en het bestand wordt weggegooid zodra het rapport is gerenderd. Geen login, geen opslag, geen quota.

Hetzelfde patroon, breder toegepast

Dit gaat niet alleen over PDF/A. Het patroon van “twee onafhankelijke bevestigingen” geldt ook voor:

Factur-X / ZUGFeRD e-facturen: gpdf.com/validator/ draait Mustang (mustangproject.org) voor de ingesloten EN 16931 CII XML, naast de PDF/A-controle hierboven. (ZUGFeRD valideren met Mustang: wat slaagt, wat faalt behandelt die werkwijze.)
TLS-certificaten: elke moderne CA-log wordt door meerdere monitors gekruist gecontroleerd.
Reproduceerbare builds: twee onafhankelijke rebuilds uit dezelfde bron zouden byte-identieke output moeten opleveren.

De wereld van gereguleerde processen doet dit al decennia. PDF/A haalt die praktijk nu in.

TL;DR

Een single-engine “Pass” is geel licht. Een dual-engine “Pass” is groen. Beide engines zijn gratis beschikbaar op validator: upload uw bestand, krijg twee rapporten en voeg ze toe aan uw QA-bewijs. Als gPdf het bestand heeft gegenereerd, is de validator het publieke bewijsstuk dat de API haar conformiteitsclaim heeft waargemaakt.

Als u op de gPdf API bouwt, laat de E-invoice API-referentie (§5) zien hoe u Factur-X / ZUGFeRD PDF/A-3 direct uitgeeft. De validator bevestigt het daarna extern. Twee engines, één upload: dat is het auditwaardige patroon.