PDF/A, PDF/X és PDF/UA kimenet Delphiben: HotPDF

A PDF/A, a PDF/X és a PDF/UA három különböző szabvány, amely három különböző gondot old meg: a hosszú távú archiválást, a nyomdai átadást és az akadálymentességet. Nem három jelölőnégyzet egyetlen megfelelőségi űrlapon, és a leggyakoribb hiba éppen az, ha annak tekintik őket. Egy fájl lehet hibátlan PDF/A és használhatatlan egy nyomda számára; egy tökéletes nyomdai mesterpéldány olvashatatlan lehet egy képernyőolvasónak. Ami rosszabb: mindhárom a fájl belső szerkezetére vonatkozó megkötés, nem arra, hogyan néz ki. Az a dokumentum, amely minden birtokolt megjelenítőben tisztán nyílik meg, elsőre így is elbukhat az ellenőrzésen, és általában el is bukik

A HotPDF, a losLab natív VCL PDF-könyvtára, a megfelelőséget olyasminek tekinti, amelyet az első oldal létrejötte előtt kell kijelentenie. Beállít egy megfelelőségi tulajdonságot, csatolja azokat a szerkezeteket, amelyeket a szabvány megkövetel, a könyvtár pedig mentéskor megtagadja azokat a beállításokat, amelyek ellentmondanak a profilnak. Ez jobb modell annál, mint hogy előállít egy fájlt, és reménykedik, hogy egy utófeldolgozó utólag beleépíti a hiányzót, mert ezeknek a szabványoknak a legtöbb követelménye utólag nem pótolható

Három ISO-szabvány, három különböző ígéret

A PDF/A (ISO 19005) az időről szól. Azt ígéri, hogy a fájl évtizedek múlva is azonosan jelenik meg, ezért teljes önállóságot követel: minden betűkészletet beágyazva, minden színt eszközfüggetlen jelentéssel egy OutputIntent szerkezeten át, teljes XMP jellemzőkészletet, és tilt mindent, aminek a viselkedése a környezettől függ. A titkosítás és a JavaScript kimarad, mert senki sem garantálhatja, hogy a visszafejtő vagy a szkriptmotor 2050-ben létezni fog

A PDF/X (ISO 15930) a papírra vitt színről szól. Azért létezik, hogy egy tervező úgy adhasson át fájlt egy nyomdának, hogy egyiküknek se kelljen megbeszélnie, ami jellemzett nyomtatási feltételeket, kötelező /Trapped kulcsot, meghatározott vágási és kifutógeometriát jelent, az X-1a változatban pedig azt is, hogy nincs élő átlátszóság, amelyet a RIP-nek kellene kitalálnia. A PDF/UA (ISO 14289) arról szól, ki tudja elolvasni az eredményt. A segítő technológiának teljes címkefára, épeszű olvasási sorrendre, kijelentett dokumentumnyelvre és minden nem szöveges elemhez szöveges alternatívára van szüksége

Mivel a három különböző irányba húz, kimeneti csatornánként válassza ki az irányadó szabványt, ahelyett hogy egyetlen, mindet kielégítő fájlt kergetne. Egy csak CMYK nyomdai mesterpéldány pontosan az, amit nem szabad annak a képernyőolvasót használó embernek átadni, aki soha nem lát színt, az archiválási profil dinamikus viselkedésre vonatkozó zárja pedig ütközik mindennel, ami interaktív. Ha ugyanabból a forrásadatból csatornánként generál, az egész ellentmondást megkerüli

PDF/A: az OutputIntent az a rész, amelyet mindenki elfelejt

Ha egy PDF/A fájl elbukik az ellenőrzésen, először az OutputIntent szerkezetet nézze meg. Ezt hagyják ki leggyakrabban a generátorok, épp azért, mert semmi látható nem függ tőle. Az ISO 19005 megköveteli: beágyazott ICC-profilt, amely rögzíti, mit is jelentenek valójában a dokumentum eszközszínei. A HotPDF ezt a profilt kifejezett bemenetté teszi, nem utólagos gondolattá:

var
  Pdf: THotPDF;
  ICC: TFileStream;
