PDF/A- ja PDF/UA-preflight Delphissä PDFlibPasilla

PDF/A ja PDF/UA vastaavat kahteen kysymykseen, joilla ei ole mitään tekemistä toistensa kanssa, ja niiden käsittäminen yhtenä saavutettavuus-ja-arkistointi -rastina on tapa, jolla rikkinäiset tiedostot päätyvät arkistoon compliance-nimikkeen kanssa. PDF/A kysyy, renderöityykö tiedosto yhä uskollisesti kahdenkymmenen vuoden päästä. PDF/UA kysyy, voiko avustava teknologia lukea sitä tänään. Dokumentti voi läpäistä toisen kylmästi ja kaatua toiseen, joten ainoa rehellinen tuomio tulee molempien ajamisesta, ja ajamisesta ennen tiedoston kirjoittamista ulos, ei sen jälkeen kun alavirran järjestelmä luottaa sen metadaan leivottuun conformance-tunnisteeseen. Tuo tunniste on itseilmoitus. Mikään formaatissa ei vaadi sitä todeksi, ja sovellus, joka kirjoittaa "PDF/A-1b":n XMP:hen validoimatta standardia vasten, tuottaa tiedoston, joka näyttää vaatimustenmukaiselta jokaiselta kuluttajalta, joka lukee vain nimikkeen. losLab PDF Library (PDF Library for Delphi) sulkee tuo kuilun Delphille ja C++Builderille rakentamalla molemmat validattorit kirjastoon, jotta tarkistus ajetaan prosessissa ilman ulkoista palvelua pystytettävaksi

Kaksi standardia, jotka kaatavat tiedostoja vastakkaisista syistä

ISO 19005 (PDF/A) on lisääntymissopimus. Vaatimustenmukaisen tiedoston on renderöidyttävä identtisesti vuosikymmeniä myöhemmin ohjelmistolla, joka ei koskaan nähnyt järjestelmää, joka sen tuotti, joten säännöt hyökkäävät ulkoisia riippuvuuksia vastaan: jokainen fontti upotettu, väri ankkuroitu upotettuun ICC OutputIntent -profiiliin tai ilmaistu laite-riippumattomassa avaruudessa, ei salausta PDF/A-1:ssä, ei JavaScriptiä, XMP-metada joka on samaa mieltä dokumentin tietosanakirjan kanssa. ISO 14289 (PDF/UA) sen sijaan on semantiikkasopimus. Avustavan teknologian on läpäistävä dokumentti ja tultava pois merkityksen kanssa, joka asuu kokonaan toisessa kerroksessa: täydellinen rakennepuu, vaihtoehtoinen teksti kuvissa, näyttöä varten asetettu dokumentin otsikko, otsikkotasot jotka eivät hyppää, taulukon otsikkosuhteet jotka säilyvät kun sivu on pois ruudulta

Koska kaksi standardia valvovat eri kerroksia, tiedostot, jotka purevat sinua, ovat niitä, jotka istuvat niiden välissä. Arkistotäydellinen dokumentti voi olla hiljainen ruudunlukuohjelmalle. Kauniisti tagitettu voi viitata työpöydän fonttiin, jota ei ole olemassa kymmenen vuoden päästä. Julkishallinnon julkaisu on tavallinen paikka, missä molemmat vaatimukset laskeutuvat kerralla, ja putki siellä ei voi romahdtaa niitä yhdeksi portiksi. Löydökset menevät eri ihmisille. Upottamattomat fontit ovat vika koodissa, joka tuottaa PDF:n, kun taas puuttuva vaihtoehtoinen teksti kuuluu kenelle tahansa, joka omistaa sisältömallit, ja raportti, joka sekoittaa nuo kaksi, vain välitetään kahdesti

Se, mihin PDF/A:n osaan tähtäät, merkitsee yhtä paljon kuin se, osuiko. PDF/A-1 on jäädytetty PDF 1.4:ään ja hylkää läpinäkyvyyden ja JPEG2000:n, molemmat joita moderni raportointituotos tavoittelee ajattelematta. PDF/A-2 (ISO 19005-2, rakennettu ISO 32000-1:n päälle) hyväksyy molemmat ja on järkevä oletus uudelle arkistolle. PDF/A-3 menee pidemmälle ja sallii minkä tahansa tyyppiset upotetut tiedostot, mikä on se, mihin säännellyt sähköisen laskutuksen formaatit nojaavat. Tiimi, joka yhä standardoituu PDF/A-1b:hen vuonna 2026, kantaa yleensä vaatimusta, jonka joku kirjoitti viisitoista vuotta sitten, ja tavoitteen osan uudelleenneuvottelu on usein halvempaa kuin läpinäkyvyyden riisuminen jokaisesta kaaviosta, jonka järjestelmä emittoi

Jäsennetyt löydökset sisäänoton aikaan

Flat-API-tulokohta on CheckFileCompliance, testin valitsimella 1 PDF/A:lle ja 2 PDF/UA:lle. Se palauttaa merkkijonoluettelokahvan, jonka kohteet ovat yksittäisiä löydöksiä, yksi per rivi, mikä on tarkalleen se muoto, jota automatisoitu portti haluaa kävellä:

