PDF/A-, PDF/X- og PDF/UA-utdata i Delphi: En HotPDF-veiledning

PDF/A, PDF/X og PDF/UA er tre forskjellige standarder som løser tre forskjellige problemer: langtidsarkivering, trykkeriutveksling og tilgjengelighet. De er ikke tre avkrysningsbokser på ett samsvarsskjema, og den vanligste feilen er å behandle dem som om de var det. En fil kan være feilfri PDF/A og ubrukelig for et trykkeri; en perfekt trykkmaster kan være uleselig for en skjermleser. Verre er det at alle tre er begrensninger på filens interne struktur, ikke på hvordan den ser ut. Et dokument som åpner seg feilfritt i hver eneste viser du eier, kan likevel feile validering på første forsøk, og gjør som regel nettopp det

HotPDF, losLabs native VCL PDF-bibliotek, behandler samsvar som noe du erklærer før den første siden i det hele tatt finnes. Du setter en samsvarsegenskap, fester strukturene standarden krever, og biblioteket avviser konfigurasjoner som motsier profilen ved lagringstidspunktet. Det er en bedre modell enn å generere en fil og håpe at en etterbehandler kan ettermontere det, fordi det meste av det disse standardene krever, ikke kan legges til i etterkant

Tre ISO-standarder, tre forskjellige løfter

PDF/A (ISO 19005) handler om tid. Den lover at en fil fortsatt vil rendres identisk om flere tiår, så den krever full selvstendighet: hver skrift innebygd, hver farge gitt enhetsuavhengig betydning gjennom en OutputIntent, fullstendig XMP-metadata, og et forbud mot alt hvis atferd avhenger av miljøet. Kryptering og JavaScript er ute, fordi ingen kan garantere at dekrypteringsverktøyet eller skriptmotoren vil finnes i 2050

PDF/X (ISO 15930) handler om farge på papir. Den finnes slik at en designer kan overlevere en fil til et trykkeri uten at noen av dem trenger å diskutere den, noe som betyr karakteriserte trykkforhold, en obligatorisk /Trapped-nøkkel, definert beskjærings- og utfallsgeometri, og, i X-1a-varianten, ingen levende gjennomsiktighet for RIP-en å gjette på. PDF/UA (ISO 14289) handler om hvem som kan lese resultatet. Hjelpeteknologi trenger et komplett taggetre, en fornuftig leserekkefølge, et erklært dokumentspråk, og tekstalternativer for alt som ikke er tekst

Fordi de tre trekker i forskjellige retninger, bør du velge den styrende standarden per utdatakanal, i stedet for å jage én fil som tilfredsstiller alle tre. En rent CMYK-basert trykkmaster er nøyaktig det gale å gi en skjermleserbruker som aldri ser farge, og arkivprofilens nedlåsing av dynamisk atferd kolliderer med alt som er interaktivt. Generer per kanal fra de samme kildedataene, så unngår du hele konflikten

PDF/A: OutputIntent er delen alle glemmer

Hvis en PDF/A-fil feiler validering, er OutputIntent det første å sjekke. Det er strukturen generatorer hopper over oftest, nettopp fordi ingenting synlig avhenger av den. ISO 19005 krever én: en innebygd ICC-profil som fastslår hva dokumentets enhetsfarger faktisk betyr. HotPDF gjør denne profilen til en eksplisitt inndata i stedet for en ettertanke:

var
  Pdf: THotPDF;
  ICC: TFileStream;
begin
  Pdf := THotPDF.Create(nil);
  try
    Pdf.FileName := 'invoice-archival.pdf';
    Pdf.PDFACompliance := 'B';            // nivå B: visuell troskap
    Pdf.Lang := 'en-US';
    Pdf.StandardFontEmulation := False;   // bygg inn ekte skrifter, ingen Base-14-emulering
    ICC := TFileStream.Create('sRGB.icc', fmOpenRead);
    try
      Pdf.AddPDFAOutputIntent('sRGB IEC61966-2.1', '', ICC, 3, 'DeviceRGB');
    finally
      ICC.Free;
    end;
    Pdf.BeginDoc;
    Pdf.CurrentPage.SetFont('Arial', [], 11);
    Pdf.CurrentPage.TextOut(50, 760, 0, 'Archival invoice body');
    Pdf.EndDoc;
  finally
    Pdf.Free;
  end;
end;

Noen få detaljer avgjør bestått eller feilet her. StandardFontEmulation må være av: emulerte Base-14-skrifter blir ikke innebygd, og innebygging er ikke forhandlingsbart under ISO 19005. Kryptering må forbli avslått, så kombiner aldri PDFACompliance med ActivateProtection; en kryptert arkivfil er en motsigelse validatoren fanger opp umiddelbart. Komponentantallet i AddPDFAOutputIntent må stemme med profilen, som er 3 for en RGB-profil som sRGB IEC61966-2.1 og 4 for CMYK. HotPDF sporer bruk av DeviceRGB og DeviceCMYK mot den erklærte intensjonen mens den skriver, så en feilplassert CMYK-fylling i et RGB-intensjonsdokument blir til et rapportert problem i stedet for et stille ett

Én ting er verdt å si om ICC-profilen: behandle den som en versjonert distribusjonsartefakt, ikke en fil noen en gang dumpet på byggeserveren. Bytene dens bygges inn i hvert dokument du genererer, så en avkuttet eller korrupt profil forgifter stille en hel batch, og du oppdager det først ved valideringstidspunktet. Send den med installatøren din, registrer sjekksummen i kjøreloggen, og last den inn gjennom TFileStream-mønsteret vist ovenfor, slik at en manglende fil feiler høylytt under genereringen i stedet for stille ved arkivporten

PDF/X for trykk: Trapped, CMYK og trykkprofilen

