veraPDF: проверка PDF/A и PDF/UA, отчёты и автоматизация

veraPDF — специализированный валидатор PDF/A и PDF/UA, а не просмотрщик или редактор. Его сильная сторона — формализованные правила, воспроизводимые отчёты и автоматизация пакетного контроля. Для чтения документов он избыточен, зато в электронных архивах, издательских конвейерах и системах приёмки отвечает на вопрос, который визуальный просмотр не закрывает: какие требования стандарта выполнены или нарушены.

Скачать veraPDF

Безопасная отправная точка — официальный портал загрузок veraPDF. Он публикует стабильный Release Installer, отдельную нестабильную development-сборку, архив прежних выпусков и GPG-подписи. Для рабочей среды разумно брать именно стабильный пакет: разработчики прямо предупреждают, что development-сборки могут содержать незавершённые изменения и не имеют тех же гарантий стабильности. На сентябрь 2026 года актуальная стабильная линия — 1.30, а последние примечания к выпуску относятся к версии 1.30.2.

Текущая страница загрузки показывает Greenfield Implementation. Это важнее старых формулировок в инструкции по установке, где всё ещё описаны Greenfield и вариант на Apache PDFBox как две параллельные сборки. В примечаниях к выпуску 1.30 RC прямо указано завершение поддержки PDFBox. Поэтому для новой установки не стоит искать PDFBox-редакцию по старым ссылкам: актуальным путём является Greenfield, использующий собственный парсер и модель veraPDF.

Дистрибутив поставляется ZIP-архивом с Java-установщиком и сценариями запуска для разных ОС. Перед установкой можно проверить подпись пакета: официальный сайт публикует GPG-подпись и отпечаток ключа 13DD 102B 4DD6 9354 D12D E5A8 3184 8632 78B1 7FE7. Это особенно уместно в архивных и корпоративных средах, где валидатор становится частью доверенной цепочки приёма документов. Проверка подписи полезнее скачивания копий с каталогов программ, потому что исключает подмену дистрибутива посредником.

Что такое veraPDF

veraPDF возник как отраслевой проект для формальной проверки PDF/A. Консорциум возглавляли Open Preservation Foundation и PDF Association при участии Digital Preservation Coalition; первоначальное финансирование шло через европейский проект PREFORMA. После завершения PREFORMA в 2017 году поддержку и устойчивое сопровождение взяла на себя Open Preservation Foundation, а специалисты PDF Association продолжают участвовать в разборе неоднозначностей стандарта. Это не случайная утилита для «проверки PDF», а инструмент, выросший из потребностей цифрового сохранения и отраслевой верификации.

Назначение veraPDF — определить, соответствует ли конкретный PDF заявленному профилю PDF/A или PDF/UA, сформировать объяснимый отчёт и при необходимости применить дополнительные институциональные правила. В экосистеме продукта есть настольный графический интерфейс, командная строка и Java-библиотека для интеграции. Отдельно существует veraPDF REST, а также veraPDF Arlington для проверки модели PDF 2.0; это родственные проекты, но их нельзя смешивать с основным настольным PDF/A/PDF/UA Conformance Checker, рассматриваемым здесь.

Хронология развития и поддержки

Публичные прототипы появились в 2015 году, версия 1.0 вышла в январе 2017 года с проверкой всех частей и уровней PDF/A. В 2018 году линия 1.12 получила параллельную обработку в CLI, что сделало инструмент практичнее для больших коллекций. В 2022 году версия 1.20 добавила PDF/A-4, включая варианты 4e и 4f. В последующих ветках развивалась проверка PDF/UA, а версия 1.26 уже содержала поддержку PDF/UA-2 на стадии развития стандарта.

Цикл 1.30 закрепил более заметные архитектурные изменения: прекращена поддержка PDFBox-реализации, появилась возможность установить только CLI без GUI, добавлена поддержка новых версий Java на уровне библиотек и продолжена работа над PDF/UA-2 и WTPDF. В 1.30.1 и 1.30.2 исправлялись правила доступности, парсинг шрифтов и вопросы безопасности. Для эксплуатационной среды это означает простое правило: сравнивать поведение нужно с текущей 1.30.x, а старые результаты 1.2x не считать эталоном, если спор касается недавно уточнённых правил или пограничного PDF.

