HotPDF skriver native PDF 2.0-dokumenter fra Delphi og C++Builder, herunder de tre PDF/A-4-arkiv-profiler og PDF/UA-2-tilgængeligt output med navnerums-belagte struktur-elementer. At vælge dem er et spørgsmål om to egenskaber, men standarderne bag disse egenskaber ændrede sig mere, end versionsnummeret antyder: PDF/A-4 droppede de conformance-bogstaver, alle lærte med PDF/A-2, og PDF/UA-2 introducerede struktur-navnerum, som et del 1-dokument aldrig havde
Denne artikel dækker, hvad der reelt ændrer sig i den genererede fil, og hvilke fejl HotPDF forvandler til en exception ved EndDoc frem for til et dokument, der fejler validering hos kunden
Hvordan adskiller PDF/A-4-identifikation sig fra del 2 og 3?
PDF/A-4 identificerer sig selv ved del-nummer og revisionsår, uden conformance-bogstav for basis-delen. Sæt PDFACompliance til '4', og HotPDF emitterer pdfaid:part=4 med pdfaid:rev=2020 og slet ingen pdfaid:conformance-post. Bogstavet forsvandt ikke — del 4 har ingen A/B/U-niveauer, fordi de krav, der plejede at adskille dem, blev foldet ind i basis-delen
To udvidelser bevarer et bogstav. '4E' vælger PDF/A-4e til ingeniør-dokumenter og emitterer conformance E, som tillader de 3D- og RichMedia-annotationsstier, de andre profiler forbyder. '4F' vælger PDF/A-4f og emitterer conformance F, som tillader en indlejret fil i ethvert format. Alle tre gennemtvinger en PDF 2.0-header, kræver de sædvanlige PDF/A-output-intent- og metadata-tjek og forbyder kryptering — en krypteret arkivfil er en selvmodsigelse, standarden ikke underholder
var
Pdf: THotPDF;
begin
Pdf := THotPDF.Create(nil);
try
Pdf.FileName := 'invoice-archive.pdf';
Pdf.PDFACompliance := '4F'; // PDF/A-4f: associated files of any format
Pdf.BeginDoc;
Pdf.CurrentPage.SetFont('Arial', [], 11);
Pdf.CurrentPage.TextOut(50, 760, 0, 'Invoice 2026-0731');
Pdf.AddPDFAssociatedFile('invoice.xml', 'text/xml',
'Structured invoice data', 'Data', LoadInvoiceBytes);
Pdf.EndDoc;
finally
Pdf.Free;
end;
end;AddPDFAssociatedFile indlejrer filen, bygger dens FileSpec med en /AFRelationship, og registrerer den i både katalogets /AF-array og EmbeddedFiles-navnetræet. Begge registreringer er påkrævede; en fil, der kun er opført i den ene, er den enkelt mest almindelige årsag til, at en hybrid faktura består et hurtigt øje-tjek og fejler en rigtig validator. Relations-strengen accepterer Source, Data, Alternative, Supplement eller Unspecified, og den aktive profil skal være PDF/A-3, PDF/A-4e eller PDF/A-4f — basis-del 4-profilen admit-ter ikke tilknyttede filer. Det ældre AddPDFA3AssociatedFile-navn virker stadig for eksisterende kode
Hvad kræver PDF/UA-2, som PDF/UA-1 ikke gjorde?
PDF/UA-2 gennemtvinger PDF 2.0 og emitterer pdfuaid:part=2 med pdfuaid:rev=2024, og den introducerer navnerum i strukturtræet. Et del 1-dokument havde ét fladt ordforråd af standard-roller. Et del 2-dokument kan bære tilpassede roller, så længe hver enkelt tilhører et erklæret navnerum, hvilket er det, der gør domæne-specifik mærkning læsbar for hjælpemidler i stedet for gættet
To metoder implementerer dette. RegisterStructureNamespace opretter eller genbruger en indirekte /Type /Namespace-dictionary og opfører den i StructTreeRoot /Namespaces, og returnerer dictionary'en, så du kan genbruge den. AddStructureElementNS opretter et struktur-element, hvis /NS-post peger på den dictionary, hvilket er det, der licenserer et rolle-navn uden for standard-sættet. Gentagne kald med samme URI genbruger én dictionary frem for at dynge dubletter op
var
Root: THPDFDictionaryObject;
begin
Pdf.PDFUACompliance := True;
Pdf.PDFUAPart := 2; // part 2 forces PDF 2.0
Pdf.Lang := 'en-US';
Pdf.BeginDoc;
Root := Pdf.AddStructureElement('Document', nil);
Pdf.AddStructureElementNS('WidgetGroup',
'https://example.com/ns/widgets', Root);
Pdf.EndDoc;
end;Lang er ikke dekoration her. Et tagget dokument uden erklæret naturligt sprog efterlader en skærmlæser gættende på udtale, og PDF/UA behandler udeladelsen som en fejl frem for en præference
Hvilke struktur-fejl fanger EndDoc?
Fire, og hver svarer til et dokument, der ellers ville nå en validator brudt. Struktur-roden skal indeholde præcis ét top-niveau Document-element. Hver navnerums-dictionary skal være indirekte, type-mærket som Namespace og bære en unik ikke-tom URI. Hver struktur-elements /NS-reference skal resolve til en dictionary, der reelt er opført i rod-/Namespaces-arrayet. Og en rolle uden navnerum skal være en PDF 2.0-standard-rolle eller resolve gennem RoleMap
Disse affyres ved EndDoc, fordi det er det sidste øjeblik, hele træet eksisterer i hukommelsen, og det første øjeblik, det er komplet. At fange dem tidligere ville betyde at afvise gyldige mellemtilstande; at fange dem senere ville betyde slet ikke at fange dem. Den praktiske konsekvens for din kode er, at en struktur-fejl dukker op ved slutningen af genereringen med en besked, der navngiver problemet, i stedet for at dukke op uger senere som en veraPDF-rapport, nogen videresender fra en kunde
PDF 2.0-rollerne det kan betale sig at kende
Den type-belagte rolle-enum får DocumentFragment, Aside, Title, FENote, Sub, Em, Strong og Artifact. Tre af dem ændrer, hvordan du mærker almindelige forretningsdokumenter. Aside giver endelig sidemarger og pull-quotes et hjem, der ikke er et misbrugt Sect. FENote markerer fodnoter og slutnoter som det, de er, så en læser kan tilbyde dem frem for at interleave dem med brødtekst. Em og Strong erstatter den semantiske gætterier, der kom fra at mærke fremhævning som span-niveau-formatering
String-overloaden accepterer ydermere den åbne Hn-form, herunder H7 og derudover. PDF 1.7 stoppede ved H6, hvilket tvang dybe tekniske dokumenter til at flade deres outline ud eller genbruge niveauer. Genererer du standard-dokumenter, juridiske kodekser eller dele-kataloger, kan det alene være grunden til at flytte output til PDF 2.0
Hvad skal tjekkes før skift af produktions-output?
PDF 2.0 er en header-ændring med en lang hale. Ældre arkiv-indtagelses-værktøjer, visse tryk-RIP'er og et overraskende antal line-of-business-fremvisere accepterer kun op til PDF 1.7, og de fejler på headeren frem for på noget, du gjorde forkert. Før du skifter, så bekræft de forbrugende systemer, og husk at vælge en PDF/A-4-profil vælger PDF 2.0, uanset om du bad om det eller ej
En sikker rækkefølge er at bevare PDF/A-3 til dokumenter, der går udad til ukendte læsere, bruge PDF/A-4f til interne arkiver, hvor du kontrollerer indtagelsen, og adoptere PDF/UA-2 kun, hvor tilgængelighedspolitikken navngiver den. Arbejder du dig gennem arkiv-siden først, dækker vejledningerne til PDF/A-, PDF/X- og PDF/UA-validering og til ZUGFeRD- og Factur-X-hybridfakturaer på PDF/A-3 de profil-valg, der betyder noget, før versionsnummeret gør, og noterne om automatiseret preflight-rapportering viser, hvordan man gør dommen til del af dit build frem for et manuelt skridt
HotPDF shipper hele PDF 2.0-forfatter-fladen som native VCL-kode til Delphi og C++Builder, så PDF/A-4- og PDF/UA-2-output ikke kræver nogen ekstern motor eller redistributable — HotPDF-komponent-siden opfører de understøttede profiler og RAD Studio-versioner