ISO 19005-4 (PDF/A-4): NextPDF feature mapping

At a glance

International Organization for Standardization (ISO) 19005-4:2020 is the Portable Document Format (PDF) 2.0 archival profile known as PDF/A-4. This page maps that profile to NextPDF without overstating support: what Core emits, what the nextpdf/pro extension adds, and what NextPDF explicitly does not cover. NextPDF emits PDF/A-4-relevant structures; only a validator can assert that a file conforms.

Install

composer require nextpdf/core:^3
# PDF/A-4 file authoring (OutputIntent + ICC + XMP) requires:
# composer require nextpdf/pro

Conceptual overview

ISO 19005-4:2020 builds on ISO 32000-2:2020 (PDF 2.0), while PDF/A-2 and PDF/A-3 build on ISO 32000-1:2008 (PDF 1.7). NextPDF captures this lineage difference in ConformanceMode::requiresPdf17(). The method returns false for every PDF/A-4 case and true for PDF/A-2 and PDF/A-3.

PDF/A-4 defines three conformance shapes. The base profile does not use a pdfa:conformance letter. PDF/A-4e (Annex B, engineering / 3D content) sets pdfa:conformance = E. PDF/A-4f (Annex A, embedded files) sets pdfa:conformance = F. ISO 19005-4:2020 §6.7.3 specifies the PDF/A identification schema in the Association for Intelligent Information Management (AIIM) namespace. It says a file conforming to neither PDF/A-4e nor PDF/A-4f provides no pdfa:conformance entry. NextPDF mirrors this behavior exactly in ConformanceMode::pdfaConformanceLetter(): PdfA4 returns the empty string, PdfA4e returns E, PdfA4f returns F.

The critical edition boundary is PDF/A-4 file authoring. The OutputIntent dictionary, the embedded International Color Consortium (ICC) profile, the Extensible Metadata Platform (XMP) extension schema, font-subset guarantees, and the encryption prohibition are implemented in the Enterprise PdfAManager. The Enterprise PdfAManager ships in the nextpdf/pro extension. In a Core-only installation, Document::enablePdfA() raises InvalidConfigException because the security.pdfa capability is not registered. The runnable example (examples/32-pdfa4-icc.php) demonstrates this by checking the capability registry and degrading with a clear message instead of a stack trace.

Therefore, on Core alone, the PDF/A-4 surface is the discriminator only. NextPDF records which PDF/A-4 variant a document declares. NextPDF emits the pdfaid:part = 4 / pdfa:conformance markers the schema defines. Producing a complete PDF/A-4 file — and validating that it conforms — are separate steps. The first step requires nextpdf/pro. The second step requires veraPDF.

API surface

Surface	Edition	What it provides
`ConformanceMode::PdfA4` / `PdfA4e` / `PdfA4f`	core	The variant discriminator
`ConformanceMode::pdfaPart()` → `4`	core	ISO 19005 part number
`ConformanceMode::pdfaConformanceLetter()` → `''` / `'E'` / `'F'`	core	§6.7.3 conformance letter
`ConformanceMode::requiresPdf17()` → `false`	core	PDF 2.0 lineage gate
`Document::enablePdfA()`	pro	OutputIntent + ICC + XMP authoring; throws `InvalidConfigException` in Core

Code sample — Quick start

<?php

declare(strict_types=1);

use NextPDF\Conformance\ConformanceMode;

// Core: introspect the declared PDF/A-4f contract.
$mode = ConformanceMode::PdfA4f;
$mode->pdfaPart();              // 4
$mode->pdfaConformanceLetter(); // 'F'  (ISO 19005-4:2020 §6.7.3 / Annex A)
$mode->requiresPdf17();         // false (PDF/A-4 is PDF 2.0 lineage)

Code sample — Production

<?php

declare(strict_types=1);

use NextPDF\Core\Document;
use NextPDF\Exception\InvalidConfigException;
use NextPDF\Support\CapabilityRegistry;

// PDF/A-4 file authoring requires the Premium extension. Probe first so a
// Core-only install gets a clear rationale, not a stack trace.
$registry = CapabilityRegistry::getInstance();
if (!$registry->get('security.pdfa')->isAvailable()) {
    throw new InvalidConfigException(
        configKey: 'security.pdfa',
        givenValue: 'Core-only install',
        expectedType: 'nextpdf/pro extension (Enterprise PdfAManager)',
    );
}