Проект остаётся активным: roadmap указывает на новые выпуски примерно раз в год, а репозитории обновлялись в 2026 году. Для аудита полезно хранить не только итог «соответствует/не соответствует», но и версию veraPDF, выбранный профиль и полный машинный отчёт.

Основные функции veraPDF

Валидация PDF/A, PDF/UA и WTPDF

Ядро veraPDF применяет формализованные Validation Profiles к структуре PDF. Встроенные профили покрывают PDF/A-1a и 1b; PDF/A-2a, 2b и 2u; PDF/A-3a, 3b и 3u; PDF/A-4, 4e и 4f; PDF/UA-1 и PDF/UA-2, а также профили WTPDF 1.0 Accessibility и Reuse. Правило описывает проверяемый объект, условие и ссылку на соответствующее требование спецификации, поэтому результат можно разбирать на уровне конкретных нарушений, а не только по итоговому красному или зелёному статусу.

По умолчанию veraPDF определяет заявленный профиль по XMP-метаданным. Если декларация отсутствует или непригодна, применяется профиль по умолчанию — PDF/A-1b, если его не изменили в настройках. В регламентированном процессе профиль лучше задавать явно: это отделяет вопрос «что заявил файл» от вопроса «чего требует архив или заказчик».

Для PDF/UA есть принципиальная оговорка: veraPDF выполняет машинно проверяемые проверки. Некоторые требования доступности требуют человеческой оценки — например, адекватности альтернативного текста или логичности структуры в конкретном содержательном контексте. Поэтому успешный PDF/UA-отчёт veraPDF нельзя превращать в заявление, что документ полностью прошёл ручной аудит доступности.

Пакетная обработка и автоматизация

GUI удобен для единичной проверки, но CLI предназначен для конвейеров. Он принимает несколько файлов, каталог с рекурсивным обходом и ZIP-архивы с PDF. Это позволяет проверять входящую поставку целиком, а не открывать каждый документ вручную. Для больших партий доступна параллельная обработка несколькими процессами через параметр processes; по умолчанию используется один процесс, поэтому ускорение нужно включать осознанно с учётом доступных CPU и памяти.

Машинный отчёт можно передавать следующему этапу контроля качества. XML удобен для устойчивой интеграции, JSON — для сервисов, text — для краткого результата, raw — для низкоуровневого представления. В GUI основной выбор проще: XML для машинной обработки и HTML для чтения человеком.

Извлечение признаков PDF

Feature Reporter извлекает свойства документа независимо от самой проверки соответствия. Через конфигурацию можно запрашивать метаданные, сведения о шрифтах, изображениях, ICC-профилях, аннотациях, формах, вложениях, сигнатурах, цветовых пространствах, низкоуровневых объектах и других элементах. Это превращает veraPDF из бинарного валидатора в средство инвентаризации: например, архив может одновременно проверить PDF/A и собрать сведения о применённых шрифтах или изображениях.

Policy Checker и пользовательские правила

Стандарт PDF/A задаёт общие требования, но организация может иметь дополнительные ограничения: обязательный заголовок, запрет определённых шрифтов, допустимый набор сжатий, собственные правила метаданных. Policy Checker использует Schematron-правила поверх machine-readable report. Он не разбирает PDF заново, а проверяет уже извлечённые признаки, поэтому для политики важно заранее включить необходимые категории Feature Reporter.

В GUI есть Policy Creator, позволяющий собрать типовые условия без ручного написания всего Schematron-файла. Сложные политики всё равно требуют понимания структуры отчёта и XPath. Практическая ценность механизма — разделение нормативных слоёв: базовый профиль отвечает за ISO-соответствие, а policy-файл — за локальные требования учреждения.

Metadata Fixer

Greenfield-версия умеет исправлять ограниченный класс проблем метаданных. Возможности включают добавление XMP на уровне документа при его отсутствии, добавление корректной идентификации PDF/A или PDF/UA, удаление ложной идентификации, а для PDF/A-1 — синхронизацию свойств Info Dictionary и XMP. Исправление выполняется только при условиях, когда прочих нарушений соответствия нет и изменение метаданных действительно может привести документ к корректному состоянию.

Это не «ремонт PDF» в смысле Acrobat Preflight: veraPDF не обещает автоматически встраивать отсутствующие шрифты, перестраивать теги, исправлять цветовые пространства или конвертировать произвольный PDF в нужный PDF/A. Если файл провален из-за содержательных или структурных нарушений, валидатор сообщает о них, но исправление нужно делать внешним инструментом.

