PDF 2.0 Conformance Support

HotPDF can write and reload PDF 2.0 documents through the append-only pdf20 value in TPDFVersType

PDF/A-4 profiles

`PDFACompliance`	Profile	Generated identification
`'4'`	PDF/A-4 base	`part=4`, `rev=2020`, no conformance field
`'4E'`	PDF/A-4e engineering	`part=4`, `rev=2020`, `conformance=E`
`'4F'`	PDF/A-4f associated files	`part=4`, `rev=2020`, `conformance=F`

All three profiles force a PDF 2.0 header, require the normal PDF/A output intent and metadata checks, and prohibit encryption

AddPDFAssociatedFile accepts associated files under PDF/A-3, PDF/A-4e, and PDF/A-4f while AddPDFA3AssociatedFile remains available for source compatibility

PDF/A-4e enables the existing 3D and RichMedia annotation paths for engineering documents

PDF/A-4 generation and validation

EndDoc now validates every PDF/A-4 profile before serialization and reports the first error with a stable rule code, ISO 19005-4 clause, and object path

Generation omits the trailer Info entry, enables automatic form appearances, creates the mandatory PDF/A-4f EmbeddedFiles name tree even when it is empty, and emits complete associated-file structures for PDF/A-4f attachment annotations

ValidatePDFA4 can also validate loaded files with bounded iterative traversal and collect all retained warnings and errors as typed issues or shared machine-readable compliance findings

The base profile rejects 3D, RichMedia, and FileAttachment annotations
The engineering profile accepts U3D and PRC content plus SetOCGState and GoTo3DView actions while rejecting FileAttachment annotations
The associated-file profile accepts FileAttachment annotations and requires the EmbeddedFiles name tree while rejecting 3D and RichMedia annotations
All profiles check XMP identification, encryption, trailer ID, Info restrictions, actions, annotations, form state, output intents, font embedding, optional content, and embedded-file metadata

Transactional PDF/A-4 repair

RepairPDFA4 applies a bounded whitelist of structural and XMP normalisations inside an object-graph transaction, validates the result, and restores the complete original state on a budget failure, validation regression, exception, or unmet full-conformance policy

The repair can normalise the PDF 2.0 header, trailer ID, metadata streams and dictionaries, namespace-aware identification properties, forbidden Catalog keys, and presentation entries without rewriting page content, fonts, colour, transparency, images, graphics operators, or extracted text

Default policy commits safe repairs even when unrelated unsafe findings remain, while RequireFullConformance changes that contract to all-or-nothing conformance

PDF/X-6 profiles

PDFXCompliance accepts 'X-6', 'X-6p', and 'X-6n', forces PDF 2.0, emits the matching XMP identification, and runs fail-closed generation validation at EndDoc

ValidatePDFX6 also validates loaded documents with bounded object and issue budgets, stable clause-aware typed or shared compliance findings, and independently selectable output-intent, page-box, exchange, font, and annotation checks

Complete PDF/X-6 uses an embedded ICC destination profile
PDF/X-6p uses an external gray, RGB, or CMYK profile reference
PDF/X-6n uses an external N-colourant profile reference with a matching two-to-fifteen-entry colourant table
Page-level output intents override Catalog scope for the corresponding PDF 2.0 page
Inherited and direct page boxes, annotations, actions, forms, fonts, graphics state, and resource exchange constraints are checked without mutating the graph

See PDF/X-6 authoring and validation for profile setup and API examples

PDF/UA-2 workflow

PDF.PDFUACompliance := True;
PDF.PDFUAPart := 2;
PDF.Lang := 'en-US';
PDF.BeginDoc;
Root := PDF.AddStructureElement('Document', nil);
PDF.AddStructureElementNS('WidgetGroup',
  'https://example.com/ns/widgets', Root);
PDF.EndDoc;

Part 2 forces PDF 2.0 and emits pdfuaid:part=2 plus pdfuaid:rev=2024

RegisterStructureNamespace creates or reuses an indirect /Type /Namespace dictionary and lists it in StructTreeRoot /Namespaces

AddStructureElementNS attaches the registered dictionary through the structure element /NS entry and permits custom roles in that namespace

ValidatePDFUA2Structure performs non-mutating validation with explicit object, expanded-table-cell, and issue bounds, while RepairPDFUA2Structure atomically normalises recoverable namespace, attribute, list, table, East Asian inline, pronunciation, alternate-text, language-inheritance, heading-order, and Artifact-tag defects and rolls back when post-repair validation fails

The three validators can return THPDFComplianceFindings with shared profile, severity, rule, clause, object, and page fields; the detailed PDF/UA-2 repair overload also records applied, unresolved, rolled-back, and failed provenance for deterministic ComplianceFindingsToJSON output

SetStructurePronunciation writes per-element pronunciation hints and AddPronunciationLexicon embeds ordered PLS document lexicons through StructTreeRoot/PronunciationLexicon

Validation at `EndDoc`

The structure root must contain exactly one top-level Document element
Every namespace dictionary must be indirect, typed as Namespace, and carry a unique non-empty URI
Every structure-element /NS reference must resolve to a dictionary listed by the root /Namespaces array
An unnamespaced role must be a PDF 2.0 standard role or resolve through RoleMap
Duplicate namespace role maps must agree before canonical repair can merge their URI registrations
Custom structure attribute owners require a registered explicit namespace and valid non-negative revision semantics
Lists, tables, Ruby, Warichu, pronunciation hints, and PLS lexicons retain their required PDF 2.0 hierarchy, types, sequences, and bounded association semantics

PDF 2.0 structure roles

The typed enum adds DocumentFragment, Aside, Title, FENote, Sub, Em, Strong, and Artifact

The string overload additionally accepts the open-ended Hn form, including H7 and higher