HotPDF skriver PDF 2.0-dokumenter i ren form fra Delphi og C++Builder, inkludert de tre PDF/A-4-arkivprofilene og PDF/UA-2-tilgjengelig utdata med navneroms-bestrukturelementer. Å velge dem er et spørsmål om to egenskaper, men standardene bak de egenskapene endret seg mer enn versjonsnummeret antyder: PDF/A-4 droppet konformansbokstavene alle lærte med PDF/A-2, og PDF/UA-2 innførte struktur-navnerom som et del-1-dokument aldri hadde
Denne artikkelen dekker hva som faktisk endres i den genererte filen, og hvilke feil HotPDF gjør om til et unntak ved EndDoc snarere enn til et dokument som feiler validering hos kunden
Hvordan PDF/A-4-identifikasjon skiller seg fra del 2 og 3
PDF/A-4 identifiserer seg ved delenummer og revisjonsår, uten konformansbokstav for basisdelen. Sett PDFACompliance til '4' og HotPDF sender ut pdfaid:part=4 med pdfaid:rev=2020 og ingen pdfaid:conformance-oppføring i det hele tatt. Bokstaven forsvant ikke — del 4 har ingen A/B/U-nivåer, fordi kravene som pleide å skille dem ble brettet inn i basisdelen
To utvidelser beholder en bokstav. '4E' velger PDF/A-4e for ingeniørdokumenter og sender ut konformans E, som tillater 3D- og RichMedia-annotasjonsstiene de andre profilene forbyr. '4F' velger PDF/A-4f og sender ut konformans F, som tillater en innebygd fil i ethvert format. Alle tre fremtvinger en PDF 2.0-header, krever de vanlige PDF/A-utdata-intent- og metadata-sjekkene, og forbyr kryptering — en kryptert arkivfil er en selvmotsigelse 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 bygger inn filen, bygger dens FileSpec med en /AFRelationship, og registrerer den i både Catalog /AF-arrayen og EmbeddedFiles-navnetreet. Begge registreringer kreves; en fil oppført i bare én av dem er den enkleste grunnen til at en hybrid faktura passerer en kjapp øyekast-sjekk og feiler en ekte validator. Relasjonsstrengen aksepterer Source, Data, Alternative, Supplement eller Unspecified, og den aktive profilen må være PDF/A-3, PDF/A-4e eller PDF/A-4f — basis del 4-profilen innrømmer ikke tilknyttede filer. Det eldre AddPDFA3AssociatedFile-navnet virker fortsatt for eksisterende kode
Hva PDF/UA-2 ber om som PDF/UA-1 ikke gjorde
PDF/UA-2 fremtvinger PDF 2.0 og sender ut pdfuaid:part=2 med pdfuaid:rev=2024, og den innfører navnerom i strukturtreet. Et del-1-dokument hadde ett flatt vokabular av standardroller. Et del-2-dokument kan bære egendefinerte roller så lenge hver tilhører et erklært navnerom, noe som er det som gjør domene-spesifikk merking lesbar for assistiv teknologi i stedet for gjetting
To metoder implementerer dette. RegisterStructureNamespace oppretter eller gjenbruker en indirekte /Type /Namespace-ordbok og lister den i StructTreeRoot /Namespaces, og returnerer ordboken slik at du kan gjenbruke den. AddStructureElementNS oppretter et struktur-element hvis /NS-oppføring peker på den ordboken, noe som er det som lisensierer et rollenavn utenfor standardsettet. Gjentatte kall med samme URI gjenbruker én ordbok i stedet for å hope opp duplikater
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 dekorasjon her. Et merket dokument uten noe erklært naturlig språk etterlater en skjermleser i gjetting om uttale, og PDF/UA behandler utelatelsen som en defekt snarere enn en preferanse
Hvilke strukturfeil fanger EndDoc?
Fire, og hver tilsvarer et dokument som ellers ville nå en validator ødelagt. Strukture-roten må inneholde nøyaktig ett toppnivå-Document-element. Hver navneromsordbok må være indirekte, typet som Namespace, og bære en unik ikke-tom URI. Hver struktur-elements /NS-referanse må løse seg til en ordbok faktisk oppført i rotens /Namespaces-array. Og en rolle uten navnerom må være en PDF 2.0-standardrolle eller løse seg gjennom RoleMap
Disse fyres ved EndDoc fordi det er det siste øyeblikket hele treet finnes i minne og det første øyeblikket det er komplett. Å fange dem tidligere ville bety å avvise gyldige mellomtilstander; å fange dem senere ville bety å ikke fange dem i det hele tatt. Den praktiske konsekvensen for koden din er at en strukturfeil dukker opp ved slutten av genereringen med en melding som navngir problemet, i stedet for å dukke opp uker senere som en veraPDF-rapport noen videresender fra en kunde
PDF 2.0-rollene det er verdt å kjenne til
Den typede rolle-enumen får DocumentFragment, Aside, Title, FENote, Sub, Em, Strong og Artifact. Tre av disse endrer hvordan du merker vanlige forretningsdokumenter. Aside gir endelig sidefelt og uthevde sitater et hjem som ikke er et misbrukt Sect. FENote markerer fotnoter og sluttnoter som det de er, slik at en leser kan tilby dem i stedet for å flette dem inn i brødtekst. Em og Strong erstatter den semantiske gjettingen som oppsto fra å merke utheving som spenn-nivå-formatering
Streng-overloaden aksepterer i tillegg den åpne Hn-formen, inkludert H7 og utover. PDF 1.7 stoppet ved H6, noe som tvang dype tekniske dokumenter til å flate ut disposisjonen sin eller gjenbruke nivåer. Hvis du genererer standard-dokumenter, juridiske kjelder eller delskataloger, kan dette alene være grunnen til å flytte utdata til PDF 2.0
Hva du bør sjekke før du bytter produksjonsutdata
PDF 2.0 er en header-endring med en lang hale. Eldre arkiv-inntaksverktøy, noen trykk-RIP-er og et overraskende antall forretningslesere aksepterer bare opptil PDF 1.7, og de feiler på headeren snarere enn på noe du gjorde feil. Før du bytter, bekreft de konsumerende systemene, og husk at å velge en PDF/A-4-profil velger PDF 2.0 enten du ba om det eller ikke
En trygg sekvens er å beholde PDF/A-3 for dokumenter som går utover til ukjente lesere, bruke PDF/A-4f for interne arkiver der du kontrollerer inntak, og ta i bruk PDF/UA-2 bare der tilgjengelighetspolicyen navngir den. Hvis du jobber deg gjennom arkivsiden først, dekker veiledningene til PDF/A-, PDF/X- og PDF/UA-validering og til ZUGFeRD- og Factur-X-hybridfakturaer på PDF/A-3 de profilvalgene som betyr noe før versjonsnummeret gjør det, og notatene om automatisert preflight-rapportering viser hvordan du gjør dommen til del av bygget ditt i stedet for et manuelt trinn
HotPDF leverer hele PDF 2.0-forfatterflaten som ren VCL-kode for Delphi og C++Builder, slik at PDF/A-4- og PDF/UA-2-utdata ikke trenger noen ekstern motor eller redistribuert pakke — HotPDF-komponentsiden lister de støttede profilene og RAD Studio-versjonene