ConvertToPDFA muuttaa tavallisen asiakirjan arkistoasiakirjaksi yhdellä kutsulla: se poistaa mitä valittu osa kieltää, lisää mitä osa vaatii, ilmoittaa osan jonka asiakirja vaatii ja tarkistaa sitten tuloksen. Vaatimus raportoidaan täytetyksi vain kun tarkistus menee läpi, ja GetPDFAConversionReport luettelee mitä tehtiin ja mitä vielä seisoo tiellä
Juuri tuo viimeinen ominaisuus on se suunnittelupäätös johon kannattaa pysähtyä. Muunnin joka leimaa vaatimuksen tarkistamatta on pahempi kuin ei konvertoria lainkaan, koska tiedosto joka sanoo olevansa arkistoinnittava ja ei ole, pääsee suoraan läpi juuri niistä järjestelmistä jotka muuten olisivat sen kiinni ottaneet. Virhe nousee esiin vuosia myöhemmin, tilintarkastuksessa, asiakirjassa jota kukaan ei voi enää uudelleentuoata
Miksi PDF joka näyttää kelvolliselta epäonnistuu PDF/A-tarkistuksessa?
Useimmiten siksi, että PDF:n kaksi paikkaa jotka sanovat kuka sen kirjoitti ovat eri mieltä. Validaattori lukee sekä asiakirjan information sanakirjan että XMP-paketin ja hylkää tiedoston jossa nämä eroavat — ja useimmat tiedostot jotka kaatuvat tähän pisteen eivät yksinkertaisesti koskaan saaneet XMP-puoltaan kirjoitetuksi lainkaan
RepairDocumentMetadata saattaa ne linjaan ja palauttaa kuinka monta tietoa se korjasi. Jos vain toinen puoli kantaa arvoa, toinen täytetään siitä, joten mitään jo kerran kirjattua ei heitetä pois. Kenenkään ei tarvitse päättää kumpi kopio on auktoritatiivinen, koska käytännössä yksi kopio on tyhjä
Samassa kutsussa on toinenkin korjaus joka ottaa kiinni hienovaraisemman tapauksen. Asiakirja jolle on asetettu PDF/A-tila saa standarditunnisteensa palautetuksi jos se oli kadonnut, mikä tapahtuu aina kun kutsuja toimittaa oman XMP-paketin. Ilman tuota tunnistetta validaattori lukee tiedoston tavallisena PDF:nä ja raportoi kaikki vaaditun osan säännöt täyttämättömiksi — näyttävän suuruinen virhe jolla on yksi pieni syy
var
Lib: TPDFlib;
Repaired: Integer;
begin
Lib := TPDFlib.Create;
try
Lib.LoadFromFile('incoming.pdf', '');
Repaired := Lib.RepairDocumentMetadata;
Log(Format('%d metadata entries brought into agreement', [Repaired]));
Lib.SaveToFile('incoming-fixed.pdf');
finally
Lib.Free;
end;
end;Osen valitseminen ennen muuntamista
SetPDFAMode ja ConvertToPDFA jakavat saman numeroinnin, ja kolme arvoista on tuoreita. Tila 9 on PDF/A-4, PDF 2.0:aan rakennettu osa. Tila 10 on PDF/A-4e, joka lisäksi sallii 3D- ja rich media -sisällön, ja tila 11 on PDF/A-4f, joka sallii upotetun tiedoston missä tahansa muodossa
Osa 4 tunnistaa itsensä eri tavalla kuin edeltäneet osat: osanumerolla ja vuodella jolloin sen osa julkaistiin, ilman vaatimustasokirjainta pelkälle PDF/A-4:lle ja kirjaimella E tai F kahdelle laajennukselle. Tarkistus tunnistaa osan 4, tuomitsee sen tiedostot PDF 2.0:eaa vasten eikä 1.7:ää vasten, ja raportoi osa 4 -tiedoston joka ei ilmoita julkaisuvuottaan
Jokainen upotettu tiedosto osa 4 -asiakirjassa ilmoittaa miten se liittyy asiakirjaan, kuten osat 3 ja 4 molemmat vaativat. Tämä on sääntö joka aiemmin otti kiinni tavalliset liitteet: suhde kirjoitettiin vain ensimmäisen jälkeisille liitteille eikä koskaan viimeiselle, joten asiakirja jolla oli yksittäinen liite — yleinen tapaus — ei kantanut lainkaan suhdetta ja epäonnistui validoinnissa juuri tuossa pisteessä
var
Verdict: Integer;
begin
Lib.LoadFromFile('report.pdf', '');
Verdict := Lib.ConvertToPDFA(9); // 9 = PDF/A-4, 10 = 4e, 11 = 4f
Memo1.Lines.Text := Lib.GetPDFAConversionReport;
if Verdict = 1 then
Lib.SaveToFile('report-pdfa4.pdf')
else
Log('conversion incomplete - see the report for what stands in the way');
end;Mihin muunnosraportti on tarkoitettu
Päätöksen tekemiseen siitä mitä tehdä seuraavaksi. Onnistunut muunnos ei tarvitse raporttia; muunnos joka ei onnistu on koko syy miksi raportti on olemassa. Jotkut esteet ovat muuntimen poistettavissa ja jotkut eivät — salaus, kielletty sisältö joka kantaa merkitystä, fonttiohjelmaa joka ei yksinkertaisesti ole missään koneella. Raportti erottaa tehdyt jäljellä olevista, mikä muuttaa "muunnos epäonnistui" työkohteeksi
Käsittele tuomiota porttina eräputkessa. Muunna, lue tuomio ja reititä tiedosto: arkistoi ne jotka menivät läpi, jonoa loput ihmiselle raportti liitteenä. Mitä sinun ei tulisi tehdä on tallentaa epäonnistuneen muunnoksen tulosta arkistoon koska se näyttää paremmalta kuin syöte — se kantaa nyt vaatimusta jonka tarkistus kieltäytyi vahvistamasta
Tiedoston jo kantaman merkin lukeminen
Ennen mitään muuntamista, tiedä mitä asiakirja sanoo itsestään. PDF/A-tarkistus joka ei osaa lukea olemassa olevaa standardimerkkiä tuomitsee jokaisen tiedoston osaa 1 vastaan mitä ikinä se ilmoittaakin, mikä tarkoittaa että täysin kelvollinen PDF/A-2- tai PDF/A-3-asiakirja raportoidaan merkittömäksi ja liian korkeaversioiseksi — totuuden vastaisesti
Merkki luetaan riippumatta siitä kirjoittiko tuottaja sen XMP-elementtinä vai attribuuttina. molemmat muodot ovat tavallista XMP:tä, ja vain toisen hyväksyminen jättää muiden tuottajien tiedostot näyttämään merkitsemättömiltä. Jos olet koskaan miettinyt miksi asiakirja joka validoituu muualla epäonnistuu omassa putkessasi, tämä on hyvä paikka katsoa ensimmäisenä
Puhdistaminen ennen arkistointia, ja virhe jonka kannattaa tuntea
Arkistointimuunnos ja puhdistus juostaan usein yhdessä, koska turvallisuuskäytännön poistettava sisältö menee vahvasti päällekkäin PDF/A:n kieltämän sisällön kanssa. SanitizeDocument poistaa JavaScriptin, ja viimeisen skriptin poistaminen poistaa myös sen jättämän tyhjän nimipuun — puun joka muuten yhä kertoisi lukijalle asiakirjan kantavan skriptejä
Tuo jälkimmäinen puolikas opittiin kantapään kautta: yksi virhe pakettiluettelossa tarkoitti että puhdistus raportoi poistaneensa skriptejä poistamatta yhtäkään, joten puhdistettu asiakirja yhä suoritti skriptinsä avattaessa. Se on hyvä argumentti yleiselle periaatteelle johon tämä koko artikkeli nojaa — varmista tulos sen sijaan että luotat operaatioon, sekä omassa putkessasi että kirjastossa
Ympäröivää arkistointityötä varten katso artikkelit PDF/A- ja PDF/UA-eskelennus, aito rajaus ja sisällön poisto sekä PDF/A-3:n XMP-laajennusskeemat Factur-X:lle, joka käsittelee metatietopuolen kun arkistoitu asiakirja kantaa myös rakenteellista laskudataa
PDFlibPas on natiivi Pascal-PDF-kirjasto Delphille, C++Builderille ja Lazarukselle, joten muunnos, korjaus ja validointi tapahtuvat kaikki oman prosessisi sisällä ilman ulkoista työkalua ketjussa — katso PDFlibPas-tuotesivulta tuetut PDF/A-osat ja alustat