Képzeld el ezt. Egy pénzügyi csapat archiválja az ügyfélkivonatokat és a tranzakciós rekordokat mint PDF/A az elmúlt hat évben. Minden fájl tartalmazza a megfelelő metaadat címkét. Minden alkalmazott azt hiszi, hogy a munka elkészült a fájl mentésének pillanatában. Ezután megjelenik egy szabályozó egy rutinszerű felülvizsgálaton, lefuttat néhány fájlt egy érvényesítőn, és a fele meghiúsul.
Soha egyik dokumentumhoz sem nyúltak hozzá, semmi sem történt másként. Ezek a dokumentumok kezdetben sosem voltak megfelelőek, csak azt állították, hogy megfelelnek. És ez a különbség a „PDF/A-nak állítás” és a „PDF/A-nak lenni” között a dokumentumarchiválás egyik leggyakoribb és legköltségesebb vakfoltja manapság.
Tehát ha az archiválási erőfeszítései kudarcot vallanak, és/vagy a folyamat helyes oldalán szeretne maradni, akkor itt van, hogy mi történik valójában, és hogyan hozhat létre robusztus munkafolyamatot PDF/A megfelelőség.
Miért fontosabb a PDF/A megfelelőség, mint a legtöbb csapat gondolná
A PDF/A nem csak „PDF archiválással”. Ez egy ISO-szabványok által meghatározott formátum annak biztosítására, hogy egy dokumentum pontosan ugyanúgy nyíljon meg és nézzen ki most, tíz év múlva és ötven év múlva, függetlenül attól, hogy milyen szoftvert vagy betűtípust telepítettek az olvasáshoz.
Ennek nagy jelentősége van a szabályozás terén. Az olyan szabályozások, mint például a GDPR, előírják, hogy a vállalatnak meg kell őriznie személyes adatainak integritását, titkosságát és elérhetőségét. A MiFID II-hez hasonló szabályozások előírják, hogy a cégek évekig tárolják az ügyfelek kommunikációs és tranzakciós adatait olyan formátumban, amelyet nem lehet titokban megváltoztatni. Csináljon itt valamit, és éves bevételének egyszámjegyű százalékában mérhető bírságra számíthat, ami jelentős összeg egy nagyvállalatnál.
Ezért mikor PDF/A megfelelőség hiányzik az archívum, ez nem tekinthető a technológia problémájának. Ez szabályozási megfelelési problémának minősül, és a felelősség a szóban forgó céget terheli.
A leggyakoribb okok, amelyek miatt a PDF/A-fájlok nem érvényesülnek
A legtöbb PDF/A hiba az ismétlődő problémák rövid listájára vezethető vissza. Itt általában elromlanak a dolgok.
Nem teljesen beágyazott betűtípusok
Kétségtelenül ez a probléma leggyakoribb oka. PDF/A fájl esetén a dokumentumban használt összes betűtípust be kell ágyazni a fájlba, hogy a nézőnek ne kelljen telepítenie a betűtípusokat a gépére. Sok esetben csak a betűtípus részhalmaza van beágyazva a PDF-fájlba, ami általában sikertelen az ellenőrzési folyamatban. A valós PDF/A fájlokon végzett korábbi tanulmányok azt mutatták, hogy a nem megfelelő példányok több mint fele betűtípusokból származik.
Eszköztől független színterek
A PDF/A követelményeknek megfelelően a színeket eszközfüggetlen ICC-profilokon keresztül kell leírni a konzisztens megjelenítés érdekében, függetlenül attól, hogy milyen monitort, nyomtatót vagy alkalmazást használ a dokumentum megtekintéséhez. Érdekes módon a PDF/A létrehozása során az egyik leggyakrabban elkövetett hiba egy bizonyos színtéren (például egyszerű sRGB) alapuló dokumentumot érint, amelyből hiányzik a szükséges ICC-profil.
Metaadatok, amelyek nem egyeznek a valósággal
Minden PDF/A dokumentumnak tartalmaznia kell az XMP metaadatokat, amelyek jelzik, hogy a PDF/A melyik verziójának felel meg (PDF/A-1, -2 vagy -3), és melyik megfelelőségi szinten (A, B vagy U). Az ilyen metaadatok megadásának elmulasztása, vagy hibás vagy félrevezető módon történő megadása azonnali kudarcot jelent az auditálás megkezdése előtt.
Zavaros inkrementális frissítési előzmények
A növekményes frissítés további adatokat fűz a meglévő PDF-dokumentumhoz anélkül, hogy a teljes dokumentumot a semmiből újraírná. Ez egy kényelmes lehetőség a szabványos PDF-fájlokban, de a PDF/A fájlok, ez óvatosan történik:
- •A PDF/A-1 egyáltalán nem teszi lehetővé a növekményes frissítéseket. Minden szerkesztésnek a fájl teljes újraírását kell eredményeznie.
- •PDF/A-2 és PDF/A-3 esetén a növekményes frissítések megengedettek; azonban a csatolt adatoknak meg kell felelniük a dokumentum többi részének. Például egy változat hozzáfűzése nem beágyazott betűtípusokkal érvényteleníti a teljes fájlt.
- •A fájl fejlécében szereplő verziószámnak is meg kell egyeznie a dokumentum belső katalógusában megadott verzióval. Az itt található eltérést könnyű elmulasztani, és egyszerű módja annak, hogy meghiúsuljon az érvényesítés.
Egy dokumentum PDF/A formátumba konvertálása nem egyenlő a PDF/A érvényesítésével
Ez az a terület, ahol sok cég megbotlik; és egyértelműen ki kell mondani.
A konvertálás során egy dokumentumot, annak eredeti formátumától függetlenül (legyen szó Word-dokumentumról, HTML-oldalról vagy PDF-ről), konvertál PDF/A fájl. Ennek során a szoftver metaadatokat ad hozzá, amelyek igazolják, hogy az újonnan létrehozott fájl PDF/A-kompatibilis.
Az érvényesítés egy teljesen más folyamat, ahol egy speciális program ellenőrzi, hogy a fájl valóban megfelel-e a tanúsítvány megszerzéséhez szükséges összes követelménynek.
De itt van a csavar: A konverziós szakaszban beillesztett metaadatok állítás, nem bizonyíték. A fájl metaadatai között előfordulhat, hogy PDF/A-2b-kompatibilis, de nem felel meg a PDF/A-2b-ellenőrzésnek.
Ezt tovább rontja, hogy sok ingyenes és nyílt forráskódú PDF/A érvényesítők heurisztikát használjon, és ne soronkénti összehasonlítást a teljes specifikációhoz képest. Ez azt jelenti, hogy gyakran azt állítják, hogy egy dokumentum "valószínűleg" érvényes, ami elsőre jó hírnek tűnhet, de egyáltalán nem az. A megfelelőség ellenőrzésének másik módja a vizuális, amikor valaki egyszerűen kinyitja a dokumentumot, és megnézi, hogy jól néz-e ki.
Minden PDF/A fájlnak legalább:
- •Az összes betűtípust, képet és tartalmat közvetlenül ágyazhatja be, külső hivatkozás nélkül
- •Kerülje el teljesen az audio-, video-, JavaScript- és XFA-űrlapokat
- •Hagyja ki az LZW tömörítést, titkosítást és jelszavas védelmet
- •Adjon minden interaktív űrlapmezőnek megfelelő megjelenésű szótárt
- •A metaadatok tárolása az XMP szabvány használatával
Hagyja ki az érvényesítést, és bízik abban, hogy a négyzetek mindegyike helyesen lett bejelölve, anélkül, hogy ténylegesen megerősítette volna.
A megfelelőségi szintek nem cserélhetők fel
A sikertelen ellenőrzések másik csendes forrása a megfelelőségi szintű eltérés, amikor egy fájl azt állítja, hogy a megfelelőségi szintet valójában nem teljesíti.
Itt két dolgot érdemes megérteni:
Maguk a szabványok különböznek egymástól. A PDF/A-1, PDF/A-2 és PDF/A-3 év különbséggel kerültek közzétételre, és nem ugyanazok a szabályok. A PDF/A-1 például nem támogatja az átlátszóságot vagy a rétegeket, és csak A és B megfelelőségi szintet kínál. A PDF/A-2 támogatja az átlátszóságot, a rétegeket és még más PDF/A fájlok beágyazását is, valamint egy új szint, az U.
A megfelelőségi szintek egymásra épülnek. Az U szint mindent tartalmaz, ami a B szinthez szükséges, az A szint pedig mindent, ami az U szinthez szükséges, plusz még több. A megfelelő szint kiválasztása nem csupán egy technikai részlet, hanem egy döntés, amely valós következményekkel jár arra nézve, hogy mennyire lesz használható az archívum évek múlva. Egy követelésarchívumnak, ahol például a dokumentumoknak kereshetőnek és szöveges kivonatolásnak kell maradniuk, legalább U szintre van szükség. A B szint önmagában ezt nem garantálja.
Az U szint kifejezetten a szövegintegritásról szól. Ez biztosítja, hogy a dokumentumban található Unicode-szöveg később megbízhatóan kimásolható vagy kereshető legyen, ami rendkívül fontos minden olyan archívum esetében, amelyet esetleg évekkel a benyújtás után át kell nézni vagy keresni kell.
Hogy néz ki valójában egy auditbiztos PDF/A folyamat?
A védhető archiválási folyamat általában a következőt követi:
A forrásdokumentum normalizálása → Konvertálás PDF/A formátumba → Önálló érvényesítés → A fájl archiválása
Ez az a lépés, amelyet a legtöbb szervezet általában kihagy, de ez a legdöntőbb lépés. Abban az esetben, ha a fájlt más formára konvertáló szoftver az átalakítási folyamatot érvényesítő szoftver, akkor mindössze annyit kell tennie, hogy érvényesíti a szoftver által generált kimenetet a szoftver által megértett specifikáció alapján. A specifikáció szoftver által végzett helytelen értelmezése nem észlelhető mindaddig, amíg a fájlt egy független érvényesítő nem érvényesíti.
A szilárd ellenőrzési nyomvonalnak a következőket kell tartalmaznia:
- •Feljegyzés arról, hogy ki és mikor konvertálta az egyes fájlokat
- •A használt eszköz neve és verziója
- •Független érvényesítési jelentés, amely megerősíti az állítólagos megfelelőségi szintet, ideális esetben időbélyeggel és a dokumentummal együtt tárolva
A generálást és az érvényesítést várhatóan különböző rendszerek végzik; az érvényesítési jelentéseknek géppel olvashatónak kell lenniük, és ellenőrzési bizonyítékként meg kell őrizni őket; és a követelt és a tényleges tartalom közötti összhangnak valósnak kell lennie. A GDPR és a MiFID II szerint az integritás igazolásának felelőssége teljes mértékben az archívum tulajdonosát terheli, nem a szoftverszolgáltatót.
Következtetés
Az önállóan nem hitelesített PDF/A fájl valójában csak egy olyan fájl, amely reméli, hogy megfelel. Ez évekig megfelelő lehet, egészen addig, amíg egy szabályozó meg nem kéri az archívumot. Épület PDF/A hitelesítés a csővezetékbe, mint külön, független lépés az, ami egy reményteljes archívumot védhetővé varázsol, és sokkal olcsóbb szokás most felépíteni, mint később kifizetni.
Tegye meg a következő lépést a PDF/A megfelelőség felé
Konvertálás PDF/A formátumbaBiztonságban a kezünkben
Az AziPDF komolyan veszi a magánéletét. Ne feledje, hogy...