function GateArchiveUpload(Pdf: TPDFlib; const FileName: string): Boolean;
var
  ListId, I: Integer;
begin
  ListId := Pdf.CheckFileCompliance(FileName, '', 1, 0);  // 1 = PDF/A
  if ListId = 0 then
  begin
    // 0 tarkoittaa "no findings" TAI "file unreadable" — erottele ennen kuin välität eteenpäin
    Result := Pdf.LastErrorCode = 0;
    Exit;
  end;
  for I := 0 to Pdf.GetStringListCount(ListId) - 1 do
    LogFinding(FileName, Pdf.GetStringListItem(ListId, I));
  Pdf.ReleaseStringList(ListId);
  Result := False;
end;

Kaksi yksityiskohtaa päättävät, ajautuuko tämä ilman valvontaa. Ensimmäinen on paluuarvo, joka tarkoittaa kahta vastakkaista asiaa. CheckFileCompliance palauttaa 0, kun tiedosto on täysin vaatimustenmukainen ja myös silloin kun tiedostoa ei voitu avata lainkaan, koska sisäisesti tyhjä tulosluettelo reducedoituu 0:ksi molemmissa tapauksissa. Portti, joka lukee 0:n läpipääsytä, päästää korruptoituneet lataukset suoraan arkistoon, joten disambiguaa LastErrorCode:n avulla ennen kuin luotat nollaan, kuten portti yllä tekee. Toinen koskee sitä, missä tiedosto on elinkaarellaan. Tarkistaja ajaa kirjaston suoratoistolukijalla täyden dokumenttimallin sijaan, avaten tiedoston suoraan lukujako-tilassa eikä koskaan kutsumalla LoadFromFile:a, mistä syystä se voi jauha monen gigatavun syötteen ilman objektipuun rakentamista. Tuo sama suoratoistoavaus epäonnistuu, kun toinen prosessi vielä pitää tiedostoa kirjoitusta varten, ja käynnissä oleva lataus on juuri tuo tila. Portittaa kun siirto on päättynyt

Suoratoistosuunnittelu maksaa itsensä takaisin kuormituksen alla. Jokainen tarkistus avaa syötteensä vain luku -tilassa ja jakaa sen lukua varten, joten joukko-auditointi skaalautuu työntekijäsäikeille tai prosesseille yhdellä TPDFlib-instanssilla per työntekijä ilman kilpailua niiden välillä. Resurssi, joka tarvitsee kuria, on kahva itse. Jokainen nollasta poikkeava tulos CheckFileCompliance:stä pysyy varattuna kunnes kutsut ReleaseStringList:ä, ja pitkäkestoinen portti, joka unohtaa vapauttaa ne, ei kaadu, se vain vuotaa muistia hitaasti kunnes joku lähtee etsimään syytä

Raportteja ihmisille, diffejä build-porteille

LöydösLuettelo on oikea muoto portille ja väärä muoto sähköpostille mallitiimille. CreatePreflightReport renderöi saman analyysin luettavana proosana, CreatePreflightReportEx lisää raporttiformaatin valitsimen, ja SavePreflightReport kirjoittaa sen levylle, jotta raportti voi matkustaa toimitetun dokumenttipaketin mukana. Paljon arkistosopimuksia tekevät tuosta raportista oman toimitettavansa, eivät vain sisäisen artefaktin

Tämän perheen jäsen, joka ansaitsee paikkansa hiljaa, on ComparePreflightReports. Vaatimustenmukaisuus on regressiopinta kuten mikä tahansa muu palanen käytöstä. Mallin viilaus, vastikään lisensoitu yritysfontti tai kirjastopäivitys voivat kukin tuoda löydöksen, jota ei ollut edellisessä julkaisussa, eikä yksikään niistä ilmoita itsestään. Pidä kultaiset raportit joukolle edustavia dokumentteja versionhallinnassa, regeneroi ne jokaisen muutoksen jälkeen, ja aja ComparePreflightReports laskeaksesi deltan. Tyhjä diff on julkaistu artefakti, jonka säilyttäminen kannattaa. Yllättävä löydös kaataa buildin, mikä on paljon halvempi paikka löytää se kuin auditointi

Tuotoksen generointi, joka läpäisee ensimmäisellä ajolla

Preflight ansaitsee pitonsa tiedostoissa, jotka saapuvat muualta. Dokumenteille, joita oma koodisi tuottaa, rikkomusten löytäminen generoinnin jälkeen ja niiden paikkaaminen takaisin on hidas tie. PDF Library for Delphi kantaa generointipuolen tilaa kullekin standardille, ja voit kytkeä molemmat päälle samalle dokumentille:

var
  Pdf: TPDFlib;
  Diag: WideString;
