HotPDF kirjoittaa natiiveja PDF 2.0 -asiakirjoja Delphistä ja C++Builderistä, mukaanlukien kolme PDF/A-4-arkistointiprofiilia ja PDF/UA-2-saavutettava tuloste nimiavaruudellisilla rakenneryhmillä. Niiden valitseminen on kahden ominaisuuden asia, mutta niiden ominaisuuksien takana olevat standardit muuttuivat enemmän kuin versionumero antaa ymmärtää: PDF/A-4 pudotti vaatimuskirjaimet jotka kaikki oppivat PDF/A-2:n kanssa, ja PDF/UA-2 esitteli rakennenimiavaruudet joita osa 1 -asiakirjalla ei koskaan ollut
Tämä artikkeli käsittelee mitä todella muuttuu tuotetussa tiedostossa, ja mitkä virheet HotPDF muuttaa poikkeukseksi EndDoc:ssä sen sijaan että niistä tulisi asiakirja joka epäonnistuu validoinnin asiakkaan luona
Miten PDF/A-4-tunnistautuminen eroaa osista 2 ja 3
PDF/A-4 tunnistaa itsensä osanumerolla ja julkaisuvuodella, ilman vaatimuskirjainta perusosalle. Aseta PDFACompliance:ksi '4' ja HotPDF emitoi pdfaid:part=4:n yhdessä pdfaid:rev=2020:n kanssa eikä lainkaan pdfaid:conformance-merkintää. Kirjain ei kadonnut — osalla 4 ei ole A/B/U-tasoja, koska vaatimukset jotka ennen erottivat ne on taitettu perusosaan
Kaksi laajennusta pitävät kirjaimen. '4E' valitsee PDF/A-4e:n insinööriasiakirjoille ja emitoi vaatimustason E, mikä sallii 3D- ja RichMedia-kommenttipolut jotka muut profiilit kieltävät. '4F' valitsee PDF/A-4f:n ja emitoi vaatimustason F, mikä sallii upotetun tiedoston missä tahansa muodossa. Kaikki kolme pakottavat PDF 2.0 -otsakkeen, vaativat tavalliset PDF/A-tulostustarkoitukset ja metatietotarkistukset, ja kieltävät salauksen — salattu arkistointitiedosto on ristiriita jota standardi ei edes harkitse
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 upottaa tiedoston, rakentaa sen FileSpecin /AFRelationship:n kanssa ja rekisteröi sen sekä Katalogin /AF-taulukkoon että EmbeddedFiles-nimipuuhun. molemmat rekisteröinnit ovat pakollisia; tiedosto joka on luetteloitu vain yhdessä on yksittäisin yleisin syy miksi hybridi-lasku läpäisee nopean silmävaraisen tarkistuksen ja epäonnistuu oikeassa validaattorissa. Suhde-merkkijono hyväksyy Source, Data, Alternative, Supplement tai Unspecified, ja aktiivisen profiilin on oltava PDF/A-3, PDF/A-4e tai PDF/A-4f — perusosan 4 profiili ei hyväksy liitettyjä tiedostoja. Vanhempi AddPDFA3AssociatedFile-nimi toimii yhä olemassa olevalle koodille
Mitä PDF/UA-2 vaatii mitä PDF/UA-1 ei vaatinut
PDF/UA-2 pakottaa PDF 2.0:n ja emitoi pdfuaid:part=2:n yhdessä pdfuaid:rev=2024:n kanssa, ja se tuo nimiavaruudet rakennepuuhun. Osa 1 -asiakirjalla oli yksi litteä standardiroolien sanasto. Osa 2 -asiakirja voi kantaa mukautettuja rooleja kunhan jokainen kuuluu julistettuun nimiavaruuteen, mikä on se mikä tekee alakohtaisesta tunnistuksesta luettavaa avustavalle teknologialle arvailun sijaan
Kaksi metodia toteuttaa tämän. RegisterStructureNamespace luo tai uudelleenkäyttää epäsuoran /Type /Namespace-sanakirjan ja luettelee sen StructTreeRoot /Namespaces:ssä, palauttaen sanakirjan niin että voit käyttää sitä uudelleen. AddStructureElementNS luo rakenneryhmän jonka /NS-merkintä osoittaa tuohon sanakirjaan, mikä on se mikä luvittaa roolinimen standardijoukon ulkopuolella. Toistuvat kutsut samalla URI:lla käyttävät yhden sanakirjan uudelleen dublikaattien kasaamisen sijaan
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 ei ole tässä koriste. Tunnistettu asiakirja jossa ei ole julistettua luonnollista kieltä jättää ruudunlukuohjelman arvailemaan ääntämystä, ja PDF/UA kohtelee puutetta vikana eikä mieltymyksenä
Mitä rakennevioita EndDoc ottaa kiinni?
Neljää, ja jokainen vastaa asiakirjaa joka muuten pääsisi validaattoriin rikkonaisena. Rakennejuuren on sisällettävä tasan yksi ylätason Document-ryhmä. Jokaisen nimiavaruussanakirjan on oltava epäsuora, tyypiltään Namespace, ja kannettava yksilöllinen ei-tyhjä URI. Jokaisen rakenneryhmän /NS-viittauksen on ratkauduttava sanakirjaan joka on todella luetteloitu juuren /Namespaces-taulukossa. Ja ilman-nimiavaruuden roolin on oltava PDF 2.0 -standardirooli tai ratkaistuttava RoleMapin läpi
Nämä syttyvät EndDoc:ssä koska se on viimeinen hetki jolloin koko puu on olemassa muistissa ja ensimmäinen hetki jolloin se on valmis. Niiden ottaminen kiinni aiemmin tarkoittaisi kelvollisten väitilojen hylkäämistä; myöhemmin se tarkoittaisi ettei niitä oteta kiinni lainkaan. Käytännön seuraus koodillesi on että rakennevika nousee esiin tuotannon lopussa viestillä joka nimeää ongelman, sen sijaan että se nousisi esiin viikkoja myöhemmin veraPDF-raporttina jonka joku välittää asiakkaalta
PDF 2.0 -roolit jotka kannattaa tuntea
Tyypitetty roolien enumeraatio saa lisäkseen DocumentFragment, Aside, Title, FENote, Sub, Em, Strong ja Artifact:n. Kolme näistä muuttaa sitä miten tunnistat tavallisia liiketoiminta-asiakirjoja. Aside antaa viimeinkin sivupalstoille ja lainauksille kodin joka ei ole väärinkäytetty Sect. FENote merkitsee alaviitteet ja loppuviitteet siksi mitä ne ovat, jolloin lukija voi tarjota niitä sen sijaan että se sotkisi ne leipätekstiin. Em ja Strong korvaavat semanttisen arvailun joka syntyi kun korostus tunnistettiin span-tason muotoiluksi
Merkkijonoylikuormitus hyväksyy lisäksi avoimen Hn-muodon, mukaanlukien H7:n ja pidemmälle. PDF 1.7 pysähtyi H6:een, mikä pakotti syvät tekniset asiakirjat litistämään jäsennyksensä tai käyttämään tasoja uudelleen. Jos tuotat standardiasiakirjoja, lakikoodeja tai osaluetteloita, tämä yksin voi olla syy siirtää tuloste PDF 2.0:een
Mitä tarkistaa ennen tuotantotulosteen vaihtamista
PDF 2.0 on otsakemuutos jolla on pitkä häntä. Vanhat arkistojen sisäänottotyökalut, jotkut paino-RIP:it ja yllättävän monet liiketoimintasovellusten katselimet hyväksyvät vain PDF 1.7:ään asti, ja ne kaatuvat otsakkeeseen eivätkä mihinkään mitä tekivät väärin. Ennen vaihtoa vahvista käyttävät järjestelmät, ja muista että PDF/A-4-profiilin valitseminen valitsee PDF 2.0:n pyysit sitä tai et
Turvallinen järjestys on pitää PDF/A-3 asiakirjoille jotka menevät ulos tuntemattomille lukijoille, käyttää PDF/A-4f:iä sisäisissä arkistoissa missä hallitset sisäänoton, ja ottaa PDF/UA-2 käyttöön vain missä saavutettavuuskäytäntö sen nimeää. Jos työskentelet ensin arkistointipuolta, oppaat PDF/A-, PDF/X- ja PDF/UA-validointi ja ZUGFeRD- ja Factur-X-hybridi-laskut PDF/A-3:ssa käsittelevät profiilivalintoja jotka merkitsevät ennen versionumeroa, ja muistiinpanot automatisoitu eskelennusraportointi näyttävät kuinka tehdä tuomiosta osa rakennettasi sen sijaan että se olisi manuaalinen askel
HotPDF toimittaa koko PDF 2.0 -luontialustan natiivina VCL-koodina Delphille ja C++Builderille, joten PDF/A-4- ja PDF/UA-2-tuloste eivät tarvitse ulkoista moottoria tai redistribuoitavaa — HotPDF-komponenttisivulta löytyy tuetut profiilit ja RAD Studio -versiot