PDF/E-1 inžineriniai dokumentai Delphi su PDFlibPas

PDF/E-1 yra archyvinis inžinerinių dokumentų profilis, o PDFlibPas jį realizuoja kaip autoriaus režimą, kurį įjungiate su SetPDFEMode, plius apribotą preflight, skaitantį turinio srautus operatorių po operatoriaus. Šis profilis nėra PDF/A su kita etikete: jis turi savą identifikacijos vardų erdvę, savą gyvavimo ciklo metaduomenų reikalavimą ir vieną taisyklę, kuri turinio tikrinimą daro griežtesnį nei bet kuris jūsų matytas archyvinis profilis

Inžineriniai pristatymai yra priežastis, kodėl šis profilis egzistuoja. Brėžinių rinkinys, kuris po dvidešimt metų turi būti skaitomas ir įrodytai nepakitęs, su išlikusia peržiūrų istorija ir su spalva, kuri kitame pastate stovinčiame ploteryje reiškia tą patį. Tie reikalavimai duoda specifikaciją, kurios reikalavimai dažniausiai sėdi už puslapio turinio ribų — metaduomenyse ir spalvų valdyme, ir būtent ten universali PDF rašyklė juos sugadina

Sava identifikacija, o ne PDF/A atmaina

Pirmas dalykas, kurį reikia padaryti teisingai: PDF/E-1 identifikacijos negalima pagaminti pritaikius PDF/A arba PDF/X šabloną. Ji naudoja atskirą XMP vardų erdvę, http://www.aim.org/pdfe/ns/id/, o versijos reikšmė turi pasirodyti dviejose vietose: kaip dokumento informacijos įrašas ir kaip vardų erdvės kvalifikuota XMP savybė. Vienos XMP savybės arba vieno informacijos įrašo išdavimas duoda failą, kuris neša ketinimą, bet neišlaiko patikros

Išvesties ketinimas (output intent) turi lygiai tokį pat specifinį pavidalą. PDF/E-1 reikalauja įdėtojo ICC profilio su potipio identifikatoriumi ISO_PDFE1, o profilis turi turėti komponentų skaičių, atitinkantį įrenginio spalvų šeimą, kurią dokumentas iš tikrųjų naudoja. Ta paskutinė nuostata yra vieta, kur realizacijos tyčiomis klysta, nes ji reiškia, kad ketinimo negalima parinkti iš anksto ir po to pamiršti

Kodėl įrenginio spalvoms reikia viso dokumento apžvalgos?

Todėl, kad spalvų erdvės slepiasi išteklių žodynuose, kurių puslapio lygio skenavimas niekada nepasiekia. PDF/E-1 DeviceRGB ir DeviceCMYK laiko tarpusavyje nesuderinamomis dokumento šeimomis, todėl profilio patikrinimas reiškia žinoti kiekvieną įrenginio spalvų erdvę, kurią bet kas faile naudoja. Form XObject turi savus išteklius. Taip pat raštas (pattern) ir taip pat vaizdas. Sklaidos raštas form XObject viduje puslapio viduje yra trijų lygių gylyje, ir patikrintojas, žiūrintis tik į aukščiausio lygio puslapio išteklius, praleis dokumentą, naudojantį abi šeimas

Todėl apžvalga registruoja spalvų erdves pereidama puslapius, formas, vaizdus ir raštus kaip vieną praėjimą, ir tik tada nusprendžia, ar dokumentas nuoseklus, ir ar išvesties ketinimas atitinka. Tas pats mąstymas apskritai valdo preflight architektūrą: dalinė peržiūra duoda klaidingus išlaikymus, o klaidingas išlaikymas suderinamumo tikrinime yra blogesnis už jo nebuvimą, nes užregistruojamas kaip įrodymas

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

    // Autoriaus režimas kiekvieno išsaugojimo metu palaiko ciklo metaduomenis
    // Paklauskite prieš išsaugodami, ar dokumentas praeitų savo vartus
    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;

Gyvavimo ciklo metaduomenys yra pareiga prieš kiekvieną išsaugojimą

PDF/E-1 prašo daugiau nei dokumento identifikatoriaus. Mažiausias rinkinys apima medijos valdymo dokumento identifikatorių, versijos identifikatorių, atmainos klasę (rendition class), sukūrimo laiką, keitimo laiką, metaduomenų laiką ir pavadinimą. Tai peržiūrų sekimo žodynas, ir jis egzistuoja todėl, kad inžinerinis pristatymas turi būti perleidžiamas iš naujo, o ne parašomas vieną kartą

Realizacijai iš to seka, kad šių laukų negalima nustatyti kuriant dokumentą. Jei keitimo laikas užrašomas tada, kai įjungiate režimą, o dokumentas vėliau redaguojamas, XMP momentinė nuotrauka ir faktinė dokumento būsena išsiskiria, ir jas lyginantis patikrintojas praneša netyčinį nesuderinamumą. Autoriaus režimas todėl sinchronizuoja laukus tučtuojau prieš kiekvieną išsaugojimą, kad metaduomenys apibūdintų baitus, kurie tuoj bus užrašyti, o ne baitus, kurie buvo, kai režimas buvo įjungtas

Tai bendras principas suderinamumo metaduomenims ir verta jį išsakyti atskirai nuo PDF/E: išvestiniai metaduomenys priklauso išsaugojimo keliui, o ne redagavimo keliui. Bet kuris laukas, apskaičiuotas iš dokumento būsenos, turi būti perskaičiuotas tą akimirką, kai būsena užšąlama, kitaip jis yra podėlis be jokio atnaujinimo

