PDF या तो PDF/A-3 conform करता है या नहीं करता. फिर कोई भी same file पर दो validators क्यों चलाएगा?

Short answer: क्योंकि spec इतनी बड़ी है कि दो correct implementations भी edge cases पर disagree कर सकती हैं, और audit-grade workflow single-engine “Pass” को green light नहीं, yellow light मानता है. Long version यह है.

PDF/A is a stack of negotiated rules, not a single algorithm

PDF/A कई ISO 19005 parts में define है: PDF/A-1, PDF/A-2, PDF/A-3, PDF/A-4. इनके sub-conformance levels हैं: b, a, u, e, f. और ये सब underlying PDF specification (ISO 32000) के ऊपर build होते हैं. Combined surface area normative text के कई हजार pages है.

कुछ examples जहाँ conforming implementations historically diverge हुई हैं:

PDF/A-2/3 में transparency: specific conditions में allowed है; conditions procedural लिखी हैं और अलग validators check को अलग तरह implement करते हैं.
Embedded color profiles: ICC profile कब “required” है और कब “recommended”? Same file को अलग validators ने इस axis पर “Pass” और “Fail” दोनों कहा है.
PDF/A-3 में embedded file metadata: AFRelationship, /AF references, embedded XMP. Rules well-specified हैं, लेकिन enforcement strictness बदलती है.
Font subsetting: PDF/A requires all fonts to be embedded with actual encoding. Partial subsets वाले CID-keyed fonts के edge cases validator disagreements करा चुके हैं.

ये हमेशा bugs नहीं हैं. यह complex specification को independent teams द्वारा normative text से implement करने का natural consequence है. Conservative position, और most regulated industries की position, है: multiple independent confirmations मांगना.

The reference engine + the second opinion

veraPDF PDF Association द्वारा maintained reference implementation है: वही standards body जो PDF/A publish करती है. यह open-source है, industry working groups से audited है, और इसका rule set ISO 19005 text की canonical interpretation है. अगर veraPDF “Pass” कहता है, तो single engine से मिलने वाला यह सबसे strong signal है.

लेकिन “strongest single-engine signal” और “audit-passing evidence” एक ही बात नहीं हैं. Regulated institutions — banks, healthcare records archives, government records offices — के auditors अक्सर second independent confirmation मांगते हैं क्योंकि:

veraPDF किसी rule को उस validator से अलग interpret कर सकता है जिसे auditee internally use करता है, और downstream rejection हो सकती है.
किसी भी single engine में bug, reference engine में भी, same engine को दो बार चलाने से detect नहीं होगा.
Procurement principle “two independent confirmations” compliance domains में broadly applied है; PDF/A अपने archival use cases से वही expectation inherit करता है.

Second-engine choice available tools पर depend करता है:

Adobe Acrobat Preflight paid और closed-source है. Confirmation engine के रूप में fine है, लेकिन re-verification सीमित करता है.
callas pdfaPilot paid है और de-facto enterprise choice है, लेकिन independent re-verification को फिर सीमित करता है.
A second open-source engine: कुछ हैं, ज्यादातर veraPDF से less complete.

gPdf में हमने Rust + WebAssembly में अपना engine deliberately बनाया: same spec, same rules, लेकिन scratch से लिखा हुआ independent re-implementation. जब दोनों engines same file को pass करते हैं, conclusion किसी एक engine से बहुत stronger है. जब वे disagree करते हैं, तो investigate करने के लिए clear bug मिलता है: किसी एक engine में, या file में.

The validator that puts both on one URL

हम दोनों engines gpdf.com/validator/ पर host करते हैं: free, no login. File veraPDF और हमारे edge engine से parallel run होती है, और दोनों reports side-by-side return होते हैं. Use cases:

आप PDF/A generate करते हैं और ship करना चाहते हैं: validator में drop करें, दोनों pass हों, JSON reports को QA evidence के रूप में attach करें. Done.
एक engine fail, दूसरा pass: आपके पास precise bug है. Reports diff करें और offending field खोजें. अक्सर यह subtle चीज होती है: misaligned XMP timestamp या PDF/A-3 में missing /AF reference.
दोनों fail: file सच में broken है; source में fix करें.
Incoming archive batch audit करना: randomly-sampled PDFs drop करें, report URLs log करें, audit work paper में attach करें. “We verified with veraPDF and an independent engine” claim “we ran our vendor’s checker” से stronger है.

आप जो file upload करते हैं वह request से बाहर नहीं जाती. Engines Cloudflare Workers पर in-memory चलते हैं और report render होते ही file discard हो जाती है. No login, no persistence, no quota.

The same pattern, generalized

यह सिर्फ PDF/A के बारे में नहीं है. “Two independent confirmations” pattern यहाँ भी लागू होता है:

Factur-X / ZUGFeRD e-invoices: gpdf.com/validator/ embedded EN 16931 CII XML के लिए Mustang (mustangproject.org) चलाता है, ऊपर वाले PDF/A check के साथ. (Validating ZUGFeRD with Mustang — what passes, what fails उस workflow को cover करता है.)
TLS certificates: हर modern CA log multiple monitors से cross-check होता है.
Build reproducibility: same source से दो independent rebuilds byte-identical outputs produce करने चाहिए.

Compliance world यह decades से कर रही है. PDF/A बस catch up कर रहा है.

TL;DR

Single-engine “Pass” yellow light है. Dual-engine “Pass” green है. दोनों engines validator पर free हैं: file drop करें, दो reports लें, QA evidence में attach करें. अगर file gPdf ने generate की है, तो validator public receipt है कि API ने अपना compliance claim पूरा किया.

अगर आप gPdf API पर build कर रहे हैं, तो E-invoice API reference (§5) दिखाता है कि Factur-X / ZUGFeRD PDF/A-3 directly कैसे emit करें. Validator फिर इसे externally confirm करता है. Two engines, one upload: यही audit-grade pattern है.