PDF/E-1-suunnitteludokumentit Delphissa PDFlibPasilla

PDF/E-1 on suunnitteludokumenttien arkistointiprofiili, ja PDFlibPas toteuttaa sen tekijätilana, jonka kytkee päälle SetPDFEMode-kutsulla, sekä rajattuna esitarkastuksena, joka lukee sisältövirrat operaattori kerrallaan. Profiili ei ole PDF/A eri etiketillä: sillä on oma tunnistenimiavaruutensa, oma elinkaarimetadatavaatimuksensa ja yksi sääntö, joka tekee sisällön validoinnin tiukemmaksi kuin yksikään arkistointiprofiili, jonka olet tavannut

Suunnittelualan toimitukset ovat syy, miksi profiili on olemassa. Piirustuskokoelma, jonka on oltava luettava ja todistettavasti muuttumaton kahdenkymmenen vuoden päästä, säilyvällä revisiohistorialla ja värillä, joka tarkoittaa samaa toisen rakennuksen plotterilla. Nämä vaatimukset tuottavat spesifikaation, jonka vaatimukset asuvat pääosin sivusisällön ulkopuolella, metadatassa ja värinhallinnassa, ja juuri siinä geneerinen PDF-kirjoittaja mokaa

Oma tunnistautuminen, ei PDF/A:n variaatio

Ensimmäinen oikein saatava asia on, ettei PDF/E-1-tunnistautumista voi tuottaa sovittamalla PDF/A- tai PDF/X-kaavaa. Se käyttää erillistä XMP-nimiavaruutta, http://www.aim.org/pdfe/ns/id/, ja versioarvon on ilmestyttävä kahteen paikkaan: dokumenttitietomerkintänä ja nimiavaruusmääritettynä XMP-ominaisuutena. Vain XMP-ominaisuuden tai vain tietomerkinnän emittoiminen tuottaa tiedoston, joka kantaa aietta ja kaatuu validoinnissa

Output intentilla on yhtä tarkka muoto. PDF/E-1 vaatii upotetun ICC-profiilin alatyyppitunnisteella ISO_PDFE1, ja profiilin komponenttimäärän on vastattava sitä laitevärisukua, jota dokumentti todella käyttää. Tuo viimeinen lauseke on paikka, jossa toteutukset mokaavat hiljaa, koska se tarkoittaa, ettei output intentia voi valita etukäteen ja sitten unohtaa

Miksi laiteväri tarvitsee koko dokumentin kattavan läpikäynnin?

Koska väriavaruudet kätkeytyvät resurssisanakirjoihin, joihin sivutason skannaus ei koskaan yletä. PDF/E-1 kohtelee DeviceRGB:tä ja DeviceCMYK:ta toisensa poissulkevina sukuina dokumentissa, joten profiilin validoiminen tarkoittaa kaikkien niiden laiteväriavaruuksien tuntemista, joita tiedoston sisältö käyttää. Form XObjectilla on omat resurssinsa. Sama pätee kuvioon ja kuvaan. Sivun sisällä olevan form XObjectin sisällä oleva tiling-kuvio on kolmen tason syvyydellä, ja vain ylimmän tason sivuresursseja tarkistava validointi päästää läpi dokumentin, joka käyttää molempia sukuja

Läpikäynti rekisteröi siis väriavaruudet kulkiessaan sivujen, formien, kuvien ja kuvioiden läpi yhtenä kulkuna, ja vasta sen jälkeen päättää, onko dokumentti koherentti ja täsmääkö output intent. Sama päättely ohjaa esitarkastuksen arkkitehtuuria yleisemmin: osittainen läpikäynti tuottaa vääriä läpipääsyjä, ja väärä läpipääsy yhteensopivuustarkistuksessa on pahempi kuin ei tarkistusta lainkaan, koska se kirjataan näytöksi

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');

    // Tekijätila pitää elinkaarimetadatan ajan tasalla joka tallennuksella.
    // Kysy ennen tallennusta, läpäisisi dokumentti oman porttinsa
    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;

Elinkaarimetadata on jokaisen tallennuksen velvoite

