Un PDF è conforme a PDF/A-3 oppure non lo è. Allora perché passare lo stesso file in due validatori?

Perché nella pratica la specifica è abbastanza ampia da far divergere due implementazioni corrette sui casi limite. In un flusso che deve reggere un audit, un “Pass” di un solo motore è un semaforo giallo, non verde.

PDF/A non è un singolo algoritmo

PDF/A vive in più parti della ISO 19005: PDF/A-1, PDF/A-2, PDF/A-3 e PDF/A-4, con livelli b, a, u, e, f. Sotto c’è anche la specifica PDF di base, ISO 32000. La superficie normativa arriva a migliaia di pagine.

Le differenze emergono spesso qui:

Trasparenza in PDF/A-2/3: ammessa a certe condizioni, ma i confini non sono sempre interpretati allo stesso modo.
Profili ICC: obbligatori, consigliati o insufficienti a seconda del motore.
Metadati degli allegati in PDF/A-3: AFRelationship, riferimenti /AF e XMP devono essere coerenti.
Font subsetting: font CID e subset parziali creano casi limite reali.

Non sono necessariamente bug. È la conseguenza naturale di uno standard complesso implementato in modo indipendente. I settori regolati, per prudenza, chiedono una seconda conferma.

Il motore di riferimento e la seconda opinione

veraPDF è l’implementazione di riferimento mantenuta dalla PDF Association. Se veraPDF dice “Pass”, hai il segnale singolo più forte per PDF/A.

Ma il miglior segnale singolo non è ancora prova da audit. Banche, archivi sanitari, uffici pubblici e sistemi di conservazione a lungo termine spesso richiedono un secondo motore perché:

Il destinatario può usare un altro validator.
Un bug in un motore non si scopre rilanciando lo stesso motore.
Due conferme indipendenti sono una pratica comune in compliance.

gPdf combina veraPDF con un proprio motore in Rust + WebAssembly. È un’implementazione indipendente della stessa specifica. Se entrambi passano, la conclusione è molto più solida; se divergono, sai dove iniziare l’indagine.

Due report in un solo URL

Il flusso è gratuito su gpdf.com/validator/. Senza login: carichi il file, veraPDF e il motore edge di gPdf girano in parallelo, e ricevi due report affiancati.

Usi tipici:

Prima di consegnare un PDF/A: carica, verifica due “Pass”, conserva i JSON come evidenza QA.
Un motore passa e l’altro fallisce: confronta i report; spesso il problema è XMP, un riferimento /AF o metadata di allegato.
Entrambi falliscono: correggi la generazione alla fonte.
Audit di un batch archiviato: valida campioni e allega i risultati alla documentazione.

Il file non viene salvato. Viene elaborato in memoria su Cloudflare Workers e scartato dopo la generazione del report.

Lo stesso principio vale per l’e-invoicing

Con Factur-X / ZUGFeRD non basta verificare il guscio PDF/A-3; va validato anche l’XML CII EN 16931 incorporato. Il validator gPdf usa Mustang per questa parte e mostra il risultato accanto al report PDF/A.

Non è sfiducia verso uno strumento. È costruire evidenza con implementazioni indipendenti.

TL;DR

Un “Pass” singolo è giallo. Due “Pass” indipendenti sono molto più forti. Usa validator, scarica i due report e allegali a QA o audit. Se il PDF è stato generato da gPdf API, il validator è la ricevuta pubblica della conformità promessa.