PDF/A na první pohled vypadá jednoduše: při exportu zvolíte příslušnou volbu, vznikne soubor s příponou PDF a tím by mělo být hotovo. V praxi se ale běžně stává, že dokument označený jako PDF/A neprojde nezávislou validací, dva nástroje se nad stejným souborem neshodnou nebo konverze do PDF/A změní vlastnosti, které organizace vůbec měnit nechtěla. Problém není v tom, že by PDF/A bylo „nespolehlivé“. Problém je spíš v představě, že PDF/A je jeden formát a jeho vytvoření jeden jednoduchý úkon.
PDF/A není zvláštní přípona, ale soubor pravidel pro PDF
PDF/A je standardizovaná podmnožina PDF určená pro dlouhodobé uchování statické vizuální podoby dokumentu. Smyslem není vytvořit jiný typ souboru než PDF, ale omezit a zpřesnit vlastnosti běžného PDF tak, aby jeho budoucí zobrazení nebylo závislé na zdrojové aplikaci, konkrétním počítači nebo externích zdrojích.
Proto PDF/A například vyžaduje, aby byly pro reprodukci potřebné zdroje uloženy přímo v souboru, typicky včetně použitých písem a informací o barvách. Naopak nepřipouští šifrování souboru a omezuje obsah, jehož budoucí chování by záviselo na aktivních nebo externích mechanismech. To, co je dovoleno, ale závisí i na konkrétní části standardu.
Právě zde vzniká první častý omyl. Neexistuje jen jedno „PDF/A“. Rodina ISO 19005 zahrnuje několik částí a variant či úrovní shody: PDF/A-1a a 1b, PDF/A-2a, 2b a 2u, PDF/A-3a, 3b a 3u a PDF/A-4, 4e a 4f. Jejich požadavky a technické možnosti se liší. Například PDF/A-2 je oproti PDF/A-1 postaveno na novější verzi PDF a připouští některé vlastnosti, které starší část neumí použít. PDF/A-3 zase umožňuje vložit do dokumentu i jiné typy souborů.
Jak PDF/A skutečně vzniká
PDF/A může vzniknout několika cestami. Nejčistší bývá přímý export ze zdrojové aplikace, která má k dispozici původní text, obrázky, písma i další informace. Stejně tak může PDF/A vzniknout při skenování nebo automatickým generováním z informačního systému.
Druhou cestou je konverze již existujícího PDF. To je podstatně jiná operace. Konvertor už nepracuje se zdrojovým dokumentem, ale pouze s výsledným PDF a musí z něj vytvořit soubor odpovídající zvolené variantě PDF/A. Může proto potřebovat doplnit nebo převést barevné informace, vložit dostupná písma, odstranit nepovolené prvky, upravit metadata nebo některé objekty přepsat.
Samotná norma přitom neurčuje konkrétní postup, jak se má papírový nebo elektronický dokument do PDF/A převádět. Stanoví požadavky na výsledný soubor. Dva různé generátory tedy mohou ze stejného vstupu dojít k technicky odlišnému výsledku, a přesto mohou oba vytvořit validní PDF/A.
„Uložit jako PDF/A“ není totéž jako nezávislá validace
Když aplikace při exportu nabídne volbu PDF/A, znamená to, že se pokusí vytvořit soubor podle příslušných pravidel. Není to ale nezávislé osvědčení, že výsledný soubor pravidla skutečně splňuje. Generátor může mít chybu, může špatně zpracovat konkrétní font, barvu, metadata nebo jinou konstrukci PDF.
PDF/A se navíc samo identifikuje pomocí metadat. Soubor tedy může deklarovat, že je například PDF/A-2b, aniž by všechny požadavky této varianty skutečně splňoval. Validátor proto neověřuje jen deklaraci v metadatech, ale samotnou strukturu a vlastnosti souboru.
V případě veraPDF je princip dobře vidět: validační profily formalizují jednotlivé závazné požadavky standardu a nástroj vyhodnocuje, zda je konkrétní soubor splňuje. Při automatické volbě validačního profilu veraPDF vychází z deklarace v XMP metadatech; profil lze ale zadat také výslovně.
Co validátor kontroluje
Validace není vizuální kontrola. Dokument může na monitoru vypadat zcela normálně a přesto být nevalidní. Validátor kontroluje technické požadavky zvolené varianty či úrovně shody. Podle konkrétní části PDF/A se může zabývat například tím, zda:
- jsou použitá písma vložena do souboru a lze je v dané variantě PDF/A použít,
- je reprodukce barev dostatečně jednoznačně popsána a jsou k dispozici potřebné barevné profily,
- soubor neobsahuje zakázané šifrování nebo nepřípustné aktivní prvky,
- metadata odpovídají požadavkům zvolené varianty a nejsou ve vzájemném rozporu,
- jsou použité PDF objekty a jejich vlastnosti přípustné v konkrétní variantě PDF/A,
- dokument skutečně odpovídá deklarované variantě PDF/A, nikoli pouze tomu, co o sobě tvrdí v metadatech.
Důležité je slovo „konkrétní“. Validátor nemá obecně odpovědět na otázku „je to nějaké PDF/A?“, ale na přesnější otázku „splňuje tento soubor požadavky konkrétní varianty či úrovně shody, proti které jej ověřuji?“
Proč validace nejčastěji selže
V praxi nejsou všechny chyby stejně zajímavé. Některé vznikají už ve zdrojovém dokumentu, jiné až při exportu nebo při dodatečné konverzi.
Písma
Typickým problémem jsou písma. PDF/A obecně vyžaduje, aby písmo potřebné k vykreslení nebylo závislé na jeho přítomnosti v operačním systému. Pokud zdrojová aplikace potřebné písmo nevloží, nemá k dispozici jeho vložitelný fontový program nebo vložení odmítne například kvůli licenčnímu omezení, může tvorba PDF/A selhat. Konvertor pak někdy musí použít náhradu nebo krajní řešení, například rasterizaci části obsahu. Tím už se ale může měnit kvalita, velikost souboru nebo možnosti práce s textem.
Barvy a ICC profily
Další skupinou problémů jsou barvy. Běžné PDF může obsahovat barvy popsané způsobem, který je při dlouhodobém uchování příliš závislý na konkrétním zařízení. PDF/A proto pracuje s požadavky na jednoznačnější reprodukci barev. Při konverzi se tak mohou doplňovat ICC profily nebo měnit způsob, jakým jsou barevné prostory v souboru popsány.To je také důvod, proč konverze do PDF/A nemusí být pouze „přidání značky do souboru“. U některých dokumentů jde o poměrně výrazný technický zásah.
Zakázané nebo zvolenou variantou nepodporované vlastnosti
Další chybou je snaha převést dokument do varianty PDF/A, která některé jeho vlastnosti neumí zachovat. Starší PDF/A-1 například vychází z PDF 1.4, zatímco PDF/A-2 a PDF/A-3 jsou založeny na novější PDF 1.7 a dovolují bohatší grafické konstrukce, včetně transparentnosti. Volba starší části tak může vyžadovat zjednodušení nebo přepočet obsahu, který by v novější variantě mohl zůstat zachován.
Podobně nelze obecně říct, že příloha uvnitř PDF je vždy chybou PDF/A. Záleží na konkrétní části a variantě: PDF/A-3 je právě navrženo tak, aby mohlo obsahovat i vložené soubory jiného typu. Bez znalosti cílové varianty proto může být i zdánlivě jednoznačné validační hlášení vyloženo špatně.
Metadata: dokument může vypadat správně a přesto selhat
Část problémů není při běžném otevření vůbec vidět. PDF může obsahovat XMP metadata, údaje v jiných částech souboru a deklaraci shody s PDF/A. Pokud si tyto informace odporují nebo deklarace neodpovídá skutečné struktuře souboru, validátor chybu odhalí, přestože na stránkách není vizuálně nic špatně.
To není formalismus bez významu. Metadata slouží mimo jiné k identifikaci a popisu dokumentu a obsahují také deklaraci jeho shody s konkrétní variantou PDF/A. Samotná deklarace však shodu nevytváří a způsob vykreslení dokumentu neurčují metadata sama. Opravit pouze deklaraci v metadatech proto nestačí, pokud ostatní vlastnosti PDF požadavkům příslušné varianty nevyhovují.
Proč dva validátory nemusí ukázat totéž
Rozdílný výsledek dvou nástrojů neznamená, že PDF/A je relativní norma, podle které může mít každý program vlastní pravdu. Pokud dva nástroje skutečně kontrolují stejný soubor proti stejné variantě či úrovni shody a proti stejným normativním požadavkům, měly by dojít ke stejnému závěru.
V praxi se ale mohou lišit podmínky kontroly. Jeden nástroj může validační profil určit automaticky podle metadat, druhý jej může mít nastavený ručně. Lišit se může verze validačního jádra, interpretace opraveného nebo sporného pravidla i chyba v implementaci. Některé informační systémy navíc vedle samotné shody s PDF/A uplatňují vlastní vstupní pravidla. To, že systém soubor odmítne, proto ještě samo o sobě neříká, které konkrétní ustanovení PDF/A soubor porušil.
Při sporu proto není užitečná věta „u mě je to zelené“. Důležitá je konkrétní část a varianta PDF/A, verze validačního nástroje a přesné pravidlo, které podle jednoho validátoru selhalo.
Validní PDF/A ještě neznamená kvalitní dokument
Validace odpovídá na technickou otázku shody se standardem. Neříká, zda je dokument obsahově správný, zda OCR správně rozpoznalo text, zda je dokument přístupný, zda je elektronický podpis důvěryhodný nebo zda má dokument potřebné právní náležitosti.
Stejně tak PDF/A samo nechrání soubor před poškozením dat. Je to formát zaměřený na dlouhodobou reprodukovatelnost, nikoli náhrada zálohování, správy integrity, elektronických podpisů nebo archivních procesů.
Jak nastavit tvorbu a validaci rozumně
Největší jistotu nedává jeden konkrétní program, ale reprodukovatelný proces. Organizace by nejprve měla vědět, jakou část a variantu či úroveň shody PDF/A skutečně potřebuje. Pokud požadavek stanoví právní předpis, informační systém, archivní politika nebo smluvní protistrana, je třeba vycházet právě z něj a nevynucovat starší či přísnější variantu jen ze zvyku.
Je-li to možné, je vhodnější vytvářet PDF/A přímo ze zdrojového dokumentu než opakovaně převádět hotové PDF. Výsledek má smysl po vytvoření nezávisle validovat, zejména pokud jde o dokumenty určené pro dlouhodobé ukládání nebo pro automatizovanou výměnu mezi systémy.
Při chybě je lepší pracovat s konkrétním validačním pravidlem než dokument opakovaně otevírat a ukládat v různých aplikacích, dokud „něco neprojde“. Takový postup může problém zakrýt, změnit obsah nebo vytvořit další odvozené verze, aniž by bylo jasné, co se skutečně opravilo.
Pro důležitější procesy je praktické evidovat alespoň cílovou část a variantu PDF/A a validační nástroj včetně jeho verze. Ne proto, že by konkrétní validátor určoval obsah normy, ale proto, aby bylo možné stejnou kontrolu později reprodukovat a vysvětlit.
Shrnutí
PDF/A není tlačítko ani vlastnost, kterou soubor získá tím, že ji o sobě uvede v metadatech. Je to soubor technických požadavků vyplývajících z konkrétní části a varianty či úrovně shody PDF/A. Jeho vytvoření může být jednoduchým exportem, ale také poměrně složitou konverzí zasahující do písem, barev, metadat nebo dalších vlastností dokumentu.
Validátor proto nekontroluje, zda soubor „vypadá jako PDF/A“, ale zda splňuje jednotlivé požadavky zvolené varianty. Když validace selže, správná otázka není „který program má pravdu“, ale „proti jaké části a variantě PDF/A se validovalo a které konkrétní pravidlo nebylo splněno“.
Právě tato disciplína odděluje spolehlivou práci s PDF/A od provozní zkratky typu „uložili jsme to jako PDF/A, takže to PDF/A musí být“.
Tento článek má informační charakter.