PDF либо соответствует PDF/A-3, либо нет. Зачем тогда прогонять один и тот же файл через два валидатора?

Практический ответ: спецификация достаточно велика, чтобы две корректные реализации расходились на пограничных случаях. Для процесса, который должен выдержать аудит, один “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-шрифты и частичные subsets часто создают пограничные случаи.

Это не обязательно ошибки. Так выглядит независимая реализация сложного стандарта разными командами. В регулируемых отраслях поэтому просят независимое подтверждение.

Эталонный движок и второе мнение

veraPDF — эталонная реализация, поддерживаемая PDF Association. Если veraPDF показывает “Pass”, это самый сильный одиночный сигнал для PDF/A.

Но даже лучший одиночный сигнал не равен аудиторскому доказательству. Банки, медицинские архивы, государственные реестры и системы долгосрочного хранения часто требуют второй движок, потому что:

Получатель может использовать другой валидатор и отклонить файл.
Ошибку одного движка нельзя найти, запустив тот же движок еще раз.
Два независимых подтверждения — привычная практика compliance.

В gPdf мы запускаем veraPDF рядом с собственным движком на Rust + WebAssembly. Это независимая реализация той же спецификации. Когда оба движка проходят, вывод значительно сильнее; когда расходятся, появляется понятная точка для расследования.

Два отчета по одному адресу

Этот процесс доступен бесплатно на gpdf.com/validator/. Без логина: загрузите файл, veraPDF и edge-движок gPdf проверят его параллельно, а вы получите два отчета рядом.

Типичные сценарии:

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

Файл не сохраняется. Он обрабатывается в памяти на Cloudflare Workers и удаляется после формирования отчета.

Та же логика для электронных счетов

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

Это не недоверие к конкретному инструменту. Это нормальный способ строить доказательство через независимые реализации.

TL;DR

Один “Pass” — желтый свет. Два независимых “Pass” — гораздо более сильное доказательство. Загрузите файл в validator, получите два отчета и приложите их к QA или аудиту. Если PDF создан через gPdf API, валидатор становится публичной квитанцией его соответствия.