PDF या तो PDF/A-3 compliant है या नहीं। फिर उसी file को दो validators से क्यों जांचना चाहिए?

क्योंकि व्यवहार में PDF/A specification इतनी बड़ी है कि दो सही implementations भी edge cases पर अलग राय दे सकती हैं। Audit-grade workflow में single-engine “Pass” को green light नहीं, yellow light माना जाता है।

PDF/A एक simple algorithm नहीं है

PDF/A कई ISO 19005 parts में फैला है: PDF/A-1, PDF/A-2, PDF/A-3, PDF/A-4, और इनके b, a, u, e, f जैसे conformance levels। इसके नीचे PDF की मूल specification ISO 32000 भी है। कुल मिलाकर हजारों pages की normative text बनती है।

जहां differences दिखते हैं:

PDF/A-2/3 transparency: कुछ conditions में allowed है, पर conditions की interpretation अलग हो सकती है।
ICC color profiles: क्या profile required है या recommended, यह validators अलग तरह से पढ़ सकते हैं।
PDF/A-3 embedded file metadata: AFRelationship, /AF references और XMP metadata में strictness का असर पड़ता है।
Font subsetting: CID fonts और partial subsets वाले cases में disagreement आम है।

यह हमेशा bug नहीं होता। Complex standard को अलग teams जब independently implement करती हैं, तो boundary cases में फर्क आना स्वाभाविक है। Regulated industries इसलिए independent confirmation मांगती हैं।

Reference engine के साथ second opinion

veraPDF PDF Association द्वारा maintained reference implementation है। अगर veraPDF “Pass” कहता है, तो यह PDF/A के लिए सबसे मजबूत single-engine signal है।

लेकिन strongest single signal भी audit evidence के बराबर नहीं है। Banks, healthcare archives, government records और long-term archives अक्सर second engine चाहते हैं क्योंकि:

Receiver अपने अंदर कोई दूसरा validator चला सकता है।
एक engine में bug हो तो उसी engine को दो बार चलाने से bug नहीं दिखेगा।
Compliance में “two independent confirmations” एक परिचित pattern है।

gPdf में हम veraPDF के साथ अपना Rust + WebAssembly engine चलाते हैं। यह same specification की independent implementation है। दोनों pass हों तो confidence बहुत बढ़ता है; mismatch हो तो investigation का clear starting point मिलता है।

एक URL पर दो reports

यह workflow gpdf.com/validator/ पर मुफ्त है। Login की जरूरत नहीं। File upload करें, veraPDF और gPdf edge engine parallel में चलते हैं, और दोनों reports side by side मिलते हैं।

Common workflows:

PDF/A ship करने से पहले: upload करें, dual pass देखें, JSON reports को QA evidence में रखें।
एक pass, एक fail: reports compare करें; अक्सर problem XMP timestamp, missing /AF reference या attachment relation में मिलती है।
दोनों fail: source generation ठीक करें।
Archive batch audit: sampled PDFs validate करें और reports audit workpaper में attach करें।

Uploaded file persist नहीं होती। Processing Cloudflare Workers पर in-memory होती है और report बनने के बाद file discard कर दी जाती है।

E-invoice में भी यही pattern

Factur-X / ZUGFeRD में सिर्फ PDF/A-3 shell नहीं, embedded EN 16931 CII XML भी validate करना होता है। gPdf validator XML side के लिए Mustang चलाता है और PDF/A result के साथ report दिखाता है।

Compliance में भरोसा single tool से नहीं, independent confirmations से बनता है।

TL;DR

Single-engine “Pass” yellow light है। Dual-engine “Pass” कहीं मजबूत evidence है। validator पर file डालें, दो reports लें और QA या audit में attach करें। अगर PDF gPdf API से बना है, validator उसके compliance claim की public receipt है।