Интерфейс и удобство использования

Графический интерфейс veraPDF компактный и задачный. В главном окне выбирается PDF, папка или архив, тип операции, профиль соответствия и при необходимости пользовательская политика. После выполнения становятся доступны просмотр и сохранение отчётов. Такая структура хорошо подходит специалисту по контролю качества: почти всё, что нужно для разовой проверки, помещается в одном окне, без вкладок редактора и инструментов разметки.

Для новичка порог входа связан не столько с интерфейсом, сколько с предметной областью. Список PDF/A-2u, PDF/A-3a, PDF/A-4f или PDF/UA-2 ничего не объясняет пользователю, который не знает, какой стандарт требует архив или заказчик. Автоопределение облегчает первый запуск, но в регламентированном процессе профиль лучше задавать явно: декларация в XMP может отсутствовать, быть ошибочной или конфликтовать с фактическим заданием.

Расширенные настройки позволяют включать прошедшие правила, подробные сообщения, журнал, ограничивать число отображаемых ошибок и прекращать проверку после заданного количества провалов. Эти опции нужны прежде всего для управления объёмом и временем обработки. Например, документ с одной массово повторяющейся ошибкой шрифта может породить огромное число одинаковых проверок; ограничение отображения делает отчёт пригоднее для чтения, не меняя природу обнаруженного дефекта.

Официальная документация и актуальные скриншоты показывают англоязычный GUI. Актуальный перечень локализаций проект не публикует, поэтому наличие русского интерфейса нельзя считать подтверждённым.

Поддерживаемые форматы и совместимость

Основной входной формат — PDF. veraPDF не конвертирует DOCX, ODT, EPUB, изображения или электронные таблицы в PDF и не является универсальным просмотрщиком. При пакетной работе можно подать каталог или ZIP: программа рекурсивно найдёт PDF внутри. Есть режим обработки файла с нестандартным или отсутствующим расширением, но это не расширяет набор поддерживаемых форматов — валидатор всё равно ожидает содержимое PDF.

Служебные входы включают пользовательские Validation Profiles в XML и Schematron-политики. Конфигурация приложения также хранится в XML-файлах. Результат проверки можно вывести в XML, HTML, JSON, text или raw в зависимости от интерфейса и сценария. Важное различие: HTML здесь — отчёт о валидации, а не экспорт исходного PDF в веб-страницу; XML/JSON — структурированное описание проверки, а не преобразованная копия документа.

Совместимость со стандартами шире, чем просто PDF/A-1: актуальные профили охватывают PDF/A-1–4, PDF/UA-1/2 и WTPDF 1.0. При этом проверка PDF/UA ограничена автоматизируемыми требованиями. veraPDF не заявляет проверку PDF/X, PDF/E или полноценный контроль полиграфического preflight как основную функцию. Если организация принимает разные семейства ISO PDF, это нужно учитывать при выборе единого инструмента контроля.

Для интеграции доступна Java-библиотека, а JAR-плагины могут расширять Feature Reporter. Отдельный veraPDF REST следует считать самостоятельным серверным компонентом, а не функцией настольного GUI.

Паспорт обратимости операций

В обычном режиме veraPDF — аналитический инструмент, поэтому риск необратимого изменения невелик: проверка и извлечение признаков производят отчёты. Исключение — Metadata Fixer, где появляется изменённый PDF. Настройки позволяют задать отдельную папку и префикс имени исправленного файла; этим стоит пользоваться всегда, даже если исходник доступен из резервной копии. После исправления необходимо повторно валидировать именно новую копию.

Производительность и стабильность

veraPDF не публикует универсальные требования вида «N страниц в секунду», и такие цифры были бы мало полезны: стоимость проверки зависит от внутренней структуры PDF, числа объектов, шрифтов, изображений, тегов и количества срабатывающих правил. Документация прямо отмечает, что большой файл может потребовать сотни тысяч проверок, а многочисленные ошибки способны резко увеличить отчёт. Поэтому производительность нужно оценивать на своём корпусе, а не по размеру файла в мегабайтах.

Для контроля нагрузки есть несколько механизмов. Параметр —maxfailures прекращает валидацию после заданного числа провалов, —disableerrormessages сокращает формирование детальных сообщений, —maxfailuresdisplayed ограничивает число выводимых повторов одного правила, а —processes распределяет пакет по нескольким процессам. Эти настройки меняют либо полноту прогона, либо стоимость и объём отчётности.

