A ConvertToPDFA egyetlen hívással változtatja a mindennapi dokumentumot archívvá: eltávolítja, amit a választott rész tilt, hozzáadja, amit megkövetel, megnevezi a dokumentum által hivatkozott részt, majd ellenőrzi az eredményt. A hivatkozás csak akkor számít teljesítettnek, ha az ellenőrzés sikeres, és a GetPDFAConversionReport felsorolja, mit végeztek el, és mi áll még útban
Ez utóbbi tulajdonság az a tervezési döntés, amelyet érdemes jobban megnézni. Egy konverter, amely ellenőrzés nélkül bélyegzi a hivatkozást, rosszabb, mint egyáltalán semmilyen konverter, mert egy olyan fájl, amely archívnak mondja magát és nem az, egyenesen átjut azokon a rendszereken, amelyek egyébként elkapnák. A hiba évek múlva, egy audit során, egy olyan dokumentumnál bukkan ki, amit senki nem tud újragenerálni
Miért bukik meg egy érvényesnek tűnő PDF egy PDF/A-ellenőrzésen?
A leggyakrabban azért, mert a PDF két helye, amely megmondja, ki írta, nem egyezik. Egy validátor mind a dokumentuminformációs szótárat, mind az XMP csomagot beolvassa, és elutasítja azt a fájlt, ahol eltérnek — és az ehben a pontban megbukó fájlok nagy része egyszerűen soha nem kapta meg az XMP felét
A RepairDocumentMetadata hozza őket összhangba, és visszaadja, hány bejegyzést javított. Ahol csak az egyik fél hordoz értéket, a másik abból töltődik ki, így semmi már rögzített nem vész el. Senkinek nem kell eldönteni, melyik másolat a mérvadó, mert a gyakorlatban az egyik másolat üres
Ugyanebben a hívásban van egy második javítás is, amely egy finomabb esetet elkap. Egy PDF/A-módra állított dokumentum visszakapja a szabványazonosítását, ha elveszett, ami minden olyan alkalommal megtörténik, amikor a hívó saját XMP csomagot ad meg. Az azonosítás nélkül egy validátor egyszerű PDF-ként olvassa a fájlt, és a hivatkozott rész minden szabályát teljesítetlenként jelenti — egy látványosan tűnő hiba egyetlen kis okkal
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;A rész kiválasztása a konvertálás előtt
A SetPDFAMode és a ConvertToPDFA közös módsorszámozást használnak, és három érték friss. A 9-es mód a PDF/A-4, a PDF 2.0-ra épülő rész. A 10-es mód a PDF/A-4e, amely emellett 3D-t és rich media-t engedélyez, a 11-es mód pedig a PDF/A-4f, amely bármilyen formátumú beágyazott fájlt megenged
A 4-es rész máshogy azonosítja magát, mint a korábbi részek: részszámmal és a rész kiadási évével, sima PDF/A-4 esetén nincs megfelelőségi betű, a két kiterjesztésnél pedig E vagy F betű szerepel. Az ellenőrzés felismeri a 4-es részt, a fájljait PDF 2.0, nem pedig 1.7 alapján ítéli meg, és jelent egy olyan 4-es részű fájlt, amely nem tünteti fel a revíziós évét
Egy 4-es részű dokumentum minden beágyazott fájlja megnevezi, hogyan kapcsolódik a dokumentumhoz, ahogy a 3-as és 4-es rész egyaránt megköveteli. Ez az a szabály, amely régebben a mindennapi mellékleteket elkapta: a kapcsolatot csak az első utáni mellékletekhez írták ki, az utolsóhoz soha, tehát egyetlen melléklettel rendelkező dokumentum — a gyakori eset — egyáltalán nem hordozta, és pont emiatt bukik meg a validáción
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;Mire való a konvertálási jelentés
Annak eldöntésére, hogy mi a következő lépés. Egy sikeres konvertálásnak nincs szüksége jelentésre; egy sikertelen az egész oka annak, hogy a jelentés létezik. Egyes akadályokat egy konverter el tud távolítani, másokat nem — titkosítás, jelentést hordozó tiltott tartalom, olyan betűprogram, amely egyszerűen nincs sehol a gépen. A jelentés különválasztja, mi lett elvégezve, és mi maradt, ami a „konvertálás sikertelen”-t egy munkaelemmé alakítja
Az ítéletet egy batch-feldolgozó futószalagon kapuként kezeljük. Konvertáljunk, olvassuk az ítéletet, és irányítsuk a fájlt: archiváljuk azokat, amelyek átmentek, a többit pedig soroljuk be egy ember elé a jelentés csatolásával. Amit nem szabad tennünk, az egy sikertelen konvertálás kimenetét elmenteni az archívumba azért, mert jobban néz ki, mint a bemenet — most már egy olyan hivatkozást hordoz, amelyet az ellenőrzés nem igazolt
A már meglévő jelzés kiolvasása
Bármi konvertálása előtt tudnunk kell, mit mond a dokumentum önmagáról. Egy PDF/A-ellenőrzés, amely nem tudja beolvasni a meglévő szabványjelet, minden fájlt az 1-es részhez mér, bármilyet is deklarál, ami azt jelenti, hogy egy tökéletesen érvényes PDF/A-2 vagy PDF/A-3 dokumentum arról kap jelentést, hogy nem hordoz jelet, és túl magas a verziója — az igazság ellentéte
A jelet úgy is beolvassák, ha a producer XMP-elemként, úgy is, ha attribútumként írta. Mindkét forma mindennapi XMP, és csak az egyik elfogadása más producerektől származó fájlokat jelöletlennek tünteti fel. Ha már gondolkodtál azon, miért bukik meg egy máshol validáló dokumentum a saját futószalagodon, ez érdemes elsőként megnézni
Tisztítás archiválás előtt, és egy hiba, amit érdemes ismerni
Az archív konvertálás és a tisztítás gyakran együtt fut, mert a tartalom, amelyet egy biztonsági szabályzat eltávolítana, nagymértékben átfedi a PDF/A által tiltott tartalmat. A SanitizeDocument eltávolítja a JavaScriptet, és az utolsó szkript eltávolítása egyúttal eltávolítja az üres névfát is, amelyet hátrahagy — egy olyan fát, amely egyébként még azt mondaná az olvasónak, hogy a dokumentum szkripteket hordoz
Ez a második felét kemény úton tanultuk meg: a csomaglistában lévő off-by-one azt okozta, hogy a tisztítás arról jelentett, hogy eltávolítja a szkripteket, miközben egyet sem távolított el, tehát egy tisztított dokumentum még mindig lefuttatta a szkriptjeit megnyitáskor. Ez jó érv amellett az általános elv mellett, amelyen ez a cikk nyugszik — ellenőrizzük az eredményt, ne bízzunk a műveletben, a saját futószalagunkon éppúgy, mint a könyvtárban
A körülötte lévő archív munkához lásd a PDF/A és PDF/UA preflight, a valódi redakció és tartalomeltávolítás, valamint a Factur-X-hez tartozó PDF/A-3 XMP kiterjesztés sémák átjárásait, amelyek a metaadati oldalt tárgyalják, amikor az archivált dokumentum strukturált számlaadatokat is hordoz
A PDFlibPas natív Pascal PDF könyvtár Delphihez, C++Builderhez és Lazarushoz, így a konvertálás, a javítás és a validáció mind a saját folyamatunkon belül történik, külső eszköz nélkül a láncban — a támogatott PDF/A részeket és platformokat a PDFlibPas termékoldal tartalmazza