begin
  Pdf := THotPDF.Create(nil);
  try
    Pdf.FileName := 'invoice-archival.pdf';
    Pdf.PDFACompliance := 'B';            // B szint: vizuális hűség
    Pdf.Lang := 'en-US';
    Pdf.StandardFontEmulation := False;   // valódi betűkészletek beágyazása, Base-14 emuláció nélkül
    ICC := TFileStream.Create('sRGB.icc', fmOpenRead);
    try
      Pdf.AddPDFAOutputIntent('sRGB IEC61966-2.1', '', ICC, 3, 'DeviceRGB');
    finally
      ICC.Free;
    end;
    Pdf.BeginDoc;
    Pdf.CurrentPage.SetFont('Arial', [], 11);
    Pdf.CurrentPage.TextOut(50, 760, 0, 'Archival invoice body');
    Pdf.EndDoc;
  finally
    Pdf.Free;
  end;
end;

Néhány részlet dönti el itt a sikert vagy a bukást. A StandardFontEmulation tulajdonságnak kikapcsolva kell lennie: az emulált Base-14 betűkészletek nincsenek beágyazva, a beágyazás pedig az ISO 19005 alatt nem alku tárgya. A titkosításnak letiltva kell maradnia, tehát soha ne kombinálja a PDFACompliance tulajdonságot az ActivateProtection hívással; a titkosított archiválási fájl olyan ellentmondás, amelyet az ellenőrző azonnal elkap. Az AddPDFAOutputIntent hívásban megadott összetevőszámnak egyeznie kell a profillal, ami RGB-profilnál, például az sRGB IEC61966-2.1 esetén 3, CMYK esetén pedig 4. A HotPDF írás közben követi a DeviceRGB és a DeviceCMYK használatát a kijelentett szándékhoz mérve, tehát egy elkóborolt CMYK kitöltés egy RGB-szándékú dokumentumban jelentett gonddá válik, nem néma hibává

Egy dolgot érdemes kimondani az ICC-profilról: kezelje verziózott telepítési eszközként, ne olyan fájlként, amelyet valaki egyszer letett a fordítási kiszolgálóra. A bájtjai minden generált dokumentumba beágyazódnak, tehát egy csonka vagy sérült profil csendben megmérgez egy egész köteget, és erről csak az ellenőrzéskor szerez tudomást. Szállítsa a telepítőjével, jegyezze fel az ellenőrzőösszegét a futásnaplóba, és a fent bemutatott TFileStream mintával töltse be, hogy egy hiányzó fájl hangosan elhasaljon a generálás közben ahelyett, hogy némán az archívum kapujában bukna el

PDF/X nyomdához: Trapped, CMYK és a nyomdai profil

A nyomdai mesterpéldányok megfordítják a színről szóló történetet. A gép jellemzett CMYK értéket kíván, a szabvány pedig arra kényszeríti, hogy kijelentse, alkalmaztak-e átfedést, akkor is, amikor az őszinte válasz az, hogy fogalma sincs. A /Trapped kulcs mindenképpen kötelező:

Pdf.PDFXCompliance := 'X-1a';
Pdf.Trapped := 'Unknown';        // az ISO 15930 alatt kötelező kulcs
ICC := TFileStream.Create('FOGRA39.icc', fmOpenRead);
try
  Pdf.AddPDFXOutputIntent('FOGRA39 (ISO 12647-2:2004)', '', ICC, 4, 'DeviceCMYK');
finally
  ICC.Free;
end;
Pdf.BeginDoc;
// rajzoljon CMYK-biztos színekkel, átlátszóság és titkosítás nélkül
Pdf.EndDoc;

Az összetevőszám most 4 a CMYK nyomdai profilhoz. Az X-1a az élő átlátszóságot is tiltja, tehát vizsgálja át minden olyan rajzolási kódját, amely áttetsző elemeket rétegez; amit egy megjelenítő a képernyőn összeolvaszt, pontosan az, amit a RIP nem lesz hajlandó értelmezni. Ha a nyomdája más jellemzést küld, cserélje ki a profil bájtjait és az azonosító karakterláncot, a körülötte lévő szerkezethez viszont ne nyúljon

PDF/UA: a szerkezet generált, soha nem utólag beépített

Az akadálymentesség az a szabvány, amelyet a csapatok a leggyakrabban próbálnak a végén ráaggatni, és ezt a megközelítést keményebben bünteti, mint a másik kettő. A címkefának azt a sorrendet kell tükröznie, amelyben a tartalom logikailag létrejött, és ez olyan információ, amellyel a fájl kiírása után egyszerűen már nem rendelkezik. A PDFUACompliance beállítása bekapcsolja a címkézett kimenetet, a szerkezeti API pedig menet közben köti minden rajzolási hívást a saját jelentésbeli szerepéhez:

Pdf.PDFUACompliance := True;     // automatikusan bekapcsolja a címkézett PDF-et
Pdf.Lang := 'en-US';             // állítsa be kifejezetten; üresen 'en' értékre esik vissza
Pdf.BeginDoc;