Taisyklė, dėl kurios turinio patikra tampa griežta

PDF/E-1 neleidžia suderinamumo sekcijos operatoriams praryti nežinomo turinio. Paprastame PDF BX ir EX įrėmina sritį, kurioje vartotojas turi ignoruoti jam neatpažįstamus operatorius, ir tai yra gelbėjimosi liukas, leidžiantis gamintojui išleisti naujesnes konstrukcijas, nelaužant senesnių skaitytuvų. Po PDF/E-1 tas liukas uždarytas, todėl bet kuris preflight neatpažįstamas operatorius pranešamas nesąlygiškai, nesvarbu, ar jis sėdi suderinamumo sekcijoje

Poveikis patikrintojui reikšmingas. Jam negalima praleisti sričių, kurių jis nesupranta, o tai reiškia, kad operandų analizatorius turi realiai išanalizuoti kiekvieną kiekvieno turinio srauto operatorių. Čia ir atsiranda ribos. Praėjimas apribotas 128 įdėties lygiais, milijonu objektų ir 64 MiB turinio, ir tos ribos nėra joks našumo derinimas. Priešiškas ar tiesiog sugedęs failas gali pateikti objektų grafą su ciklais arba tokiu įdėties gyliu, kuris rekursyvų patikrintoją paverčia steko persipildymu, ir būtent ribos neleidžia patikros praėjimui tapti paslaugų atakos (denial-of-service) vektoriumi. Ta pati gynybinė laikysena aprašyta straipsnyje nepatikimų PDF saugus analizavimas

// Atskira failo, kurio patys negaminote, patikra, neįkeliant jo
// į dokumento egzempliorių
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;

Ką išsaugojimo vartai remontuoja ir ką atmeta

Vartai savo darbą skaido į du etapus, ir tas skaidymas pats savaime yra pravertantis projektavimo sumanymas. Pirmiausia jis normalizuoja tai, kas saugiai remontuojama: anotacijų spausdinimo vėliavas, tekstinių anotacijų be-zoom ir be-sukimo vėliavas ir išvaizdos generavimo vėliavą formos žodyne. Tai nustatymai su viena teisinga reikšme po šiuo profiliu ir be jokio informacinio turinio, todėl juos taisyti tyčiomis yra teisinga, o atsisakyti dėl jų būtų pedanterija

Tada jis tikrina apribojimus, kurių negalima remontuoti nekeičiant to, ką dokumentas reiškia: versiją, identifikaciją, šifravimą, išvesties ketinimą, įrenginio spalvų nuoseklumą ir dinaminio formos turinio buvimą. Dokumentas, žlugstantis bet kuriame iš jų, atmetamas, nes išgalvotas išvesties ketinimas arba autoriaus vardu parinkta spalvų šeima duotų failą, kuris praeitų patikrą ir iškraipytų turinį

Diagnostikos perskaitymas per GetPDFEDiagnostics prieš išsaugojimą tą atmetimą paverčia veiksmingu sąrašu, o ne žlugusia operacija. Paketiniame konvejeryje kviesti ją kiekvienam dokumentui, užrašyti kliūtis kiekvienam failui ir nukreipti nesėkmes į eilę, kurią žiūri žmogus. Tai daug naudingiau už išsaugojimą, keliantį klaidą, nes kliūtys paprastai telkiasi: keturiasdešimt dokumentų, žlugstančių dėl tos pačios trūkstamos išvesties ketinimo, yra vienas sutvarkymas, o ne keturiasdešimt

Renkantis tarp archyvinių profilių

PDF/E-1 yra teisingas taikinys, kai pristatymas yra inžinerinė dokumentacija su peržiūrų ciklu, ir ypač kai įrenginio spalvų nuoseklumas svarbus, nes išvestis keliauja į ploterius ir didelio formato spausdintuvus. PDF/A yra teisingas taikinys, kai tikslas yra bendras dokumentų ilgaamžiškumas, ir tai profilis su plačiausiu patikrintojų palaikymu. Šie du nėra tarpusavyje keičiami, ir dokumentas gali tenkinti vieną ir žlugti kitame

Jei renkatės, pradėkite nuo to, kas failą tikrina kitame gale. PDF/A patikros įrankių yra visur, o atitinkamas PDFlibPas preflight aprašytas straipsnyje PDF/A ir PDF/UA preflight. PDF/E patikra specifiškesnė ir paprastai yra sutartinis reikalavimas, o ne numatytoji padėtis. Kai esamą archyvą tenka pakelti iki profilio, kuriam jis niekada nebuvo rašytas, metaduomenų remonto kelias iš straipsnio konvertavimas į PDF/A su metaduomenų remontu yra modelis, kurio laikytis, ir čia taikoma ta pati forma: identifikuoti, remontuoti tai, kas saugu, likusį atsisakyti su sąrašu

Autoriaus režimas, apribotas turinio preflight ir atskira suderinamumo patikra visi keliauja su PDFlibPas Delphi PDF biblioteka, todėl dokumentas gali būti pagamintas pagal profilį ir vėliau nepriklausomai patikrintas atskiru kodo keliu — vienintelis išdėstymas, kurį verta pasitikėti teigiant suderinamumą