gPdf render/edge
ব্লগ

PDF/A-3 ব্যাখ্যা: আর ফাইলটি সত্যিই compliant কি না যাচাই করার উপায়

PDF/A-3 হলো প্রচলিত PDF/A profile যা embedded attachments বৈধ করে, আর Factur-X / ZUGFeRD e-invoicing-এর ভিত্তি। পার্থক্য, চেকপয়েন্ট ও dual-engine validation।

by gPdf ইঞ্জিনিয়ারিং দল
#pdf-a#compliance#archival#e-invoice

PDF/A হলো PDF-এর archival রূপ: ২০২৬ সালে যে ডকুমেন্ট যেমন দেখায়, ২০৫০ সালেও যেন তেমনই render হয় সেই নিশ্চয়তা। প্রধান profile চারটি: PDF/A-1, 2, 3 ও 4; প্রতিটির আবার sub-conformance level আছে। এর মধ্যে PDF/A-3-ই EU e-invoicing-এর নীরব ভিত্তি, এবং ব্যাপক ব্যবহারে একমাত্র PDF/A profile যা archival wrapper-এর ভেতরে arbitrary file attachments অনুমোদন করে।

Invoice, regulatory filing বা “PDF + structured data” workflow নিয়ে কাজ করলে PDF/A-3 আপনার সামনে আসবেই। এখানে তার বাস্তব অর্থ, অন্য profile থেকে পার্থক্য এবং যাচাই করার পদ্ধতি দেওয়া হলো।

PDF/A family এক নজরে

ProfileISO partYearমূল বৈশিষ্ট্য
PDF/A-119005-12005প্রথম archival profile। Transparency নেই, JavaScript নেই, fonts embedded।
PDF/A-219005-22011JPEG2000, transparency ও layer support যোগ করে। Print fidelity ভালো।
PDF/A-319005-32012Embedded file attachments যোগ করে। Factur-X / ZUGFeRD-এর wrapper।
PDF/A-419005-42020আধুনিক revision; conformance model সহজ, b বনাম a split নেই।

Sub-level গুলো:

  • b (basic): visual fidelity বজায় থাকে; semantic-content guarantee নেই।
  • a (accessible): structure tagging + Unicode mapping; screen reader সঠিক ক্রমে text বের করতে পারে।
  • u (Unicode): Unicode mapping আছে, তবে full structure নেই।
  • e / f (শুধু PDF/A-4): engineering 3D content ও full forms।

তাই “PDF/A-3b” মানে: archival profile 3, যেখানে attachments allowed; basic level, যেখানে accessibility tagging বাধ্যতামূলক নয়। Invoicing-এ এটাই সবচেয়ে common variant।

PDF/A-3 কেন আলাদা

PDF/A-1 ও PDF/A-2 arbitrary embedded files নিষিদ্ধ করে। কারণ archival PDF self-contained হওয়া উচিত; ভেতরে data.xlsx থাকলে সেটি PDF থেকে আলাদা ভাবে নষ্ট হতে পারে এবং archival guarantee ভেঙে দিতে পারে।

PDF/A-3 একটি কঠোর শর্তে নিয়মটি relax করে: প্রতিটি embedded file-এ AFRelationship attribute থাকতে হবে, যা বলে attachment কীভাবে visible PDF content-এর সঙ্গে সম্পর্কিত। Valid values হলো Source, Data, Alternative, Supplement, Unspecified। PDF-কে /AF array-তে attachment তালিকাভুক্ত করতে হবে এবং attached file সম্পর্কে XMP metadata emit করতে হবে।

অর্থাৎ PDF/A-3 বলে: “ফাইল attach করতে পারো, কিন্তু সেটি কী এবং মানুষ যে PDF দেখে তার সঙ্গে সম্পর্ক কী তা স্পষ্ট ঘোষণা করতে হবে।” এই ঘোষণাই e-invoicing-এর ভিত্তি: human-readable invoice PDF-এ, machine-readable EN 16931 CII XML attachment-এ, এবং AFRelationship="Alternative" জানায় যে দুটো একই invoice-এর alternative representation।

