gPdf render/edge
Blog

Mengapa dua validator PDF/A lebih baik daripada satu

Hasil PDF/A dari satu engine belum cukup sebagai bukti audit. Ini alasan validasi dua engine penting dan cara menjalankannya gratis di gpdf.com/validator/.

by gPdf Engineering
#pdf-a#compliance#validation

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

Jawabannya praktis: spesifikasi PDF/A cukup besar sehingga dua implementasi yang benar tetap bisa berbeda pada edge case. Dalam workflow yang harus lolos audit, “Pass” dari satu engine adalah lampu kuning, bukan hijau.

PDF/A bukan satu algoritma sederhana

PDF/A tersebar di beberapa bagian ISO 19005: PDF/A-1, PDF/A-2, PDF/A-3, PDF/A-4, dengan level b, a, u, e, dan f. Semuanya berdiri di atas spesifikasi PDF utama, ISO 32000. Total aturan yang harus dibaca mencapai ribuan halaman.

Perbedaan sering muncul pada:

  • Transparency di PDF/A-2/3: diizinkan dalam kondisi tertentu, tetapi batasnya bisa ditafsirkan berbeda.
  • ICC color profile: apakah wajib atau hanya direkomendasikan, tiap engine bisa punya ketegasan berbeda.
  • Metadata file tertanam di PDF/A-3: AFRelationship, referensi /AF, dan XMP harus konsisten.
  • Font subsetting: CID font dan subset parsial sering memunculkan kasus tepi.

Itu tidak selalu bug. Ini konsekuensi wajar dari standar kompleks yang diimplementasikan secara independen. Karena itu, industri yang diatur biasanya meminta konfirmasi kedua.

Engine referensi dan opini kedua

veraPDF adalah implementasi referensi yang dikelola PDF Association. Jika veraPDF memberi “Pass”, itu sinyal single-engine terkuat untuk PDF/A.

Namun sinyal tunggal terbaik tetap bukan bukti audit yang lengkap. Bank, arsip kesehatan, kantor pemerintah, dan sistem penyimpanan jangka panjang sering meminta engine kedua karena:

  • Penerima dokumen mungkin memakai validator lain.
  • Bug di satu engine tidak akan terlihat jika engine yang sama dijalankan dua kali.
  • Dua konfirmasi independen adalah pola umum dalam compliance.

Di gPdf, kami menjalankan veraPDF bersama engine sendiri yang ditulis dengan Rust + WebAssembly. Ini implementasi independen dari spesifikasi yang sama. Jika keduanya pass, kesimpulannya jauh lebih kuat; jika berbeda, investigasi punya titik awal yang jelas.

Dua laporan dari satu URL

Workflow ini gratis di gpdf.com/validator/. Tanpa login: unggah file, veraPDF dan gPdf edge engine berjalan paralel, lalu dua laporan tampil berdampingan.

Penggunaan umum:

  • Sebelum mengirim PDF/A: unggah file, pastikan dua “Pass”, simpan JSON report sebagai evidence QA.
  • Satu engine pass, satu gagal: bandingkan report; sering kali masalahnya ada di XMP, referensi /AF, atau metadata attachment.
  • Keduanya gagal: perbaiki proses pembuatan dokumen.
  • Audit batch arsip: validasi sample dan lampirkan hasilnya ke dokumen audit.

File tidak disimpan. Pemrosesan terjadi in-memory di Cloudflare Workers dan file dibuang setelah report dibuat.

Pola yang sama untuk e-invoice

Factur-X / ZUGFeRD perlu memvalidasi bukan hanya shell PDF/A-3, tetapi juga XML CII EN 16931 yang tertanam. gPdf validator menjalankan Mustang untuk XML dan menampilkan hasilnya bersama report PDF/A.

Compliance tidak dibangun dari satu alat saja, tetapi dari konfirmasi independen yang bisa diverifikasi.

TL;DR

“Pass” dari satu engine adalah lampu kuning. Dua “Pass” independen jauh lebih kuat. Gunakan validator, ambil dua report, lalu lampirkan ke QA atau audit. Jika PDF dibuat oleh gPdf API, validator menjadi bukti publik atas klaim compliance tersebut.