PDF/E-1 pyytää enemmän kuin dokumenttitunnisteen. Vähimmäisjoukkoon kuuluvat mediahallinnan dokumenttitunniste, versiotunniste, rendition-luokka, luontiaika, muutosaika, metadatan aika ja otsikko. Kyseessä on revisioseurannan sanasto, ja se on olemassa, koska suunnittelutoimituksen odotetaan tulevan uudelleen julkaistavaksi eikä kertaalleen kirjoitetavaksi

Seuraus toteutukselle on, ettei näitä kenttiä voi asettaa dokumentin luonnin yhteydessä. Jos muutosaika kirjoitetaan, kun kytket tilan päälle, ja dokumentia muokataan sen jälkeen, XMP-snapshot ja dokumentin todellinen tila ovat ajautuneet erilleen, ja niitä vertaileva validointi raportoi ristiriidan, jota kukaan ei aikonut. Tekijätila synkronoi siksi kentät heti ennen jokaista tallennusta, joten metadata kuvaa kirjoitettavaksi tulevia tavuja, eikä niitä tavuja, jotka olivat olemassa, kun tila kytkettiin päälle

Tämä on yleinen periaate yhteensopivuusmetadatalle, ja se kannattaa sanoa erikseen PDF/E:stä: johdettu metadata kuuluu tallennuspolulle, ei muokkauspolulle. Kenttä, joka lasketaan dokumentin tilasta, on laskettava uudelleen sillä hetkellä, kun tila jäädytetään, tai se on välimuisti ilman mitään mitätöintiä

PDFlibPasin PDF/E-1 -kaavio koko dokumentin laitevärin läpikäynnistä, joka kulkee sivujen, form XObjectien, tiling-kuvioiden ja kuvien resurssisanakirjojen läpi keräten DeviceRGB- ja DeviceCMYK-suvut ennen koherenssin arviota, rinnalla elinkaarimetadatan kentät, jotka tekijätila synkronoi uudelleen heti ennen jokaista tallennusta, jotta XMP-snapshot täsmää kirjoitettavaksi tuleviin tavuihin — Värikoherenssin voi arvioida vasta, kun yksi läpikäynti ylettää jokaiseen resurssisanakirjaan, ja johdettu elinkaarimetadata lasketaan uudelleen sillä hetkellä, kun dokumentin tila jäädytetään, ei silloin, kun tila kytketään päälle

Sääntö, joka tekee sisällön validoinnista tiukkaa

PDF/E-1 ei salli yhteensopivuusosion operaattoreiden nielaista tuntematonta sisältöä. Tavallisessa PDF:ssä BX ja EX rajaavat alueen, jossa kuluttajan on ohitettava tunnistamattomat operaattorit, ja se on pakkotie, joka päästää tuottajan emittoimaan uudempia rakenteita rikkomatta vanhempia lukijoita. PDF/E-1:n alla tuo pako on suljettu, joten jokainen esitarkastuksen tunnistamaton operaattori raportoidaan ehdottomasti, riippumatta siitä, istuuko se yhteensopivuusosion sisällä

Vaikutus validointiin on merkittävä. Se ei voi ohittaa alueita, joita ei ymmärrä, mikä tarkoittaa, että operandijäsentäjän on oikeasti jäsenettävä jokainen operaattori jokaisesta sisältövirrasta. Siinä rajat tulevat kuvaan. Läpikäynti katkaistaan 128 sisäkkäisyystasoon, miljoonaan objektiin ja 64 MiB sisältöön, eikä nuo rajat ole suorituskyvyn hienosäätöä. Vihamielinen tai pelkästään rikki oleva tiedosto voi esittää objektigraafin sykleillä tai sellaisella sisäkkäisyyssyvyydellä, joka kääntää rekursiivisen validoinnin pinoylivuodoksi, ja rajat ovat se, mikä estää validointikierrosta muuttumasta palvelunestohyökkäyksen väyläksi. Sama puolustusasenne on kuvattu artikkelissa epäluotettavien PDF-tiedostojen turvallinen jäsennys

// Erillinen validointi tiedostolle, jota et itse tuottanut, ilman
// lataamista dokumenttiinstanssiin
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ä tallennusportti korjaa ja mistä se kieltäytyy