Production-এ PDF/A-3 কোথায় থাকে

  • Factur-X (France, 2026 থেকে B2B rollout বাধ্যতামূলক): PDF/A-3 + CII XML, urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0# XMP namespace সহ।
  • ZUGFeRD 2.x (Germany, 2025 থেকে receipt বাধ্যতামূলক): PDF/A-3 + CII XML, urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0# XMP namespace সহ।
  • Engineering CAD archival: PDF/A-3-এ native CAD file attach থাকে। PDF হলো rendering, CAD হলো source।
  • Regulatory submissions: PDF/A-3-এ XML payloads attach থাকে, যেমন FDA submissions বা EU-listed issuers-এর ESEF financial reports।

এগুলোতে wrapper কেবল container নয়। এটি contract: PDF এবং attached file একই document, এবং দুটোই validate হতে হবে।

PDF/A-3 compliant কি না যাচাই করবেন কীভাবে

Official conformance checker হলো veraPDF (verapdf.org), PDF Association এটি maintain করে। এটি ISO 19005-3 ruleset implement করে; veraPDF যদি “Pass — PDF/A-3b” বলে, single engine থেকে এটিই সবচেয়ে শক্ত signal।

কিন্তু single-engine “Pass” audit-grade standard নয় (Why two PDF/A validators are better than one এ বিষয়ে বিস্তারিত)। Audit-grade pattern হলো দুটি independent engine চালানো এবং দুটো pass করলেই file compliant ধরা।

E-invoice file-এর জন্য আরেক engine লাগে: Mustang (mustangproject.org)। এটি Factur-X / ZUGFeRD-এর de-facto checker, যা embedded CII XML-কে EN 16931 Schematron-এর বিরুদ্ধে validate করে। PDF/A-3 conformance একা যথেষ্ট নয়; attached XML-ও valid EN 16931 হতে হবে, নইলে receiving AP system invoice reject করবে।

অনেক team Java install করে, veraPDF CLI setup করে, Mustang install করে, তারপর shell script দিয়ে output জোড়া লাগায়। কাজ করে, কিন্তু friction বেশি।

validator browser-এ তিনটি engine চালায়:

  1. veraPDF: official reference, PDF/A-3 conformance।
  2. gPdf Rust+WASM edge engine: independent re-implementation, second opinion।
  3. Mustang: embedded e-invoice payloads-এর জন্য EN 16931 CII XML Schematron।

File drop করুন, তিনটি parallel চলে, reports side-by-side আসে। QA evidence হিসেবে JSON download করা যায়। Login নেই, quota নেই।

PDF/A-3 report-এ কী দেখবেন

Failures সাধারণত কয়েকটি জায়গায় আসে:

  • Embedded file metadata missing: /AF array নেই, অথবা embedded file সেখানে listed নয়।
  • AFRelationship missing বা ভুল: e-invoice-এর জন্য Alternative হওয়া উচিত; অনেক PDF library default-এ Source বা Data দেয়।
  • XMP namespace missing বা ভুল: Factur-X ও ZUGFeRD-এর নির্দিষ্ট namespace URI আছে; এক character typo-ও fail করায়।
  • Fonts subsetted বা embedded নয়: PDF/A চায় document-এ ব্যবহৃত সব glyph font সহ embedded থাকুক। Declared কিন্তু unused font reference-ও edge case-এ fail করতে পারে।
  • Output intent missing: document pure black-and-white text হলেও PDF/A-তে colour intent (sRGB বা অন্য ICC profile) declare করতে হয়।
  • Document metadata incomplete: document info dictionary-তে /Title, /Producer, /CreationDate থাকতে হবে।

Report সাধারণত নির্দিষ্ট spec section দেখায়। Fix source-এ করুন; gPdf দিয়ে generate করলে API এগুলো auto-handle করে, আর validator হলো public receipt।

TL;DR

PDF/A-3 = PDF/A-2 + arbitrary files legal ভাবে embed করার ক্ষমতা। এটাই EU e-invoicing-কে বাস্তব করে: human-readable invoice + structured EN 16931 CII XML, এক archival wrapper-এ। Compliance মানে PDF/A-3 wrapper এবং attached XML, দুটোই pass করা।

POST /api/v1/e-invoice/render দিয়ে generate করুন। validator এ verify করুন। তিন engine (veraPDF + gPdf edge + Mustang), এক upload, free।