Root := Pdf.AddStructureElement(sstDocument, nil);
H1 := Pdf.EmitTaggedHeading(1, Root, 50, 700, 'Quarterly Report');
Para := Pdf.BeginTaggedContent('P', Root);
Pdf.CurrentPage.TextOut(50, 650, 0, 'Revenue grew in all regions.');
Pdf.EndTaggedContent;

Pdf.EndDoc;

Az a hiba, amelyre figyelni kell, a BeginTaggedContent/EndTaggedContent páron kívül kirajzolt szöveg. Tökéletesen megjelenik, és láthatatlan marad a képernyőolvasónak, tehát látó tesztelő soha nem kapja el; a hiba kiszállításra kerül, és csak akkor bukkan fel, amikor egy valódi, segítő technológiát használó felhasználó beleütközik a résbe. Ha a sablonjai egyedi szerkezeti szerepneveket hordoznak, képezze le őket a szabványos készletre az AddStructRoleMap('MyHead', 'H1') hívással, hogy a megfelelő olvasók tudják, mit jelentenek. Az ISO 14289 kijelentett nyelvet is megkövetel. A HotPDF 'en' értékre esik vissza, ha a Lang üres, de ez biztonsági háló, nem ok arra, hogy a valódi dokumentumnyelvet beállítatlanul hagyja

Ellenőrzés: az ellenőrzőben bízzon, ne a megjelenítőben

Az a megjelenítő, amely megnyitja a fájlját, semmit sem bizonyít a megfelelőségről, tehát az ellenőrzés a kiadási útra való, olyan eszközökkel, amelyek a szerkezetet vizsgálják, nem a megjelenítést. PDF/A és PDF/UA esetén a veraPDF a referenciaszintű nyílt ellenőrző; ISO-szakaszonként jelenti a hibákat, ami közvetlenül visszavezet a fenti beállításokhoz. PDF/X esetén az Adobe Acrobat Preflight profiljai maradtak a gyakorlati ellenőrzés, mert a nyomdai megfelelőség legalább annyira a színszándékról szól, mint a szintaxisról

A generátor is elvégzi a maga részét ebből. Mentéskor a HotPDF összeveti a szolgáltatásjelzőket a beállított PDF-verzióval, és némán visszaminősíti azt, amit a verzió nem tud kifejezni, például az AES-256 titkosítást AES-128 értékre PDF 1.7 alatt. Az EndDoc megfelelőségi kapui ennél tovább mennek, és a kemény ellentmondásoknál egyenesen kivételt váltanak ki, például amikor a PDFACompliance tulajdonságot titkosítással együtt kéri. Ezek egyike sem helyettesíti a külső ellenőrzőt. Csak megakadályozzák, hogy lehetetlen beállítások egyáltalán eljussanak hozzá

Egy szokás ismételten megtérül: verziózza a teljes megfelelőségi beállítást egyetlen egységként. A HotPDF kiadását, a sablon revízióját, az ICC-profil ellenőrzőösszegét, az ellenőrző azon változatát, amely rábólintott. A megfelelőség abban a pillanatban elcsúszik, amikor bármelyikük megváltozik a többi alatt, és a legcsúfabb auditok azok, ahol senki sem tudja rekonstruálni, melyik kombináció állított elő egy ötéves archívumfájlt. Kötegenként egyetlen beállítási feljegyzés ezt véglegesen rendezi

Végül: az ellenőrzőt valódi éles kimeneten futtassa, soha ne rendezett, kézzel épített mintán. A harapós hibák olyan adatokból jönnek, amelyekre senki sem számított: egy ügyfélembléma CMYK formában érkezik, miközben a szándék RGB értéket mond, egy sablonmódosítás beenged egy be nem ágyazott betűkészletet, egy új kódút a címkefán kívülre rajzol szöveget. Tartson meg minden korábbi eseményből egy ismerten rossz fájlt visszalépési bemenetként, és a megfelelőségi kapu idővel is becsületes marad. Ezeknek a munkafolyamatoknak a rajzolási oldalához lásd a jelentéskimenetről, a betűkészletekről és a képekről szóló cikkünket a HotPDF alatt; az ellenőrzők fordítási folyamatba drótozásához pedig van egy társcikk a PDF-előellenőrzések automatizálásáról

Az ezekben a példákban használt megfelelőségi tulajdonságok, kimeneti szándékok és címkézési API a HotPDF Delphi Component részeként érkezik, Delphihez és C++Builderhez; a termékoldal minden itt bemutatott híváshoz hivatkozik a teljes leírásra