Un PDF è conforme a PDF/A-3 oppure non lo è. Allora perché qualcuno dovrebbe eseguire due validatori sullo stesso file?

Risposta breve: perché la specifica è abbastanza ampia perché due implementazioni corrette possano divergere sui casi limite, e un processo adatto a un audit tratta un “Pass” da un solo motore come semaforo giallo, non verde. Ecco la versione completa.

PDF/A è una pila di regole negoziate, non un singolo algoritmo

PDF/A è definito in più parti ISO 19005 (PDF/A-1, PDF/A-2, PDF/A-3, PDF/A-4), ciascuna con sotto-livelli di conformità (b, a, u, e, f), e ognuna costruita sopra la specifica PDF sottostante (ISO 32000). La superficie combinata è di diverse migliaia di pagine di testo normativo.

Alcuni esempi di punti in cui implementazioni conformi hanno storicamente divergenze:

Trasparenza in PDF/A-2/3: consentita a condizioni specifiche; le condizioni sono scritte in modo procedurale e validatori diversi implementano il controllo in modo diverso.
Profili colore incorporati: quando un profilo ICC è “richiesto” e quando è solo “raccomandato”? Validatori diversi hanno chiamato lo stesso file “Pass” e “Fail” su questo asse.
Metadati dei file incorporati in PDF/A-3: AFRelationship, riferimenti /AF, XMP incorporato; le regole sono definite, ma cambia il rigore con cui vengono applicate.
Sottoinsiemi dei font: PDF/A richiede che tutti i font siano incorporati con la loro codifica reale. Casi limite su font CID-keyed con subset parziali hanno causato disaccordi tra validatori.

Non sono necessariamente bug. Sono la conseguenza naturale di una specifica complessa implementata da team indipendenti a partire da un testo normativo. La posizione prudente, e quella adottata da molti settori regolati, è richiedere più conferme indipendenti.

Il motore di riferimento e la seconda opinione

veraPDF è l’implementazione di riferimento mantenuta dalla PDF Association, l’organismo di standardizzazione che pubblica PDF/A. È open source, verificata da gruppi di lavoro del settore, e il suo insieme di regole è l’interpretazione canonica del testo ISO 19005. Se veraPDF dice “Pass”, è il segnale più forte ottenibile da un singolo motore.

Ma “il segnale più forte da un solo motore” non equivale a “evidenza sufficiente per un audit”. Auditor di istituzioni regolamentate, banche, archivi sanitari e uffici pubblici richiedono spesso una seconda conferma indipendente perché:

L’interpretazione di una regola da parte di veraPDF potrebbe differire da quella di un altro validatore usato internamente dall’organizzazione verificata, causando un rifiuto a valle.
Un bug in un singolo motore, anche quello di riferimento, non può essere rilevato eseguendo due volte lo stesso motore.
Il principio di procurement “due conferme indipendenti” è applicato in molti domini di conformità; PDF/A eredita questa aspettativa dai casi d’uso archivistici.

La scelta del secondo motore dipende da ciò che è disponibile:

Adobe Acrobat Preflight è a pagamento e closed source: va bene come motore di conferma, ma limita chi può verificare di nuovo.
callas pdfaPilot è a pagamento ed è la scelta enterprise de facto, ma limita comunque la riverifica indipendente.
Un secondo motore open source: ne esistono alcuni, spesso meno completi di veraPDF.

In gPdf abbiamo costruito un nostro motore in Rust + WebAssembly come “reimplementazione indipendente” intenzionale: stessa specifica, stesse regole, scritto da zero da un team diverso. Quando entrambi i motori passano lo stesso file, la conclusione è molto più forte di quella ottenibile da uno solo. Quando divergono, avete un problema chiaro da indagare: in uno dei motori, oppure nel file.

Il validatore che li mette entrambi su un solo URL

Li ospitiamo entrambi su gpdf.com/validator/: gratuito, senza login, esegue il file in parallelo con veraPDF e con il nostro motore edge, poi restituisce i due report affiancati. Casi d’uso:

Generate un PDF/A e volete consegnarlo: caricate il file nel validatore, entrambi passano, allegate i report JSON come evidenza QA. Fine.
Un motore fallisce e l’altro passa: avete un difetto preciso da analizzare; confrontate i report e trovate il campo coinvolto. Spesso è qualcosa di sottile, come un timestamp XMP non allineato o un riferimento /AF mancante in un PDF/A-3.
Entrambi falliscono: il file è davvero rotto; correggete alla fonte.
Audit di un lotto in archiviazione: caricate un campione casuale di PDF, registrate gli URL dei report e allegateli al work paper di audit. “Abbiamo verificato con veraPDF e con un motore indipendente” è un’affermazione più forte di “abbiamo eseguito il controllore del nostro fornitore”.

Il file caricato non lascia la richiesta: i motori girano in memoria su Cloudflare Workers e il file viene scartato dopo il rendering del report. Nessun login, nessuna persistenza, nessuna quota.

Lo stesso schema, generalizzato

Questo non riguarda solo PDF/A. Il modello delle “due conferme indipendenti” si estende a:

Fatture elettroniche Factur-X / ZUGFeRD: gpdf.com/validator/ esegue Mustang (mustangproject.org) sull’XML CII EN 16931 incorporato, accanto al controllo PDF/A descritto sopra. (Validating ZUGFeRD with Mustang — what passes, what fails copre questo processo.)
Certificati TLS: ogni log CA moderno viene incrociato da più monitor.
Riproducibilità delle build: due rebuild indipendenti dalla stessa sorgente dovrebbero produrre output identici byte per byte.

Il mondo della conformità lo fa da decenni. PDF/A sta solo recuperando.

TL;DR

Un “Pass” da un solo motore è giallo. Un “Pass” da due motori è verde. Entrambi sono gratuiti su validator: caricate il file, ottenete due report e allegateli all’evidenza QA. Se gPdf ha generato il file, il validatore è la ricevuta pubblica che l’API ha rispettato la propria dichiarazione di conformità.

Se state costruendo sulla gPdf API, il riferimento E-invoice API (§5) mostra come emettere direttamente PDF/A-3 Factur-X / ZUGFeRD. Il validatore lo conferma poi dall’esterno. Due motori, un caricamento: è il modello adatto a un audit.