Zum Inhalt springen

ISO 19005-4 (PDF/A-4): Feature-Mapping für NextPDF

ISO 19005-4:2020 (PDF/A-4) ist das Archivierungsprofil von PDF 2.0. Diese Seite ordnet transparent ein, wie NextPDF es abbildet: was Core ausgibt, was die Erweiterung nextpdf/pro ergänzt und was NextPDF ausdrücklich nicht abdeckt. NextPDF gibt PDF/A-4-relevante Strukturen aus; nur ein Validator kann bestätigen, dass eine Datei konform ist.

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

ISO 19005-4:2020 baut auf ISO 32000-2:2020 (PDF 2.0) auf — anders als PDF/A-2 und PDF/A-3, die auf ISO 32000-1:2008 (PDF 1.7) aufbauen. NextPDF bildet diesen Abstammungsunterschied in ConformanceMode::requiresPdf17() ab. Diese Methode liefert false in jedem PDF/A-4-Fall und true für PDF/A-2 und PDF/A-3.

PDF/A-4 definiert drei Konformitätsausprägungen. Das Basisprofil hat keinen pdfa:conformance-Buchstaben. PDF/A-4e (Anhang B, technische / 3D-Inhalte) setzt pdfa:conformance = E. PDF/A-4f (Anhang A, eingebettete Dateien) setzt pdfa:conformance = F. ISO 19005-4:2020 §6.7.3 spezifiziert das PDF/A-Identifikationsschema im AIIM-Namensraum. Die Norm schreibt vor, dass eine Datei, die weder PDF/A-4e noch PDF/A-4f entspricht, keinen pdfa:conformance-Eintrag bereitstellt. NextPDF bildet das exakt in ConformanceMode::pdfaConformanceLetter() ab: PdfA4 liefert die leere Zeichenkette, PdfA4e liefert E, PdfA4f liefert F.

Die entscheidende Editionsgrenze verläuft hier: Das Authoring von PDF/A-4-Dateien — das OutputIntent-Dictionary, das eingebettete ICC-Profil, das XMP-Erweiterungsschema, die Font-Subset-Garantien und das Verschlüsselungsverbot — ist im Enterprise-PdfAManager implementiert. Der Enterprise-PdfAManager ist Teil der Erweiterung nextpdf/pro. In einer reinen Core-Installation löst Document::enablePdfA() eine InvalidConfigException aus, weil die Fähigkeit security.pdfa nicht registriert ist. Das lauffähige Beispiel (examples/32-pdfa4-icc.php) zeigt das, indem es die Capability-Registry abfragt und mit einer klaren Meldung statt mit einem Stacktrace endet.

Daher besteht die PDF/A-4-Oberfläche in Core allein nur aus dem Diskriminator: NextPDF hält fest, welche PDF/A-4-Variante ein Dokument deklariert. NextPDF gibt die vom Schema definierten Marker pdfaid:part = 4 / pdfa:conformance aus. Eine vollständige PDF/A-4-Datei zu erzeugen und ihre Konformität zu validieren, sind getrennte Schritte. Für den ersten Schritt ist nextpdf/pro erforderlich. Für den zweiten Schritt ist veraPDF erforderlich.

OberflächeEditionWas es bereitstellt
ConformanceMode::PdfA4 / PdfA4e / PdfA4fcoreDer Variantendiskriminator
ConformanceMode::pdfaPart()4coreISO 19005-Teilnummer
ConformanceMode::pdfaConformanceLetter()'' / 'E' / 'F'core§6.7.3 Konformitätsbuchstabe
ConformanceMode::requiresPdf17()falsecorePDF 2.0-Abstammungsgate
Document::enablePdfA()proOutputIntent-, ICC- und XMP-Authoring; wirft InvalidConfigException in Core
<?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)
<?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
  • Core kann keine PDF/A-4-Datei erzeugen. enablePdfA() wirft in Core. Nur der Diskriminator und die XMP-Marker sind Core-Oberfläche.
  • Basis-PDF/A-4 gibt kein pdfa:conformance aus. Laut ISO 19005-4:2020 §6.7.3 setzen nur PDF/A-4e und PDF/A-4f den Buchstaben. ConformanceMode::PdfA4 liefert die leere Zeichenkette — das ist so vorgesehen.
  • PDF 2.0-Abstammung, nicht PDF 1.7. Ein häufiger Fehler ist, eine PDF/A-3-Pipeline wiederzuverwenden und dabei %PDF-1.7 zu erwarten. PDF/A-4 ist PDF 2.0; requiresPdf17() liefert false für alle PDF/A-4-Fälle.
  • Die ICC-Validierung ist Premium. Die OutputIntent-ICC-Validierung gemäß ISO 19005-4:2020 §6.2.2 (acsp-Magic, Tag-Tabelle, D50-Weißpunkt) ist Aufgabe des Enterprise-PdfAManager, nicht von Core.
  • Die Bibliothek zertifiziert die Datei nicht. PdfA4f zu setzen und die Marker auszugeben, macht die Ausgabe noch nicht zu einer gültigen PDF/A-4f-Datei. Führen Sie veraPDF aus.

