A PDF/E-1 a mérnöki dokumentumok archiválási profilja, és a PDFlibPas úgy valósítja meg, mint egy szerzői módot, amelyet a SetPDFEMode-bal kapcsol be, plusz egy határolt preflightot, amely operátoronként olvassa a tartalomstream-eket. A profil nem PDF/A másik címkével: saját azonosító névtere van, saját életciklus-metaadat követelménye, és egy szabálya, amely a tartalomérvényesítést szigorúbbá teszi, mint bármely eddigi archiválási profil
A mérnöki leszállítandók miatt létezik a profil. Egy rajzkészletnek húsz év múlva is olvashatónak kell lennie, bizonyíthatóan változatlanul, fennmaradó revíziótörténettel, és olyan színnel, amely a másik épületben álló plotteren ugyanazt jelenti. Ezek a követelmények olyan specifikációt eredményeznek, amelynek az igényei nagyrészt az oldaltartalomon kívül ülnek, a metaadatokban és a színkezelésben, és pontosan itt téved el az általános PDF író
Saját azonosítás, nem a PDF/A variációja
Az első dolog, amit el kell találni, hogy a PDF/E-1 azonosítás nem gyártható a PDF/A vagy PDF/X minta átalakításával. Külön XMP névteret használ, a http://www.aim.org/pdfe/ns/id/ nevteret, és a verzióértéknek két helyen kell szerepelnie: dokumentuminformációs bejegyzésként és névtér-minősített XMP tulajdonságként. Csak az XMP tulajdonság, vagy csak az információs bejegyzés kiírása olyan fájlt ad, amely viseli a szándékot, és elbukik az érvényesítésen
A kimeneti szándéknak ugyanilyen specifikus alakja van. A PDF/E-1 beágyazott ICC profilt követel meg ISO_PDFE1 altípusazonosítóval, és a profil komponensszámának egyeznie kell azzal az eszközszín-családdal, amelyet a dokumentum ténylegesen használ. Ez az utolsó záradék az, ahol az implementációk csendben elhibázzák, mert azt jelenti, hogy a szándékot nem lehet előre kiválasztani, aztán elfelejteni
Miért igényel az eszközszín teljes dokumentumot bejáró vizsgálat?
Mert a színterek olyan erőforrás-szótárakban rejtőznek, ahová egy oldalszintű vizsgálat sosem jut el. A PDF/E-1 a DeviceRGB és a DeviceCMYK családokat kölcsönösen kizárónak tekinti egy dokumentumon belül, tehát a profil érvényesítése azt jelenti, hogy tudni kell a fájl bármije által használt minden eszközszíntérről. A form XObjectnak saját erőforrásai vannak. Ugyanígy a mintázatnak, és ugyanígy a képnek. Egy oldalba ágyazott form XObjectba ágyazott tiling mintázat három szint mélyen van, és egy csak a legfelső szintű oldal-erőforrásokat ellenőrző érvényesítő átenged egy dokumentumot, amely mindkét családot használja
A bejárás ezért egyetlen végigjárásként járja a lapokat, formokat, képeket és mintázatokat, közben jegyzi a színtereket, és csak utána dönti el, hogy a dokumentum koherens-e, és hogy a kimeneti szándék egyezik-e. Ugyanez a gondolkodás hajtja általában a preflight architektúrát: a részleges bejárás hamis megfelelést ad, és egy megfelelőségvizsgálaton kapott hamis megfelelés rosszabb, mint a vizsgálat hiánya, mert bizonyítékként rögzítik
var
Lib: TPDFlib;
Diag: WideString;
begin
Lib := TPDFlib.Create(nil);
try
Lib.LoadFromFile('assembly-drawings.pdf');
if Lib.SetPDFEMode(1) = 0 then
raise Exception.Create('PDF/E author mode was refused');
// A szerzői mód minden mentéskor szinkronban tartja az életciklus-metaadatot.
// Mentés előtt kérdezze meg, átmennék-e a dokumentum a saját kapuján
if not Lib.PDFEReadyForSave then
begin
Diag := Lib.GetPDFEDiagnostics;
Writeln('PDF/E blockers: ', Diag);
Exit;
end;
Lib.SaveToFile('assembly-drawings-pdfe.pdf');
finally
Lib.Free;
end;
end;Az életciklus-metaadat mentésenkénti kötelezettség
A PDF/E-1 többet kér egy dokumentumazonosítónál. A minimális készlet tartalmazza a médiakezelési dokumentumazonosítót, egy verzióazonosítót, egy rendition osztályt, a létrehozás idejét, a módosítás idejét, a metaadat idejét és egy címet. Ez egy revíziókövető szókincs, és azért létezik, mert egy mérnöki leszállítandótól azt várják, hogy újra kiadják, nem egyszer megírják
A következmény egy implementációra az, hogy ezeket a mezőket nem lehet dokumentumlétrehozáskor beállítani. Ha a módosítás ideje akkor íródik, amikor bekapcsolja a módot, és a dokumentum utána szerkesztődik, az XMP pillanatkép és a tényleges dokumentumállapot széttart, és egy őket összehasonlító érvényesítő olyan ellentmondást jelent, amelyet senki nem akart. A szerzői mód ezért minden mentés közvetlenül előtt szinkronizálja a mezőket, tehát a metaadat a kiírásra váró bájtokat írja le, nem azokat, amelyek a mód bekapcsolásakor léteztek
Ez általános elv a megfelelőségi metaadatokra, és érdemes a PDF/E-től függetlenül is kimondani: a származtatott metaadat a mentési útra való, nem a szerkesztési útra. Minden mezőt, amelyet a dokumentumállapotból számolnak, újra kell számolni abban a pillanatban, amikor az állapot befagy, különben ez egy érvénytelenítés nélküli cache
A szabály, amely szigorúvá teszi a tartalomérvényesítést
A PDF/E-1 nem engedi, hogy a kompatibilitási szakasz operátorai felfalják az ismeretlen tartalmat. Közönséges PDF-ben a BX és az EX közrefog egy olyan régiót, amelyben a fogyasztónak figyelmen kívül kell hagynia a fel nem ismert operátorokat, ez az a menekülőnyílás, amely lehetővé teszi, hogy a gyártó újabb szerkezeteket adjon ki régebbi olvasók törése nélkül. PDF/E-1 alatt ez a kijárat zárva, tehát minden operátort, amelyet a preflight nem ismer fel, feltétel nélkül jelent, attól függetlenül, hogy kompatibilitási szakaszban ül-e
A hatás egy érvényesítőre jelentős. Nem ugorhatja át a nem értett régiókat, ami azt jelenti, hogy az operanduselemzőnek ténylegesen elemeznie kell minden operátort minden tartalomstreamben. Itt jönnek képbe a határok. A bejárás 128 beágyazási szintre, egymillió objektumra és 64 MiB tartalomra van korlátozva, és ezek a korlátok nem teljesítményhangolás. Egy ellenséges vagy csupán sérült fájl olyan objektumgráfot mutathat, amely ciklusokat tartalmaz, vagy olyan beágyazási mélységgel bír, amely a rekurzív érvényesítőt stack overflowba kergeti, és a korlátok azok, amelyek megakadályozzák, hogy egy érvényesítési menet denial-of-service vektorrá váljon. Ugyanezt a védekező álláspontot írja le a nem megbízható PDF-ek biztonságos elemzése
// Különálló érvényesítés egy olyan fájlon, amelyet Ön nem állított
// elő, anélkül, hogy dokumentumpéldányba töltené
var
Issues: TStringList;
Stream: TFileStream;
I: Integer;
begin
Issues := TStringList.Create;
Stream := TFileStream.Create('incoming.pdf', fmOpenRead or fmShareDenyWrite);
try
if CheckCompliancePDFE(Stream, '', 0, Issues) = 0 then
for I := 0 to Issues.Count - 1 do
Writeln('PDF/E: ', Issues[I]);
finally
Stream.Free;
Issues.Free;
end;
end;Mit javít meg a mentési kapu, és mit utasít el?
A kapu két szakaszra bontja a munkáját, és ez a bontás önmagában is használható tervezési ötlet. Először normalizálja azokat a dolgokat, amelyek biztonságosan javíthatók: a megjegyzés nyomtatási zászlóit, a szöveges megjegyzések nincs-nagyítás és nincs-forgatás zászlóit, és a megjelenés-előállítás zászlóját a form szótáron. Ezek olyan beállítások, amelyeknek a profil alatt egy helyes értékük van és nincs információtartalmuk, tehát csendes javításuk helyes, és rajtuk való elutasítás pedantéria volna
Aztán ellenőrzi azokat a megszorításokat, amelyek a dokumentum jelentésének megváltoztatása nélkül nem javíthatók: verzió, azonosítás, titkosítás, kimeneti szándék, eszközszín-koherencia és a dinamikus formatartalom jelenléte. A valamelyiken elbukó dokumentumot elutasítja, mert egy kimeneti szándék kitalálása vagy egy színcsalád megválasztása a szerző nevében olyan fájlt adna, amely átmegy az érvényesítésen, és félreábrázolja a tartalmat
A diagnosztika visszaolvasása a GetPDFEDiagnostics-szal mentés előtt az elutasítást cselekvhető listává teszi, nem megbukott műveletté. Egy batch folyamatsorban hívja meg minden dokumentumon, naplózza a blokkolókat fájlonként, és a hibákat irányítsa egy olyan sorba, amelyet ember néz. Ez sokkal hasznosabb, mint egy kivételt dobó mentés, mert a blokkolók általában csoportosulnak: negyven dokumentum, amely ugyanazon hiányzó kimeneti szándékért bukik meg, egy javítás, nem negyven
Választás az archiválási profilok között
A PDF/E-1 a helyes cél, amikor a leszállítandó revízió életciklusú mérnöki dokumentáció, és konkrétan akkor, amikor az eszközszín-koherencia számít, mert a kimenet plotterekre és nagyformátumú nyomtatókra megy. A PDF/A a helyes cél, amikor a cél általában a dokumentumok hosszú távú olvashatósága, és ez az a profil, amelyet a legszélesebb körben támogatnak az érvényesítők. A kettő nem felcserélhető, és egy dokumentum teljesítheti az egyiket, és megbukhat a másikon
Ha választania kell, induljon ki abból, ki érvényesíti a fájlt a távoli végén. A PDF/A érvényesítő eszközök mindenhol ott vannak, és a PDFlibPasban lévő megfelelő preflightot a PDF/A és PDF/UA preflight írja le. A PDF/E érvényesítés specializáltabb, és általában szerződéses követelmény, nem alapértelmezés. Amikor egy meglévő archívumot fel kell hozni egy profilhoz, amelyre sosem írták, a PDF/A-ra konvertálás metaadatjavítással cikk metaadatjavítási útja a követendő minta, és itt is ugyanez az alak érvényes: azonosítson, javítsa, ami biztonságos, a többit utasítsa el listával
A szerzői mód, a határolt tartalom-preflight és a különálló megfelelőségvizsgálat a PDFlibPas Delphi PDF könyvtárral együtt jár, tehát a dokumentum előállítható a profil alatt, és utána függetlenül is ellenőrizhető egy külön kódúton, ami az egyetlen elrendezés, amelyet egy megfelelőségi állításnál érdemes megbízni