PDF หนึ่งไฟล์จะ conform กับ PDF/A-3 หรือไม่ก็ไม่ conform แล้วทำไมต้องเอาไฟล์เดียวกันไปตรวจด้วย validator สองตัว?

คำตอบคือในงานจริง สเปก PDF/A ใหญ่มากพอที่ implementation ที่ถูกต้องสองชุดอาจเห็นต่างกันใน edge case สำหรับ workflow ที่ต้องใช้เป็นหลักฐาน audit คำว่า “Pass” จาก engine เดียวจึงเป็นไฟเหลือง ไม่ใช่ไฟเขียว

PDF/A ไม่ใช่ algorithm เดียว

PDF/A อยู่ในหลายส่วนของ ISO 19005 ทั้ง PDF/A-1, PDF/A-2, PDF/A-3 และ PDF/A-4 พร้อมระดับ b, a, u, e, f และยังอ้างอิง PDF base specification อย่าง ISO 32000 อีกด้วย รวมแล้วเป็นกฎหลายพันหน้า

จุดที่มักทำให้ผลต่างกัน:

Transparency ใน PDF/A-2/3: อนุญาตภายใต้เงื่อนไข แต่ขอบเขตของเงื่อนไขตีความต่างกันได้
ICC color profile: บาง engine มองว่าจำเป็น บาง engine มองว่าแนะนำหรือยังไม่พอ
Embedded file metadata ใน PDF/A-3: AFRelationship, /AF reference และ XMP ต้องสอดคล้องกัน
Font subsetting: CID font และ partial subset เป็น edge case ที่พบบ่อย

สิ่งเหล่านี้ไม่จำเป็นต้องเป็น bug เสมอไป แต่เป็นผลตามธรรมชาติของมาตรฐานซับซ้อนที่ถูก implement โดยทีมอิสระหลายทีม อุตสาหกรรม regulated จึงมักขอ independent confirmation

Reference engine และ second opinion

veraPDF คือ reference implementation ที่ PDF Association ดูแล ถ้า veraPDF ให้ “Pass” นั่นคือ single-engine signal ที่แข็งแรงที่สุดสำหรับ PDF/A

แต่ signal เดียวที่ดีที่สุดก็ยังไม่เท่ากับ audit evidence ธนาคาร ระบบ archive ทางการแพทย์ หน่วยงานรัฐ และระบบเก็บเอกสารระยะยาวมักต้องการ engine ที่สอง เพราะ:

ฝั่งรับไฟล์อาจใช้ validator คนละตัว
bug ใน engine เดียวไม่ถูกเปิดเผยด้วยการรัน engine เดิมซ้ำ
compliance มักใช้หลัก two independent confirmations

gPdf จึงรัน veraPDF ควบคู่กับ engine ของเราเองที่เขียนด้วย Rust + WebAssembly เป็น independent implementation ของสเปกเดียวกัน ถ้าทั้งสองผ่าน ความมั่นใจสูงขึ้นมาก ถ้าผลต่างกัน ก็มีจุดเริ่มต้นที่ชัดเจนสำหรับการตรวจสอบ

สอง report จาก URL เดียว

workflow นี้ใช้ฟรีที่ gpdf.com/validator/ ไม่ต้อง login เพียง upload file แล้ว veraPDF กับ gPdf edge engine จะรันพร้อมกันและแสดงสอง report เคียงข้างกัน

กรณีใช้งานทั่วไป:

ก่อนส่ง PDF/A: upload, ตรวจว่าทั้งสอง engine pass, เก็บ JSON report เป็น QA evidence
engine หนึ่ง pass อีก engine fail: เทียบ report มักเจอปัญหาใน XMP, /AF reference หรือ attachment metadata
ทั้งสอง fail: ต้องแก้ที่ source generation
audit archive batch: ตรวจไฟล์ตัวอย่างและแนบผลเข้ากับ audit workpaper

ไฟล์ที่ upload จะไม่ถูกเก็บถาวร ระบบประมวลผล in-memory บน Cloudflare Workers และทิ้งไฟล์หลังสร้าง report

ใช้กับ e-invoice ได้เช่นกัน

Factur-X / ZUGFeRD ต้องตรวจไม่เฉพาะ PDF/A-3 shell แต่รวมถึง embedded EN 16931 CII XML ด้วย gPdf validator ใช้ Mustang สำหรับ XML และแสดงผลคู่กับ PDF/A report

นี่ไม่ใช่การไม่ไว้ใจเครื่องมือใดเครื่องมือหนึ่ง แต่คือการสร้างหลักฐานที่แข็งแรงจาก implementation อิสระสองชุด

TL;DR

single-engine “Pass” คือไฟเหลือง dual-engine “Pass” คือหลักฐานที่แข็งแรงกว่า ใช้ validator อัปโหลดไฟล์ รับสอง report แล้วแนบกับ QA หรือ audit หาก PDF สร้างจาก gPdf API ตัว validator ก็คือหลักฐานสาธารณะว่า compliance claim ถูกทำได้จริง