Die Core-PDF/A-4-Oberfläche ist reine Werttyp-Introspektion (enum-match-Dispatch, O(1), keine Allokation). Der Premium-Authoring-Pfad ergänzt den OutputIntent und das ICC-Paket beim Schreiben. Seine Kosten entsprechen der Größe des eingebetteten Profils, die innerhalb des Writer-Budgets berücksichtigt wird. Die veraPDF-Validierung ist ein Out-of-Band-Schritt, nicht Teil der Generierung.

PDF/A-4 verbietet Verschlüsselung. Der Enterprise-PdfAManager erzwingt die Invariante des Verschlüsselungsverbots. Der Enterprise-PdfAManager setzt diese Invariante im Ablauf von enablePdfA() durch, damit ein Aufrufer AES-GCM nicht versehentlich mit dem Archivmodus kombinieren kann. Der Forward-Guard von Core in HasSecurity::enablePdfA() weist die nicht unterstützte Kombination zurück, bevor irgendwelche Bytes geschrieben werden. Details zur Archivierungs-Pipeline finden Sie im Bedrohungsmodell des Projekts.

Dies ist ein Feature-Mapping, keine Konformitätsaussage.

ISO 19005-4:2020-BereichKlauselNextPDF-AbdeckungStatus
Schema zur Variantenidentifikation§6.7.3ConformanceMode gibt pdfaid:part = 4 und den pdfa:conformance-Buchstaben ausBeansprucht (Core; Unit-getestet in tests/Unit/Conformance/)
PDF 2.0-Abstammungsgate§6.7.3 / BasisrequiresPdf17() liefert false für alle PDF/A-4-FälleVerifiziert (Unit-getestet)
OutputIntent + eingebettetes ICC§6.2.2Enterprise-PdfAManager (nextpdf/pro)Nur Premium (nicht Core)
XMP-Erweiterungsschema, Font-Subsetting, Verschlüsselungsverbot§6 / Anhang A/BEnterprise-PdfAManager (nextpdf/pro)Nur Premium (nicht Core)
KonformitätsbestimmungKlausel 5Nicht von NextPDF durchgeführt — veraPDFAusdrückliche Nichtabdeckung

Support ist nicht Konformität — und diese Seite trennt beides bewusst. (a) NextPDF Core gibt die Strukturen aus, die ISO 19005-4:2020 §6.7.3 für die Variantenidentifikation definiert — das ist Implementierung, belegt durch tests/Unit/Conformance/ConformanceModePdfAVariantTest.php (bestanden). (b) Dass eine Datei PDF/A-4-konform ist, ist eine separate Aussage, die gemäß ISO 19005-4:2020 Klausel 5 nur ein Validator treffen kann. Klausel 5 legt fest, dass die tatsächliche Konformitätsbestimmung anhand der normativen Anforderungen durch ein Prüfwerkzeug erfolgt. NextPDF beansprucht (a). NextPDF beansprucht (b) nicht. Validieren Sie mit veraPDF (verapdf --flavour 4 … oder php oracle/run.php für das Oracle-Harness — es läuft nur, wenn die veraPDF-Binary vorhanden ist, also hinter einem Opt-in-Gate).

Die Formulierungen „PDF/A-4 compliant“, „fully conformant“ und „PDF/A-4 certified“ werden auf dieser Seite bewusst nicht verwendet. NextPDF gibt PDF/A-4-relevante Strukturen aus; es garantiert keine konforme Datei.

Die Zitate sind aus dem Compliance-Korpus von NextPDF paraphrasiert. Die vollständigen 64-Zeichen-reference_id-Digests sind im Front-Matter der Seite und in docs/public/modules/core/_normative-evidence-conf.md festgehalten.