$doc = Document::createStandalone();
$doc->enablePdfA(); // Emits OutputIntent + ICC + pdfaid XMP (Premium).
// … write content …
$doc->save(__DIR__ . '/out/archive-a4.pdf');

// The file now CARRIES PDF/A-4 structures. Conformance is still unproven
// until veraPDF asserts it:
//
//   verapdf --flavour 4 out/archive-a4.pdf

Edge cases & gotchas

Core cannot author a PDF/A-4 file. enablePdfA() throws in Core. Core exposes only the discriminator and XMP markers.
Base PDF/A-4 emits no pdfa:conformance. Per ISO 19005-4:2020 §6.7.3, only PDF/A-4e and PDF/A-4f set the letter. ConformanceMode::PdfA4 returns the empty string by design.
PDF 2.0 lineage, not PDF 1.7. A common error is reusing a PDF/A-3 pipeline that expects %PDF-1.7. PDF/A-4 is PDF 2.0; requiresPdf17() returns false for all PDF/A-4 cases.
ICC validation is Premium. ISO 19005-4:2020 §6.2.2 OutputIntent ICC validation (acsp magic, tag table, D50 white point) is handled by the Enterprise PdfAManager, not Core.
The library does not certify the file. Setting PdfA4f and emitting the markers does not make the output a valid PDF/A-4f file. Validate with veraPDF.

Performance

The Core PDF/A-4 surface is pure value-type introspection: enum match dispatch, O(1), and no allocation. The Premium authoring path adds the OutputIntent and ICC packet during the write. Its cost is the embedded-profile size, handled inside the writer budget. veraPDF validation runs out of band, not during generation.

Security notes

PDF/A-4 forbids encryption. The Enterprise PdfAManager enforces the encryption-prohibition invariant and orders it relative to enablePdfA() so a caller cannot accidentally combine Advanced Encryption Standard in Galois/Counter Mode (AES-GCM) with archival mode. Core’s forward-guard in HasSecurity::enablePdfA() rejects the unsupported combination before any bytes are written. See the project threat model for archival-pipeline detail.

Conformance

This page is a feature mapping, not a conformance claim.

ISO 19005-4:2020 area	Clause	NextPDF coverage	Status
Variant identification schema	§6.7.3	`ConformanceMode` emits `pdfaid:part = 4` and the `pdfa:conformance` letter	Claimed (Core; unit-tested in `tests/Unit/Conformance/`)
PDF 2.0 lineage gate	§6.7.3 / base	`requiresPdf17()` returns `false` for all PDF/A-4 cases	Verified (unit-tested)
OutputIntent + embedded ICC	§6.2.2	Enterprise `PdfAManager` (`nextpdf/pro`)	Premium-only (not Core)
XMP extension schema, font subsetting, encryption prohibition	§6 / Annex A/B	Enterprise `PdfAManager` (`nextpdf/pro`)	Premium-only (not Core)
Conformance determination	Clause 5	Not performed by NextPDF — veraPDF	Explicit non-coverage

Support is not conformance — and this page separates the two deliberately. (a) NextPDF Core emits the structures ISO 19005-4:2020 §6.7.3 defines for variant identification; this is implementation, evidenced by tests/Unit/Conformance/ConformanceModePdfAVariantTest.php (passing). (b) A file being PDF/A-4 conformant is a separate assertion that only a validator can make, per ISO 19005-4:2020 Clause 5. Clause 5 states that a checking tool performs the actual determination of conformance against the normative requirements. NextPDF makes claim (a). NextPDF does not make claim (b). Validate with veraPDF (verapdf --flavour 4 …, or php oracle/run.php for the oracle harness — which only runs when the veraPDF binary is present, an opt-in gate).

The phrases “PDF/A-4 compliant”, “fully conformant”, and “PDF/A-4 certified” are deliberately absent from this page. NextPDF emits PDF/A-4-relevant structures; it does not guarantee a conforming file.

Citations are paraphrased from the NextPDF compliance corpus. Full 64-character reference_id digests are recorded in the page front matter and in docs/public/modules/core/_normative-evidence-conf.md.