Стабильность активно дорабатывается. В 1.30.2 исправлялись CFF/OpenType, альтернативные описания аннотаций и уязвимости при разборе Rich Text, XFA и PostScript-синтаксиса в шрифтах. Открытые пограничные случаи остаются, поэтому спорный результат следует воспроизводить на текущей стабильной версии и сверять с конкретным правилом.

Лицензирование и версии

veraPDF распространяется бесплатно с открытым исходным кодом и двойным лицензированием: GNU GPL v3 или более поздняя версия и Mozilla Public License v2 или более поздняя. Пользователь может выбирать подходящий набор условий. MPL допускает сочетание покрытых файлов с кодом под другими лицензиями при сохранении требований MPL для самих изменённых покрытых файлов; GPL предъявляет более широкие copyleft-требования к производным работам. Для простого запуска готовой программы лицензионной покупки не требуется.

Нет платной «Pro»-редакции, лимита страниц бесплатной версии или пробного периода. Стандартный настольный пакет можно получить без обязательной регистрации. Финансирование сопровождения идёт, в частности, через Open Preservation Foundation и пожертвования, но это не превращает загрузку в подписку. Организации, которые встраивают библиотеку в собственный продукт, должны отдельно оценить выбранную лицензию с учётом способа распространения своего кода.

Системные требования

Windows

Официальный репозиторий приложений указывает для текущего процесса установки предварительно установленную Java 8, 11, 17 или 21. Установщик запускается Windows batch-файлом, а CLI и GUI после установки имеют собственные batch-сценарии. Проект не публикует актуальную таблицу минимального объёма RAM, частоты CPU или конкретных редакций Windows, поэтому приписывать veraPDF неподтверждённые требования вроде «Windows 10 и 4 ГБ ОЗУ» неправильно.

macOS и Linux

Для macOS и Linux используется shell-сценарий установщика; общая документация формулирует поддержку как Windows, macOS или Linux при наличии Java 8 или новее. Репозиторий приложения уточняет поддерживаемые Java для установки как 8, 11, 17 и 21. Сборка проекта из исходников имеет отдельные требования и не равна требованиям готового приложения: для сборки перечислены Java 11, 17, 21 или 25 и Maven 3+.

Карта критических зависимостей

С точки зрения приватности настольный сценарий выгодно отличается от онлайн-валидаторов: документация описывает локальный выбор файлов, локальный запуск и локальное сохранение отчётов, без обязательной передачи PDF в облако. Но из этого нельзя делать более широкое заявление о полном отсутствии любых сетевых обращений приложения: например, в истории релизов упоминается проверка доступности новой версии. Для закрытого контура корректная мера — управлять сетевым доступом средствами ОС и фиксировать версию установленного пакета.

Преимущества и недостатки veraPDF

Плюсы и минусы

• Открытая и прозрачная модель проверки. Правила формализованы и развиваются при участии профильного PDF-сообщества, а исходный код доступен для аудита.

• Широкий охват PDF/A. Поддерживаются части 1–4 и их актуальные уровни, включая PDF/A-4e и PDF/A-4f.

• PDF/UA-1 и PDF/UA-2. Инструмент полезен как автоматический слой проверки доступности, если не подменять им обязательные ручные проверки.

• GUI и CLI в одной экосистеме. Один и тот же инструмент подходит для единичной проверки специалистом и для пакетного процесса.

• Структурированные отчёты. XML/JSON позволяют сохранять доказательство проверки и автоматически принимать решение в конвейере.

• Локальная обработка. Для Desktop/CLI не требуется отправлять документы в облачный сервис или заводить аккаунт.

• Дополнительные политики. Schematron позволяет наложить организационные требования поверх ISO-профиля.

• Нулевая стоимость лицензии на использование. Нет платной редакции, лимита страниц или пробного срока.

Минусы

• Не редактор и не конвертер. Большинство реальных дефектов PDF/A программа диагностирует, но не исправляет автоматически.

• Требуется знание стандартов. Выбор профиля и интерпретация ошибки часто требуют понимания PDF/A, PDF/UA и структуры PDF.

• Java как внешняя зависимость. Для стандартного десктопного развёртывания нужно поддерживать совместимую Java.

