PDF або відповідає PDF/A-3, або ні. Навіщо тоді перевіряти один і той самий файл у двох валідаторах?

Практична причина проста: специфікація PDF/A настільки велика, що дві коректні реалізації можуть розійтися на граничних випадках. Для процесу, який має витримати аудит, один “Pass” від одного рушія — це радше жовте світло, не зелене.

PDF/A — це не один простий алгоритм

PDF/A описано в кількох частинах ISO 19005: PDF/A-1, PDF/A-2, PDF/A-3 і PDF/A-4, з рівнями b, a, u, e та f. Нижче лежить базова специфікація PDF, ISO 32000. Загалом це тисячі сторінок нормативного тексту.

Розбіжності часто виникають у таких місцях:

Прозорість у PDF/A-2/3: дозволена за певних умов, але межі умов можуть трактуватись по-різному.
ICC-профілі: обов’язковий, рекомендований чи недостатній — суворість рушіїв відрізняється.
Метадані вкладень у PDF/A-3: AFRelationship, посилання /AF і XMP мають збігатися.
Підмножини шрифтів: CID-шрифти й partial subsets часто створюють edge cases.

Це не завжди помилки. Так виглядає незалежна реалізація складного стандарту. Регульовані галузі тому й просять незалежне підтвердження.

Еталонний рушій і друга думка

veraPDF — еталонна реалізація, яку підтримує PDF Association. Якщо veraPDF показує “Pass”, це найсильніший одиночний сигнал для PDF/A.

Але найсильніший одиночний сигнал ще не дорівнює аудиторському доказу. Банки, медичні архіви, державні установи та системи довгострокового зберігання часто хочуть другий рушій, тому що:

Отримувач може користуватися іншим валідатором.
Помилку одного рушія не знайти повторним запуском того самого рушія.
Два незалежні підтвердження — звична практика compliance.

gPdf запускає veraPDF разом із власним рушієм на Rust + WebAssembly. Це незалежна реалізація тієї ж специфікації. Якщо обидва проходять, висновок значно сильніший; якщо розходяться, зрозуміло, з чого починати аналіз.

Два звіти за однією адресою

Цей workflow безкоштовний на gpdf.com/validator/. Без логіну: завантажте файл, veraPDF і edge engine gPdf спрацюють паралельно, а ви отримаєте два звіти поруч.

Типові сценарії:

Перед передачею PDF/A: завантажити, отримати два “Pass”, зберегти JSON-звіти як QA evidence.
Один рушій проходить, інший ні: порівняти звіти; часто проблема в XMP, посиланні /AF або metadata вкладення.
Обидва не проходять: виправляти генерацію в джерелі.
Аудит архівної партії: перевірити вибірку та додати результати до робочих документів.

Файл не зберігається. Він обробляється в пам’яті на Cloudflare Workers і видаляється після створення звіту.

Та сама логіка для e-invoice

У Factur-X / ZUGFeRD потрібно перевіряти не лише оболонку PDF/A-3, а й вбудований XML CII за EN 16931. gPdf validator використовує Mustang для XML і показує результат поруч із PDF/A-звітом.

Це не недовіра до інструмента. Це спосіб побудувати сильніший доказ через незалежні реалізації.

TL;DR

Один “Pass” — жовте світло. Два незалежні “Pass” — значно сильніший доказ. Завантажте файл у validator, отримайте два звіти й додайте їх до QA або аудиту. Якщо PDF створено через gPdf API, validator стає публічним підтвердженням заявленої відповідності.