Trykkmastere snur fargehistorien på hodet. Trykkeriet vil ha karakterisert CMYK, og standarden tvinger deg til å oppgi om trapping er brukt, selv når det ærlige svaret er at du ikke har peiling. /Trapped-nøkkelen er obligatorisk uansett:

Pdf.PDFXCompliance := 'X-1a';
Pdf.Trapped := 'Unknown';        // obligatorisk nøkkel under ISO 15930
ICC := TFileStream.Create('FOGRA39.icc', fmOpenRead);
try
  Pdf.AddPDFXOutputIntent('FOGRA39 (ISO 12647-2:2004)', '', ICC, 4, 'DeviceCMYK');
finally
  ICC.Free;
end;
Pdf.BeginDoc;
// tegn med CMYK-sikre farger, ingen gjennomsiktighet, ingen kryptering
Pdf.EndDoc;

Komponentantallet er nå 4 for CMYK-trykkprofilen. X-1a forbyr også levende gjennomsiktighet, så gjennomgå all tegnekode som lager lag av gjennomskinnelige elementer; alt en viser komponerer på skjermen, er nøyaktig det en RIP vil nekte å tolke. Når trykkeriet ditt sender en annen karakterisering, bytt ut profilbytene og identifikatorstrengen, men la den omkringliggende strukturen være urørt

PDF/UA: struktur genereres, aldri ettermonteres

Tilgjengelighet er standarden team oftest prøver å skru på i etterkant, og den straffer den tilnærmingen hardere enn de to andre. Taggetreet må gjenspeile rekkefølgen innholdet logisk ble skapt i, noe som er informasjon du rett og slett ikke lenger har når filen er skrevet. Å sette PDFUACompliance slår på tagget output, og struktur-API-et binder hvert tegnekall til sin semantiske rolle underveis:

Pdf.PDFUACompliance := True;     // slår automatisk på tagget PDF
Pdf.Lang := 'en-US';             // sett eksplisitt; tomt faller tilbake til 'en'
Pdf.BeginDoc;

Root := Pdf.AddStructureElement(sstDocument, nil);
H1 := Pdf.EmitTaggedHeading(1, Root, 50, 700, 'Quarterly Report');
Para := Pdf.BeginTaggedContent('P', Root);
Pdf.CurrentPage.TextOut(50, 650, 0, 'Revenue grew in all regions.');
Pdf.EndTaggedContent;

Pdf.EndDoc;

Feilen å se opp for, er tekst tegnet utenfor et hvilket som helst BeginTaggedContent/EndTaggedContent-par. Den rendres perfekt og forblir usynlig for en skjermleser, så ingen seende tester fanger den noensinne opp; feilen sendes ut og dukker først opp når en faktisk hjelpeteknologibruker treffer hullet. Når malene dine bærer egendefinerte strukturrollenavn, bør du kartlegge dem mot standardsettet med AddStructRoleMap('MyHead', 'H1'), slik at lovlydige lesere vet hva de betyr. ISO 14289 krever også et erklært språk. HotPDF faller tilbake til 'en' når Lang er tomt, men det er et sikkerhetsnett, ikke en grunn til å la det virkelige dokumentspråket stå usatt

Verifisering: stol på validatoren, ikke viseren

En viser som åpner filen din, beviser ingenting om samsvar, så verifisering hører hjemme i utgivelsesløpet med verktøy som sjekker struktur snarere enn rendring. For PDF/A og PDF/UA er veraPDF den referansegraderte åpne validatoren; den rapporterer feil etter ISO-klausul, noe som kartlegger seg rett tilbake til konfigurasjonen ovenfor. For PDF/X er Adobe Acrobats Preflight-profiler fortsatt den praktiske sjekken, fordi trykksamsvar handler like mye om fargeintensjon som om syntaks

Generatoren gjør sin egen del av dette. Ved lagringstidspunktet avstemmer HotPDF funksjonsflaggene mot den konfigurerte PDF-versjonen, og nedgraderer stille det versjonen ikke kan uttrykke, som AES-256 som faller til AES-128 under PDF 1.7. Samsvarsportene i EndDoc går lenger og kaster rett ut unntak ved harde motsigelser, som å be om PDFACompliance sammen med kryptering. Ingen av disse erstatter den eksterne validatoren. De hindrer bare umulige konfigurasjoner i noensinne å nå den

Én vane lønner seg gjentatte ganger: versjoner hele samsvarsoppsettet som én enhet. HotPDF-utgivelsen, malrevisjonen, ICC-profilsjekksummen, validator-buildet som godkjente det. Samsvaret driver i det øyeblikket en eneste av dem endres under de andre, og de styggeste revisjonene er de der ingen kan rekonstruere hvilken kombinasjon som produserte en fem år gammel arkivfil. Én enkelt konfigurasjonspost per batch ordner opp i det for godt

Til slutt: kjør validatoren på ekte produksjonsoutput, aldri på en ryddig håndbygget eksempelfil. Feilene som biter, kommer fra data ingen forutså: en kundelogo som kommer som CMYK mens intensjonen sier RGB, en malendring som sniker inn en ikke-innebygd skrift, en ny kodesti som tegner tekst utenfor taggetreet. Behold én kjent-dårlig fil fra hver tidligere hendelse som regresjonsinndata, så forblir samsvarsporten ærlig over tid. For rendringssiden av disse pipelinene, se artikkelen vår om rapportoutput, skrifter og bilder med HotPDF; for å koble validatorer inn i en build, finnes det et følgestykke om å automatisere PDF-preflight-sjekker

Samsvarsegenskapene, output intents og tagge-API-et brukt i disse eksemplene, følger med HotPDF Delphi Component for Delphi og C++Builder; produktsiden lenker til den fullstendige referansen for hvert kall vist her