Portti jakaa työnsä kahteen vaiheeseen, ja jako on itsessään käyttökelpoinen suunnitteluidea. Ensin se normalisoi turvallisesti korjattavat asiat: annotaatioiden tulostusliput, tekstiannotaatioiden no-zoom- ja no-rotate-liput sekä formisanakirjan ulkoasun luontilipun. Nämä ovat asetuksia, joilla on yksi oikea arvo profiilin alla eikä mitään informaatiosisältöä, joten niiden hiljainen korjaaminen on oikein, ja niiden yli kieltäytyminen olisi pedanttia

Sitten se tarkistaa rajoitteet, joita ei voi korjata muuttamatta sitä, mitä dokumentti tarkoittaa: versio, tunnistautuminen, salaus, output intent, laitevärin koherenssi ja dynaamisen formisisällön läsnäolo. Dokumentti, joka kaatuu mihin tahansa niistä, hylätään, koska output intentin keksiminen tai värisuvun valitseminen tekijän puolesta tuottaisi tiedoston, joka läpäisee validoinnin ja vääristää sisältöä

PDFlibPasin PDF/E-1 -tallennusportin kaavio Delphille: rajattu esitarkastus, joka skannaa jokaisen sisältövirran operaattorin 128 sisäkkäisyystason, miljoonan objektin ja 64 MiB kattavuuden sisällä, korjaa hiljaa annotaatioiden tulostus-, zoom- ja kiertosliput, hylkää väärän version, tunnistautumisen, salauksen, output intentin, laitevärin tai dynaamisen formisisällön ja raportoi esteet GetPDFEDiagnosticsin kautta — Portti korjaa hiljaa vain sen, mikä ei kanna informaatiota, hylkää jokaisen rajoitteen, jonka korjaus vääristäisi, ja muuttaa hylkäämisen esteluetteloksi GetPDFEDiagnosticsin kautta ennen kuin yksikään tavu ehtii levylle

Diagnostiikan lukeminen takaisin GetPDFEDiagnosticsia käyttäen ennen tallennusta muuttaa hylkäämisen toimintakelpoiseksi luetteloksi epäonnistuneen operaation sijaan. Eräputkessa kutsu sitä jokaiselle dokumentille, kirjaa esteet tiedostokohtaisesti ja ohjaa epäonnistumiset jonoon, jota ihminen katsoo. Se on paljon hyödyllisempää kuin tallennus, joka nostaa poikkeuksen, koska esteet klusteroutuvat yleensä: neljänkymmenen dokumentin kaatuminen saman puuttuvan output intentin takia on yksi korjaus, ei neljäkymmentä

Valinta arkistointiprofiilien välillä

PDF/E-1 on oikea kohde, kun toimitus on revisioelinkaaren omaavaa suunnitteludokumentaatiota, ja erityisesti silloin, kun laitevärin koherenssi merkitsee, koska tuloste menee plottereille ja suurformaatin tulostimille. PDF/A on oikea kohde, kun tavoite on dokumenttien yleinen pitkäaikainen luettavuus, ja se on profiili, jolla on laajin validointituki. Kaksi ei ole vaihdettavissa keskenään, ja dokumentti voi täyttää toisen ja kaatua toiseen

Aloita siitä, kuka validoi tiedoston ketjun päähän asti: profiilit vaativat eri tunnistautumista, metadataa ja väritakuita, ja dokumentti voi täyttää toisen kaatuessaan toiseen

Jos olet valitsemassa, aloita siitä, kuka validoi tiedoston ketjun päähän asti. PDF/A-validointityökaluja on kaikkialla, ja vastaava esitarkastus PDFlibPasissa on kuvattu artikkelissa PDF/A- ja PDF/UA-esitarkastus. PDF/E-validointi on erikoisempaa ja yleensä sopimusvaatimus eikä oletus. Kun olemassa oleva arkisto on saatava profiilin tasolle, jolle sitä ei koskaan kirjoitettu, artikkelin PDF/A-muunnos metadatan korjauksella metadatankorjauspolku on kaava, jota seurata, ja sama muoto pätee täällä: tunnista, korjaa se mikä on turvallista, hylkää loput luettelolla

Tekijätila, rajattu sisällönesitarkastus ja erillinen yhteensopivuustarkistus toimituvat kaikki PDFlibPas Delphi PDF -kirjaston mukana, joten dokumentin voi tuottaa profiilin alla ja varmistaa itsenäisesti jälkikäteen erillisen koodipolun kautta, mikä on ainoa järjestely, johon yhteensopivuusväitteen kohdalla kannattaa luottaa