Sebuah PDF antara sesuai dengan PDF/A-3 atau tidak. Jadi mengapa file yang sama perlu dijalankan melalui dua validator?

Jawaban singkatnya: karena spesifikasinya cukup besar sehingga dua implementasi yang benar tetap bisa berbeda pada edge case, dan workflow audit-grade memperlakukan “Pass” dari satu engine sebagai lampu kuning, bukan lampu hijau. Berikut versi lengkapnya.

PDF/A adalah tumpukan aturan yang dinegosiasikan, bukan satu algoritma

PDF/A didefinisikan di beberapa bagian ISO 19005 (PDF/A-1, PDF/A-2, PDF/A-3, PDF/A-4), masing-masing dengan level sub-konformitas (b, a, u, e, f), dan semuanya berdiri di atas spesifikasi PDF dasar (ISO 32000). Jika digabungkan, permukaan aturannya mencapai ribuan halaman teks normatif.

Beberapa contoh area tempat implementasi yang sama-sama conforming pernah berbeda:

Transparency di PDF/A-2/3: diizinkan dalam kondisi tertentu; kondisi tersebut ditulis secara prosedural, dan validator yang berbeda bisa mengimplementasikan pemeriksaan dengan cara berbeda.
Embedded color profiles: kapan profil ICC “wajib” dan kapan hanya “direkomendasikan”? Validator yang berbeda pernah menyebut file yang sama “Pass” dan “Fail” pada axis ini.
Embedded file metadata di PDF/A-3: AFRelationship, referensi /AF, embedded XMP — aturannya jelas, tetapi ketegasan enforcement bisa berbeda.
Font subsetting: PDF/A mewajibkan semua font tertanam dengan encoding sebenarnya. Edge case di sekitar CID-keyed fonts dengan subset parsial pernah menyebabkan validator tidak sepakat.

Ini bukan sekadar bug. Ini konsekuensi alami dari spesifikasi kompleks yang diimplementasikan tim independen dari teks normatif. Posisi konservatif — dan posisi yang diambil banyak industri teregulasi — adalah meminta beberapa konfirmasi independen.

Engine referensi + opini kedua

veraPDF adalah implementasi referensi yang dikelola PDF Association, badan standar yang menerbitkan PDF/A. veraPDF bersifat open-source, diaudit oleh working group industri, dan rule set-nya merupakan interpretasi kanonis atas teks ISO 19005. Jika veraPDF mengatakan “Pass”, itu sinyal terkuat yang bisa Anda dapat dari satu engine.

Namun “sinyal single-engine terkuat” tidak sama dengan “bukti yang cukup untuk audit”. Auditor di institusi teregulasi — bank, arsip rekam medis, kantor arsip pemerintah — sering meminta konfirmasi independen kedua karena:

Interpretasi veraPDF atas suatu aturan bisa berbeda dari validator lain yang dipakai auditee secara internal, sehingga file dapat ditolak downstream.
Bug pada engine mana pun, bahkan engine referensi, tidak dapat ditemukan dengan menjalankan engine yang sama dua kali.
Prinsip procurement “dua konfirmasi independen” umum dipakai di banyak domain compliance; PDF/A mewarisi ekspektasi itu dari use case arsip.

Pilihan engine kedua bergantung pada apa yang tersedia:

Adobe Acrobat Preflight berbayar dan closed-source — baik sebagai engine konfirmasi, tetapi membatasi siapa yang dapat memverifikasi ulang.
callas pdfaPilot berbayar dan menjadi pilihan enterprise de-facto, tetapi juga membatasi re-verification independen.
Engine open-source kedua — ada beberapa, biasanya kurang lengkap dibanding veraPDF.

Yang kami lakukan di gPdf adalah membangun engine sendiri dengan Rust + WebAssembly sebagai “implementasi ulang independen” yang disengaja — spesifikasi yang sama, aturan yang sama, ditulis dari nol oleh tim berbeda. Ketika kedua engine meloloskan file yang sama, kesimpulannya jauh lebih kuat daripada salah satunya sendiri. Ketika hasilnya berbeda, Anda punya bug yang jelas untuk diselidiki, entah di salah satu engine atau di file tersebut.

Validator yang menaruh keduanya di satu URL

Kami menjalankan keduanya di gpdf.com/validator/ — gratis, tanpa login, file dijalankan melalui veraPDF DAN engine edge kami secara paralel, lalu kedua report ditampilkan berdampingan. Use case-nya:

Anda membuat PDF/A dan ingin mengirimkannya: unggah ke validator, keduanya pass, lampirkan JSON report sebagai bukti QA. Selesai.
Satu engine gagal, engine lain pass: Anda punya bug yang presisi — bandingkan report, temukan field yang bermasalah. Sering kali penyebabnya hal kecil seperti timestamp XMP yang tidak sejajar atau referensi /AF yang hilang di PDF/A-3.
Keduanya gagal: file memang rusak; perbaiki di sumbernya.
Mengaudit batch arsip masuk: unggah PDF sampling acak, catat URL report, lampirkan ke work paper audit. Klaim “kami memverifikasi dengan veraPDF dan engine independen” lebih kuat daripada “kami menjalankan checker vendor kami.”

File yang Anda unggah tidak pernah meninggalkan request — engine berjalan in-memory di Cloudflare Workers dan file dibuang setelah report dirender. Tanpa login, tanpa persistence, tanpa quota.

Pola yang sama, digeneralisasi

Ini bukan hanya tentang PDF/A. Pola “dua konfirmasi independen” juga berlaku untuk:

Factur-X / ZUGFeRD e-invoices: gpdf.com/validator/ menjalankan Mustang (mustangproject.org) untuk CII XML EN 16931 yang tertanam, bersamaan dengan pemeriksaan PDF/A di atas. (Validating ZUGFeRD with Mustang — what passes, what fails membahas workflow tersebut.)
TLS certificates: setiap log CA modern diperiksa silang oleh beberapa monitor.
Build reproducibility: dua rebuild independen dari source yang sama seharusnya menghasilkan output yang byte-identical.

Dunia compliance sudah memakai pola ini selama puluhan tahun. PDF/A hanya sedang mengejar.

TL;DR

“Pass” dari satu engine adalah lampu kuning. “Pass” dari dua engine adalah lampu hijau. Kedua engine tersedia gratis di validator — unggah file Anda, dapatkan dua report, lampirkan ke bukti QA. Jika file dibuat oleh gPdf, validator adalah tanda terima publik bahwa API memenuhi klaim compliance-nya.

Jika Anda membangun di atas gPdf API, E-invoice API reference (§5) menunjukkan cara menghasilkan Factur-X / ZUGFeRD PDF/A-3 secara langsung. Validator kemudian mengonfirmasinya secara eksternal. Dua engine, satu upload — itulah pola audit-grade.