Политики валидации и WTPDF

Политики валидации добавляют к существующему движку структурного preflight проверяемые требования к документу и сохраняют форматы отчётов text, JSON, HTML и CSV

Встроенные политики

GetBuiltInValidationPolicy распознаёт default, compact, strict, wtpdf-reuse, wtpdf-accessibility, wtpdf-validated-reuse и wtpdf-validated-accessibility

Политики WTPDF проверяют машинно-верифицируемые ключевые требования: PDF 2.0, дерево структуры, непустой язык документа, XMP metadata с dc:title, встроенные шрифты и соответствующий PDF Declaration, а политики accessibility дополнительно требуют DisplayDocTitle=true

Эти проверки — детерминированный входной фильтр для поддерживаемых правил; они не заменяют полноценный семантический валидатор WTPDF, PDF/UA-2 или ISO/TS 32005

Metadata о Declaration

ReadWTPDFMetadata извлекает из XMP Catalog состояния reuse, accessibility и validated declaration, а также claimBy, claimDate, claimCredentials и claimReport

Reader принимает текущие URI registry и slash-форму из исходных примеров WTPDF 1.0, но возвращает актуальную каноническую форму URI

Публичные вспомогательные типы

THPDFWTPDFConformanceLevel выбирает один из вариантов — без WTPDF claim, reuse или accessibility validation, а THPDFWTPDFMetadata возвращает найденные в XMP declaration и детали claim

THPDFValidationJob и THPDFValidationJobs описывают упорядоченные входные данные batch-обработки, а THPDFValidationJobStatus, THPDFValidationJobResult и THPDFValidationJobResults возвращают упорядоченные результаты валидации

THPDFValidationBatchOptions управляет форматом отчёта, лимитами worker'ов и очереди, поведением fail-fast и отменой

THPDFMetadataFixMode выбирает инспекцию, аддитивный ремонт или синхронизацию, а THPDFMetadataFixResult сообщает валидность metadata и число изменённых свойств

Ограниченное batch-выполнение

RunValidationBatch валидирует независимые файлы конкурентно с управляемыми вызывающим кодом лимитами worker'ов и очереди, сохраняет порядок источников, поддерживает fail-fast и отмену и записывает для каждого job затраченное время и контекст ошибок с привязкой к источнику

Неположительный лимит worker'ов выбирает число активных процессоров, а неположительный лимит очереди — четыре job на worker

Независимый ремонт metadata

FixPDFMetadata использует mfmInspectOnly, mfmAddMissing или mfmSynchronize независимо от структурного preflight-ремонта

Режим add-missing сохраняет существующие свойства и создаёт базовый packet, если metadata отсутствует, а режим synchronize переписывает общие свойства Dublin Core, PDF и XMP из загруженного Info dictionary, не трогая посторонние RDF-описания