• PDF/UA не заканчивается автоматикой. Успешный результат не заменяет человеческую оценку тех требований доступности, которые нельзя проверить программно.

• Документация местами отстаёт от продукта. Например, страница установки продолжает описывать PDFBox-вариант, хотя ветка 1.30 прекратила его поддержку и текущий портал загрузки показывает Greenfield.

• Нет официальной универсальной оценки производительности. Для больших коллекций приходится самостоятельно выбирать лимиты, число процессов и параметры JVM.

Сравнение с аналогами

С Adobe Acrobat Pro veraPDF пересекается в проверке стандартов, но Acrobat — редактор и preflight-система с исправлениями и конвертацией, тогда как veraPDF удобнее как независимый открытый контрольный шлюз. callas pdfaPilot ближе к промышленной системе архива: он сочетает проверку с конвертацией и серверными вариантами, но распространяется коммерчески. PAC специализируется на доступности и полезнее там, где после автоматики нужен визуальный ручной контроль PDF/UA.

Sumatra PDF не является прямым конкурентом: это быстрый просмотрщик, а veraPDF — валидатор. В одном процессе Sumatra может служить для визуального просмотра, а veraPDF — для формальной проверки. Если требуется исправлять PDF, уместен PDF-XChange Editor; для OCR — ABBYY FineReader; для создания и преобразования PDF на Windows — PDF24 Creator.

Инструкция по установке

Подготовка и проверка дистрибутива

1. Установите совместимую Java. Для готового приложения официальный репозиторий перечисляет Java 8, 11, 17 или 21.

2. Скачайте стабильный Greenfield Release Installer с официального портала veraPDF, а не development-сборку.

3. При регламентированных требованиях скачайте рядом GPG-подпись и проверьте её опубликованным ключом проекта.

4. Распакуйте ZIP. Внутри находятся Java-установщик и сценарий для вашей ОС.

Windows

1. Запустите verapdf-install.bat из распакованного пакета. Если политика безопасности запрещает batch-файлы, Java-установщик можно вызвать напрямую через java -jar.

2. На шагах IzPack проверьте версию, выберите каталог установки и компоненты. В ветке 1.30 предусмотрен вариант установки только CLI, что полезно для сервера без GUI.

3. Завершите распаковку. В установленном каталоге появятся сценарии запуска, профили, конфигурация и выбранные дополнительные компоненты.

4. Для первого контроля версии запустите CLI с параметром —version. Для графического режима используйте verapdf-gui.bat.

macOS и Linux

1. После распаковки запустите shell-сценарий verapdf-install. При необходимости проверьте право на исполнение файла в соответствии с политикой своей системы.

2. Выберите каталог и компоненты в установщике. Для автоматизированного развёртывания veraPDF поддерживает XML-файл конфигурации установки.

3. После установки запустите verapdf —version из каталога программы, затем verapdf-gui для графического режима или verapdf для CLI.

4. Если команда должна быть доступна из любого каталога, настройте PATH или alias средствами своей ОС; это удобство оболочки, а не обязательный компонент veraPDF.

Первый запуск и базовая проверка

На первом запуске не меняйте десятки параметров сразу. Выберите небольшой PDF с известным заявленным профилем, оставьте режим Validation и Auto-detect, выполните проверку и сохраните XML и HTML. Затем повторите её с профилем, явно заданным по регламенту. Если результаты отличаются, сначала выясните, что заявлено в XMP и какой профиль действительно требуется, а не пытайтесь «подогнать» настройки под зелёный статус.

Установщик записывает данные для uninstaller, но документация не даёт единого актуального пути к нему на всех ОС. Перед удалением сохраните нужные XML-конфиги, пользовательские профили, Schematron-политики и отчёты, затем используйте созданный установщиком механизм удаления, если он доступен в вашей установке.

Практические кейсы

Приёмка PDF/A-поставки в электронный архив

Цель. Не допустить в фонд документы, которые лишь заявляют PDF/A, но фактически нарушают профиль. Подготовка. Зафиксируйте требуемый уровень, например PDF/A-2u, и отдельный каталог для отчётов. Действия. Для небольшой поставки выберите папку в GUI; для большого потока вызовите CLI с явным профилем и машинным форматом отчёта. Не полагайтесь только на auto-detect, если договор требует конкретный профиль.

