A HotPDF natív PDF 2.0 dokumentumokat ír Delphiből és C++Builderből, beleértve a három PDF/A-4 archív profilt és a PDF/UA-2 akadálymentes kimenetet névtérkezelt szerkezeti elemekkel. Kiválasztásuk két tulajdonság kérdése, de a tulajdonságok mögötti szabványok többet változtak, mint amennyit a verziószám sugall: a PDF/A-4 elhagyta azokat a megfelelőségi betűket, amelyeket mindenki a PDF/A-2-vel tanult meg, és a PDF/UA-2 szerkezeti névtereket vezetett be, amelyek egy 1-es részű dokumentumnak sosem voltak
Ez a cikk azt tárgyalja, mi változik valójában a generált fájlban, és mely hibákat a HotPDF kivétellé alakítja EndDoc-nál, ahelyett hogy olyan dokumentumot eredményezne, amely az ügyfél telephelyén bukik meg a validáción
Miben különbözik a PDF/A-4 azonosítás a 2-es és 3-as résztől
A PDF/A-4 részszámmal és revíziós évvel azonosítja magát, az alaprésznél nincs megfelelőségi betű. Állítsuk a PDFACompliance-t '4'-re, és a HotPDF a pdfaid:part=4-et bocsátja ki pdfaid:rev=2020-szal és egyáltalán nem pdfaid:conformance bejegyzéssel. A betű nem veszett el — a 4-es résznek nincsenek A/B/U szintjei, mert a korábban elválasztó követelményeket az alaprészbe olvasztották
Két kiterjesztés megtart egy betűt. A '4E' a PDF/A-4e-t választja műszaki dokumentumokhoz, és E-megfelelőséget bocsát ki, amely megengedi a 3D- és RichMedia-jegyzetútvonalakat, amelyeket a többi profil tilt. A '4F' a PDF/A-4f-et választja, és F-megfelelőséget bocsát ki, amely bármilyen formátumú beágyazott fájlt megenged. Mindhárom PDF 2.0 fejlécet kényszerít, megköveteli a szokásos PDF/A kimeneti szándék és metaadat-ellenőrzéseket, és tiltja a titkosítást — egy titkosított archív fájl olyan ellentmondás, amellyel a szabvány nem foglalkozik
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;Az AddPDFAssociatedFile beágyazza a fájlt, felépíti a FileSpec-jét egy /AFRelationship-szel, és regisztrálja egyrészt a katalógus /AF tömbjében, másrészt az EmbeddedFiles névfában. Mindkét regisztráció kötelező; egy olyan fájl, amely csak az egyikben szerepel, a leggyakoribb oka annak, hogy egy hibrid számla átment egy gyors szemrevételezéses ellenőrzésen, és megbukik egy valódi validátoron. A kapcsolati karakterlánc elfogad Source, Data, Alternative, Supplement vagy Unspecified értéket, és az aktív profilnak PDF/A-3, PDF/A-4e vagy PDF/A-4f kell lennie — az alap 4-es profil nem engedélyez társított fájlokat. A régebbi AddPDFA3AssociatedFile név meglévő kódhoz továbbra is működik
Mit követel a PDF/UA-2, amit a PDF/UA-1 nem tett?
A PDF/UA-2 kikényszeríti a PDF 2.0-t, és pdfuaid:part=2-t bocsát ki pdfuaid:rev=2024-szel, és névtereket vezet be a szerkezeti fába. Egy 1-es részű dokumentum a szabványos szerepek egyetlen sík szókincsével rendelkezett. Egy 2-es részű dokumentum hordozhat egyéni szerepeket, amennyiben mindegyik egy deklarált névtérhez tartozik, ami teszi, hogy a tartományspecifikus jelölés a segítő technológia számára olvasható legyen, nem találgatás
Két metódus valósítja meg ezt. A RegisterStructureNamespace létrehoz vagy újrahasznál egy indirekt /Type /Namespace szótárt, és felsorolja a StructTreeRoot /Namespaces-ben, visszatérve a szótárral, hogy újra felhasználhassuk. Az AddStructureElementNS létrehoz egy szerkezeti elemet, amelynek /NS bejegyzése arra a szótárra mutat, ami engedélyezi egy szerepnév használatát a szabványos halmazon kívül. Az azonos URI-val történő ismételt hívások egy szótárt használnak újra, ahelyett hogy duplikációkat halmoznának fel
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;A Lang nem dekoráció itt. Egy olyan tagged dokumentum, amely nem deklarál természetes nyelvet, a képernyőolvasót kiejtési találgatásra kényszeríti, és a PDF/UA a kihagyást hibaként kezeli, nem preferenciaként
Mely szerkezeti hibákat kapja el az EndDoc?
Négyet, és mindegyik egy olyan dokumentumnak felel meg, amely egyébként hibásan jutna el egy validátorhoz. A szerkezeti gyökér pontosan egy felső szintű Document elemet tartalmaz. Minden névtérszótárnak indirektnek kell lennie, Namespace típusúnak, és egyedi nem üres URI-t kell hordoznia. Minden szerkezeti elem /NS hivatkozásának fel kell oldódnia egy olyan szótárra, amely valóban fel van sorolva a gyökér /Namespaces tömbjében. És egy nem névtérkezelt szerepnek PDF 2.0 szabványos szerepnek kell lennie, vagy a RoleMap-en át fel kell oldódnia
Ezek az EndDoc-nál sülnek el, mert az az utolsó pillanat, amikor a teljes fa létezik a memóriában, és az első, amikor teljes. Korábbi elkapásuk érvényes közbenső állapotok elutasítását jelentené; későbbi azt, hogy egyáltalán nem kapják el őket. A kódunkra vonatkozó gyakori következmény az, hogy egy szerkezeti hiba a generálás végén, a problémát megnevezve jelenik meg, ahelyett hogy hetekkel később egy veraPDF-jelentésként felszínre kerülne, amelyet valaki egy ügyféltől továbbít
A PDF 2.0 szerepek, amelyeket érdemes ismerni
A típusos szerep-enum megkapja a DocumentFragment, Aside, Title, FENote, Sub, Em, Strong és Artifact elemeket. Ezek közül három megváltoztatja, hogyan jelöljük a mindennapi üzleti dokumentumokat. Az Aside végre otthont ad az oldalsávoknak és a kiemelt idézeteknek, amelyek nem egy rosszul használt Sect. A FENote lábjegyzeteket és végjegyzeteket annak nevezi el, amik, így egy olvasó felkínálhatja őket ahelyett, hogy a törzsszövegbe foltozná. Az Em és Strong lecseréli azt a szemantikai találgatást, amely a hangsúly span-szintű formázásként való jelöléséből fakadt
A karakterlánc-túlterhelés emellett elfogadja a nyílt Hn formát, beleértve a H7-et és tovább. A PDF 1.7 a H6-nál állt meg, ami a mély műszaki dokumentumokat a vázlataik laposítására vagy a szintek újrahasználatára kényszerítette. Ha szabványdokumentumokat, jogi kódexeket vagy alkatrészkatalógusokat generálunk, ez önmagában lehet az oka a kimenet PDF 2.0-ra történő átállításának
Mit ellenőrizzünk a termelési kimenet átállítása előtt
A PDF 2.0 egy fejléc-változás hosszú farokkal. A régebbi archívum-betöltő eszközök, egyes nyomdai RIP-ek és meglepő számú üzleti megjelenítő csak PDF 1.7-ig terjedő tartományt fogad el, és a fejlécen buknak meg, nem valamin, amit rosszul tettünk. Átállítás előtt erősítsük meg a fogyasztó rendszereket, és ne felejtsük, hogy egy PDF/A-4 profil kiválasztása PDF 2.0-t választ, akár kértük, akár nem
Biztonságos sorrend: tartsuk a PDF/A-3-at az olyan dokumentumoknál, amelyek ismeretlen olvasók felé tartanak kifelé, használjuk a PDF/A-4f-et belső archívumhoz, ahol a betöltést mi ellenőrizzük, és vegyük fel a PDF/UA-2-t csak ott, ahol az akadálymentességi házirend megnevezi. Ha először az archív oldalon dolgozunk, a PDF/A, PDF/X és PDF/UA validáció és a ZUGFeRD és Factur-X hibrid számlák PDF/A-3-on útmutatói azokat a profilválasztásokat tárgyalják, amelyek a verziószám előtt számítanak, az automatizált preflight-jelentések jegyzetei pedig megmutatják, hogyan tegyük az ítéletet a build részevé, nem pedig manuális lépéssé
A HotPDF a teljes PDF 2.0 szerzői felületet natív VCL kódként szállítja Delphihez és C++Builderhez, így a PDF/A-4 és PDF/UA-2 kimenethez nincs szükség külső motorra vagy újraterjeszthető állományra — a HotPDF komponens oldal felsorolja a támogatott profilokat és RAD Studio verziókat