PDFium Component validoi ISO 19005-1 Annex C -toteutusrajoitukset — 127-tavuiset nimet, 8191 taulukon alkiota, 4095 sanakirjamerkintää ja 28 säiliön sisäkkäisyyden tasoa — ja raportoi symbolisen TrueType-fontin joka kantaa /Encoding-merkinnän. molemmat tarkistukset ajetaan tavusikennypolulla, joten Delphi- tai Lazarus-sovellus saa tuomion lataamatta PDFium-DLL:ää lainkaan
Nämä ovat virheet jotka puzzleavat ihmisiä eniten, koska asiakirja näyttää oikealta. Se renderöityy, se tulostuu, jokainen fontti on upotettu, tulostustarkoitus on läsnä. Sitten validaattori hylkää sen sanakirjan jokailla 4096 merkintää, eikä mikään näkyvässä asiakirjassa selitä miksi
Mitä Annex C -rajat oikein suojelevat?
Yhteensopivuutta toteutusten kanssa jotka edelsivät tuottajaasi. Annex C vie PDF Reference -toteutusrajat jokaiseen PDF/A-osan, ja numerot eivät ole mielivaltaisia — ne kuvaavat mitä vaatimustenvastaisen lukijan historiallisesti vaadittiin käsittelevän. Tiedosto joka ylittää ne voi avautua täydellisesti modernissa katselimessa ja epäonnistua arkistolukijassa jonka asiakirjajärjestelmä standardoi viisitoista vuotta sitten, mikä on juuri skenaario jonka PDF/A on olemassa estämään
Neljä rajaa ovat sisältyviä. Tasmalleen 127 tavun nimetoken validoituu; 128 ei. Taulukko jolla on tasan 8191 alkiota validoituu; 8192 ei. PDFium Component kiinnittää molemmat puolet jokaisesta rajasta testisarjassaan siksi, koska yksi-pois-rakenne rajatarkistuksessa tuottaa pahimmanlaisen validaattorin: sellaisen joka hylkää vaatimustenvastaisia tiedostoja ja johon kuitenkin luotetaan
uses FPdfPdfa;
var
Src: TFileStream;
Res: TPdfAValidationResult;
begin
Src := TFileStream.Create('archive.pdf', fmOpenRead or fmShareDenyWrite);
try
Res := ValidatePdfACompliance(Src);
if pvaiArrayOverLimit in Res.Issues then
Memo1.Lines.Add('An array carries more than 8191 elements');
if pvaiDictOverLimit in Res.Issues then
Memo1.Lines.Add('A dictionary carries more than 4095 entries');
if pvaiNestingOverLimit in Res.Issues then
Memo1.Lines.Add('Containers nest deeper than 28 levels');
if pvaiNameOverLimit in Res.Issues then
Memo1.Lines.Add('A name token is longer than 127 bytes');
finally
Src.Free;
end;
end;Mitkä tuottajat oikeasti osuvat näihin rajoihin?
Ne jotka rakentavat rakenteen ohjelmallisesti, mikä on useimman liiketoimintatulosteen laita. Lomake jolla on useita tuhansia kenttiä tuottaa /Annots-taulukon tai AcroFormin /Fields-taulukon joka kasvaa yli 8191:n. Sivu jonka resurssisanakirja kerää yhden merkinnän per tuotettu kuva tai fontti-instanssi ylittää 4095. Syvälle tuotetut rakennepuut — tunnistettu asiakirja joka rakennettiin rekursion yli sisäkkäisen datamallin — kävelevät ohi 28 tasosta kenenkään huomaamatta, koska kukaan ei katso sisäkkäissyysyyssyvyyttä
Pitkät nimet tulevat eri tavasta: datan koodaaminen nimetokeneiksi. Väriaineen nimi joka rakennettiin asiakastunnisteesta, valinnaisen sisällön ryhmä joka nimettiin koko tiedostopolun mukaan, lomakekenttä jonka täysin pätevä nimi yhdistää kuusi hierarkiatasoa. Nimet ovat halpoja tuottaa ja helppoja tehdä pitkiksi, ja 127 tavua katoaa nopeammin kuin odottaisit kun UTF-8-koodattu nimike on mukana
Korjaus on rakenteellinen joka tapauksessa. Jaa taulukko, jaa sanakirja, litistä sisäkkäisyyys, lyhennä nimi — eskelennussuositus kullekin ongelmalle nimee konkreettisen rajan sen sijaan että se kertoisi tiedoston olevan virheellinen. Merkki-injektio ei voi auttaa tässä: nämä eivät ole metatietovaatimuksia, ne ovat oliografian muoto
Miksi symbolinen TrueType-fontti ei saa kantaa /Encoding:iä
Koska ISO 19005-1 §6.3.7 hyväksyy symbolisille TrueType-fonteille vain fontin sisäänrakennetun cmapin, ja /Encoding-merkintä vastustaisi sitä. Symbolinen fontti kartoittaa koodit glyfeiksi omilla ehdoillaan — se on sitä mitä symbolinen tarkoittaa. Lisää koodaustaulu ja nyt on kaksi vastausta kysymykseen "minkä glyfin tavu 0x41 valitsee", ilman sääntöä tiedostossa joka sanoisi kumpi voittaa. Eri lukijat ratkaisevat sen eri tavalla, ja asiakirja joka renderöityy tekstinä yhdessä katselimessa renderöityy dingbatteina toisessa
PDFium Component lukee symbolisen lipun /FontDescriptor:istä riippumatta siitä onko kuvain kirjoitettu sisään fonttisanakirjassa vai viitattu epäsuorasti. Ei-symbolinen TrueType-fontti pitää vaaditun /WinAnsiEncoding:nsä tai /MacRomanEncoding:nsä ilman että sitä lippaistaan, koska ei-symbolisille fonteille koodaus on juuri sitä mitä standardi pyytää. Tarkistus syttyy ristiriidasta, ei koodauksen läsnäolosta
if pvaiSymbolicTrueTypeEncoding in Res.Issues then
Memo1.Lines.Add(
'A symbolic TrueType font carries /Encoding; PDF/A admits only its ' +
'built-in cmap (ISO 19005-1 6.3.7)');Tämän vian käytännön lähde on sellaisen tuottajan tekemä fonttiosajoukistoistaminen joka kohtelee joka TrueType-fonttia samalla tavalla. Symbol, Wingdings, viivakoodifontit ja ikonifontit ovat tavalliset kantajat — juuri ne fontit joita liiketoiminta-asiakirja käyttää valintaruuduille, logoille ja viivakoodeille, ja juuri ne joita kukaan ei tarkista uudelleen kun asiakirja epäonnistuu validoinnissa "fonttien" takia
Miten ongelmat saapuvat eskelennusraporttiin
Neljä säiliörajaa on luokiteltu rakenteen alle; symbolisen TrueType-koodauksen ongelma on luokiteltu sisällön alle. Tuo jakauma merkitsee kun raportti menee kahdelle eri ihmiselle: rakenne-löydökset kuuluvat yleensä sille joka kirjoitti tuottajan, ja sisältö-löydökset kuuluvat yleensä sille joka toimitti omaisuudet
Jokainen ongelma kantaa suosituksen joka nimeää korjaauksen konkreettisesti — lyhennä nimetokenit 127 tavuun tai vähempään, jaa taulukot niin ettei yksikään kanna enempää kuin 8191 alkiota, poista /Encoding symbolisista TrueType-fonteista. Raportti joka sanoo "ei PDF/A-vaatimustenvastainen" aloittaa tutkinnan. Raportti joka sanoo mikä raja ylitettiin ja millä päätää sen
Validointi ilman DLL:ää ja miksi se merkitsee tässä
Kaikki yllä olevat tarkistukset ajetaan tiedostotavuja vasten, joten ne toimivat palvelussa johon ei ole otettu PDFium-binääriä, rakennusaskeleessa, tai koneella jossa natiivin DLL:n lataaminen on käytäntöongelma. Tuo on tahallaan valittu PDFium Componentin suunnittelulinja: tarkistukset jotka voidaan vastata rakenteesta vastataan rakenteesta, ja DLL varataan niille jotka aidosti tarvitsevat renderöintimoottorin
Ympäröivää työnkulkua varten — validoinnin ajaminen kansion yli, raporttien tuottaminen ja sen päättäminen mitä löydöksille tehdään — katso artikkelit PDF/A-eskelennusvalidointi Delphissä ja erä-eskelennusraportin CLI. Arkistointiprofiilin valintaa varten joka istuu kaikkien näiden tarkistusten yläpuolella, muistiinpanot PDF/A-arkistointivaatimustenvastaisuus käsittelevät mihin osaan ja tasoon tähtäää ennen kuin aloitat löydösten korjaamisen
PDFium Component kietoo PDFium-moottorin Delphille, C++Builderille ja Lazarukselle korkean tason VCL-API:n ja joukon vaatimustenvastaisuusvalidaattoreiden kanssa jotka pyörivät DLL:n kanssa tai ilman — katso PDFium Component -tuotesivulta tuetut standardit ja alustat