Проверка результата. Система приёмки должна хранить итоговый статус, имя файла, версию veraPDF и отчёт, а дефектные PDF направлять на исправление отдельно. Ограничение. veraPDF диагностирует несоответствие, но не превратит произвольный дефектный PDF в PDF/A автоматически. После исправления внешним инструментом новый файл нужно валидировать повторно.

Автоматический контроль PDF/UA перед публикацией

Цель. Отсечь машинно обнаруживаемые ошибки доступности до ручного аудита. Подготовка. Определите требуемый профиль PDF/UA-1 или PDF/UA-2 и сохраните шаблон отчёта. Действия. Запустите валидацию в CLI, передайте неуспешные документы редактору тегов, а прошедшие — на ручную проверку содержательных требований.

Проверка результата. Прошедший veraPDF документ должен рассматриваться как «прошёл автоматические проверки», а не как «полностью доступен». Для ручного этапа можно применять PAC или специализированный процесс проверки чтения, структуры, альтернативных описаний и таблиц. Ограничение. Качество alt-текста и смысловая корректность структуры не сводятся к синтаксической проверке.

Институциональная политика поверх PDF/A

Цель. Проверять не только ISO-профиль, но и локальные правила: например, наличие заголовка и запрет конкретного шрифта. Подготовка. В Features Config включите Information Dictionary и Fonts, затем создайте policy через Policy Creator или Schematron. Действия. Выберите режим Policy, укажите policy-файл и PDF, выполните проверку, сохраните машинный отчёт.

Проверка результата. Разделите нарушения базового профиля и policy checks, чтобы сотрудники понимали, что именно нарушено: международный стандарт или внутреннее правило. Ограничение. Политика видит только те признаки, которые попали в Feature Report; если нужная категория выключена, правило не получает данных для корректной проверки.

Навигатор по сбоям

При спорном результате сначала сохраните исходник, отчёт, профиль и версию veraPDF, затем воспроизведите проверку. Минимальный пример помогает отличить дефект документа от ошибки или изменения валидатора.

Часто задаваемые вопросы

Может ли veraPDF сделать обычный PDF совместимым с PDF/A?

В общем случае нет. Metadata Fixer исправляет ограниченные проблемы XMP и идентификации, причём только когда другие нарушения отсутствуют. Для полноценной конвертации, внедрения шрифтов, исправления цветовых пространств или перестройки структуры нужен отдельный редактор или конвертер, после чего результат следует снова проверить veraPDF.

Что означает успешная проверка PDF/UA?

Она означает успешное прохождение реализованных машинно проверяемых требований выбранного профиля. Это не заменяет человеческие проверки там, где стандарт требует смысловой оценки. Для окончательного заключения о доступности нужен отдельный ручной этап.

Можно ли проверить целую папку или ZIP?

Да. GUI и CLI поддерживают пакетную работу; ZIP с PDF может обрабатываться рекурсивно. Для больших потоков CLI предпочтительнее, потому что его проще автоматизировать и он поддерживает управление числом процессов и форматом отчёта.

Можно ли использовать veraPDF как просмотрщик вместо Sumatra PDF?

Как хранить доказательство проверки для аудита?

Недостаточно сохранить только итог «валиден». Практичнее хранить исходный PDF, машинный отчёт, версию veraPDF, выбранный профиль и, если использовались дополнительные правила, policy-файл и конфигурацию извлечения признаков. Тогда результат можно воспроизвести позже и объяснить, по каким правилам было принято решение.

Вывод

veraPDF лучше всего подходит архивам, разработчикам, издательским и государственным системам, где PDF нужно принимать по формальным профилям и где важны автоматизация, открытый код и сохраняемый машинный отчёт. Сильнейший сценарий — независимая проверка после создания или исправления документа другим ПО: veraPDF выступает контрольной точкой, а не инструментом авторинга.

Для пользователя, которому нужно только читать PDF, программа избыточна и не заменяет Sumatra PDF. Для массового исправления дефектов, конвертации разнородных форматов и полноценного preflight рациональнее Acrobat Pro или callas pdfaPilot. Для углублённого ручного аудита доступности на Windows полезен PAC. Если же задача сформулирована как «точно и воспроизводимо проверить PDF/A или машинные требования PDF/UA, сохранить отчёт и встроить проверку в процесс», veraPDF остаётся одним из наиболее предметных открытых инструментов.