begin
  Pdf := TPDFlib.Create;
  try
    Pdf.NewDocument;
    Pdf.SetPDFAMode(1);
    Pdf.LoadOutputIntentProfile('sRGB-IEC61966-2.1.icc', 'RGB');
    Pdf.SetPDFUAMode('en-US');
    Pdf.SetInformation(1, 'Quarterly Statement');  // /Title: pakollinen PDF/UA:lle
    // ... piirrä tagattu sisältö tähän ...
    Diag := Pdf.GetPDFUADiagnostics;
    if Diag <> '' then
      Writeln('fix before shipping: ', Diag);
    Pdf.SaveToFile('statement.pdf');
    // varsinainen preflight suoritetaan tallennetulle tiedostolle:
    Writeln(Pdf.CreatePreflightReport('statement.pdf', '', 1, 0));
  finally
    Pdf.Free;
  end;
end;

Ansa piiloutuu tallennusaikaan. Useat vaatimustenmukaisuuskorjaukset tapahtuvat dokumenttia sarjallistettaessa ennemmin kuin kun kytket tilan päälle: tulostuslipun pakottaminen merkinnöille, oletus-AFRelationship:n kirjoittaminen PDF/A-3:n upotetuille tiedostoille, sarkainjärjestyksen ja lomakekentän kuvauksien normalisointi PDF/UA:ta varten. Muistissa oleva dokumentti ei ole tavu-identtinen sen kanssa, mikä laskeutuu levylle, joten ainoa preflight-tuomio, jolla on merkitystä, on se, joka lasketaan tallennetusta tiedostosta. Validoi statement.pdf itse. Älä päättele vaatimustenmukaisuutta objektista, joka on yhä muistissa, koska tavut, joita tuomitsisit, eivät ole ne tavut, jotka toimitit

Laskuskenaariot, jotka kantavat koneluettavaa XML:ää visuaalisen dokumentin rinnalla, noudattavat ZUGFeRD- ja Factur-X-mallia, joka on rakennettu PDF/A-3:n päälle. Niiden tulisi asettaa liitteen suhde eksplisiittisesti SetPDFA3DefaultAFRelationship:llä, koska ISO 19005-3 vaatii jokaista upotettua tiedostoa julistamaan roolinsa suhteessa dokumenttiin. Jätä se asettamatta, ja upotettu XML on vain blob ilman julistettua tarkoitusta, jonka validattori huomaa

Riippumattomat tuomarit: veraPDF ja Acrobat

Tuottajan ei pitäisi olla ainoa oman tuotoksensa tuomari. PDFlibPasin tarkistajat antavat nopeita, jäsenneltyjä tuomioita prosessissa, mikä on sitä mitä haluat kuumalla polulla, mutta julkaisuportin arkistoerälle pitäisi yhä ajaa tuotos sellaisen validattorin läpi, jota kukaan tiimissäsi ei ole kirjoittanut. veraPDF on yhteisön ylläpitämä referenssitoteutus PDF/A:lle ja työkalu, jonka useimmat arkistot nimeävät hyväksymiskriteereissään, joten se on se, johon matchata. Acrobatin preflight-profiilit tekevät käyttökelpoisen ratkaisijan kun veraPDF ja prosessissa oleva tarkistus ovat eri mieltä. Tallentaa validattorin nimi ja sen versio jokaisen tallennetun raportin viereen. Väite, että tiedosto läpäisi veraPDF:n, sanoo hyvin vähän ilman build-numeroa, joka sen läpäisi, koska työkalu kiristää sääntöjään julkaisujen välillä

Validattorit ovat eri mieltä standardien reunoilla, ja kun ovat, vastaus ei ole valita tykkäämäsi työkalu. Kutista tiedosto minimaaliseen näytteeseen, joka yhä laukaisee erimielisyyden, ja lue se standarditekstiä vasten. Tunti tuota yleensä paljastaa toisen kahdesta asiasta: aidon työkalubugin, jonka arvona on raportoida ylävirtaan, tai lausekkeen, jota tiimisi on lukenut väärin ja joka pitäisi kirjoittaa vaatimustenmukaisuusmuistiinpanoihin, jotta seuraava ei kiistä sitä uudelleen

Salattu syöte saa oikotien. molemmat tarkistajat ottavat salasana-argumentin, mutta PDF/A-1-tiedosto salasanakirjaston kanssa on jo vaatimustenvastainen, koska ISO 19005-1 kieltää salauksen suoraan, joten salattu lähetyksen voi hylätä ennen kuin syvempi analyysi ajetaan. Sen selvittäminen, mitä salauskirjasto todella myöntää, on oma tehtävänsä, joka on käsitelty PDF-salauksen ja oikeuksien auditoinnissa

PDF/UA-löydökset jäljittyvät lähes aina siihen, miten rakennepuu alun perin laadittiin, ja sen taustalla olevat tagitustekniikat elävät tagitettujen PDF-rakennepuiden rakentamisessa Delphissä. Arkistot, jotka myös vaativat digitaalisia allekirjoituksia, pitäisi parittaa tämän portin PAdES-allekirjoittamisen ja -validoinnin työnkulun kanssa. Täydellinen preflight-API-viite elää losLab PDF Library for Delphi -tuotesivulla