PDF preflight ellenőrzések automatizálása Delphi-ben HotPDF-fel

A fájl az Ön gépén rendben megnyílik. Az Acrobat megjeleníti, a nyomtatási előnézet jónak látszik, minden oldal a helyén van. Aztán elmegy a nyomdába vagy abba az archiválórendszerbe, amely a havi kötegét beveszi, és visszajön elutasítva: RGB képek egy CMYK munkában, hiányzó /Trapped kulcs, a géphez nem illő kimeneti szándék. Semmi nem volt hibás a dokumentumban, amit bárki láthatott volna. Egy profillal szemben volt hibás, és a profilt olyan helyen ellenőrizték, ahol Ön nem volt jelen. A preflight a nyomdai előkészítés neve erre az ellenőrzésre, az igazi kérdés pedig az, hova tartozik akkor, amikor a PDF-ek a saját Delphi-kódjából jönnek ki, nem pedig egy tervező asztaláról

A HotPDF nem ad hívható preflight-függvényt. A komponens GUI-demója tartalmaz egy preflight-jelentés ablakot, de nincs mögötte olyan API, amelyet egy szolgáltatás vagy egy buildszkript meghívhatna, és ennek elhallgatása csak egy nem létező metódus keresésére küldené Önt. Ez hiánynak hangzik, amíg észre nem veszi, hogy a saját maga által generált fájloknál a validátor futtatása a saját kimenetén amúgy is rossz forma. Minden olyan tulajdonságot Ön szab meg, amelyet egy validátor megvizsgálna. A hasznos felosztás az, hogy a generátort képtelenné teszi rossz fájl kibocsátására, majd ezt olyan eszközzel bizonyítja, amelyet nem Ön írt

Miért másképp ellenőrzi a saját kimenetét

A hagyományos preflight idegen fájlt feltételez. Valamelyik tervező, valamelyik másik alkalmazás, valamilyen ismeretlen szerkesztési lánc állította elő, és azért vizsgálja meg, mert fogalma sincs, mi van benne. A saját kódja által előállított dokumentum nem idegen. A betűkészletek beágyazása, a színtér, a kimeneti szándék, a metaadatblokk: mindezt a programja döntötte el néhány ezredmásodperccel azelőtt, hogy a fájl lemezre került. Utólag megvizsgálni, hogy felfedezze az imént meghozott döntéseket, felesleges körözés. Az olcsóbb lépés az, hogy megszorítja ezeket a döntéseket, így nem megfelelő fájl soha nem is jön létre, amelyet el kellene kapni

A külső ellenőrzés fenntartásának hitelességi oka is van. Az a könyvtár, amely a saját kimenetét áldja meg, a saját dolgozatát javítja. Amikor egy ügyfél archiválórendszere vagy egy nyomda RIP-je visszautasítja a fájlját, annak, hogy „a komponensünk szerint rendben van”, semmi súlya nincs. A veraPDF vagy az Acrobat ítéletének van, mert a túloldal ugyanazokat az eszközöket futtatja

A megfelelőség legyen beállítás, ne ellenőrzőlista

A megelőző réteg puszta konfiguráció. Állítsa be a PDFACompliance vagy a PDFXCompliance tulajdonságot a BeginDoc előtt, és a HotPDF a teljes generálási menetre tartja a hozzá tartozó szabályokat: beágyazza a betűkészleteket, figyeli a DeviceRGB és a DeviceCMYK használatát a bejelentett kimeneti szándékhoz képest, és megtagadja a profil által tiltott lehetőségeket. Az ellentmondások az EndDoc hívásnál bukkannak elő, ahol a megfelelőségi kapuk hibát jeleznek ahelyett, hogy csendben kiszállítanának valamit, ami később elbukik. Mentés után ugyanezek a tulajdonságok visszaolvassák, mi lett ténylegesen kikényszerítve – és éppen erre az egy tényre van a leginkább szüksége a feldolgozósor naplójának:

// EndDoc után: jegyezd fel a kikényszerített profilokat a futás metaadataival
if Pdf.PDFACompliance <> '' then
  Log('Generated as PDF/A level ' + Pdf.PDFACompliance);
if Pdf.PDFXCompliance <> '' then
  Log('Generated as PDF/X profile ' + Pdf.PDFXCompliance);

Tegye ezeket a jelzőket ugyanarra a naplósorra, mint a bemeneti adat kivonatát és a HotPDF verzióját. Azon a napon, amikor egy validátor és a generátora nem ért egyet egy fájlról, ez a sor mondja meg, melyik sablon állította elő és a könyvtár melyik buildje volt betöltve, és az a vita, amely különben elvinne egy délutánt, egyetlen kereséssé zsugorodik. Az e jelzők mögött álló kimeneti szándékokat, ICC-profilokat és címkézést a HotPDF PDF/A-, PDF/X- és PDF/UA-kimenetéről szóló útmutató részletezi

Olcsó első kapu a nem Ön által generált fájlokhoz

Nem minden feldolgozósor tisztán generatív. Az ügyfelek PDF-eket töltenek fel, a lapolvasók mappába dobják őket, a partnerek e-mailhez csatolják. Ha mindegyiket teljes szerkezeti validátoron hajtja át, azzal olyan fájlokra pazarol sorbanállási időt, amelyek meg sem nyílnak. A HotPDF Direct File API-ja épp annyit olvas be egy fájl szerkezetéből, hogy megválaszolja a „használható PDF ez egyáltalán” kérdést anélkül, hogy betöltené a teljes objektumfát, és ettől jó hely a gyors elbukásra:

function TriagePdf(Pdf: THotPDF; const FileName: string): Boolean;
var
  Handle, Pages: Integer;
begin
  Result := False;
  Handle := Pdf.DAOpenFileReadOnly(FileName, '');
  if Handle <= 0 then
    Exit;  // szerkezetileg olvashatatlan: karanténba, ne validáld
  try
    Pages := Pdf.DAGetPageCount(Handle);
    Result := Pages > 0;
  finally
    Pdf.DACloseFile(Handle);
  end;
end;

Két tény dönti el, hogyan burkolja be ezt az API-t. A lapos memóriájú gyorsítás csak titkosítatlan bemenetre áll fenn; adjon jelszót a DAOpenFileReadOnly hívásnak, és az csendben visszaesik teljes elemzésre, tehát egy olyan fájlt, amelyről tudja, hogy titkosított, a DecryptFile hívással érdemes sima munkapéldánnyá tenni a szűrés előtt. A DAGetPageCount pedig semmit nem jelent olyan leírón, amely nem nyílt meg rendben, ezért a leíró ellenőrzése szigorú marad, és a nem pozitív eredmény elutasítás, nem újrapróbálkozás. Több ilyen mintát a nagy PDF-munkamenetekhez készült Direct File API-cikk tartalmaz

veraPDF a build részeként futtatva

Bármire, amiről azt állítja, hogy PDF/A vagy PDF/UA, a veraPDF az a validátor, amelyet be kell kötni. Fejetlenül fut, köteget fogad, XML-t vagy JSON-t bocsát ki, és minden hibát az ISO-beli szakaszával nevez meg, így az ISO 19005-1 6.2.2 szakasza elleni szabálysértés egyenesen egy generátorbeállításra mutat vissza, ahelyett hogy találgatásra hagyná. A Delphiből való hajtása egyszerű folyamatvezérlés:

function RunVeraPdf(const PdfFile, ReportFile: string): Cardinal;
var
  Cmd: string;
  SI: TStartupInfo;
  PI: TProcessInformation;
begin
  Cmd := Format('cmd /c verapdf.bat --format xml "%s" > "%s"',
    [PdfFile, ReportFile]);
  FillChar(SI, SizeOf(SI), 0);
  SI.cb := SizeOf(SI);
  if not CreateProcess(nil, PChar(Cmd), nil, nil, False,
      CREATE_NO_WINDOW, nil, nil, SI, PI) then
    RaiseLastOSError;
  try
    WaitForSingleObject(PI.hProcess, 120000);  // fájlonként korlátozott várakozás
    GetExitCodeProcess(PI.hProcess, Result);
  finally
    CloseHandle(PI.hThread);
    CloseHandle(PI.hProcess);
  end;
end;

Ez az időkorlát megtermeli az árát. Egy hibás felépítésű fájl bármelyik elemzőt olyan sarokba hajthatja, ahonnan soha nem jön ki, és egy sorkezelő munkaegységen belüli nyitott végű várakozás magával rántja a sor többi részét is. Korlátozza a várakozást, adjon az időtúllépésnek saját hibakódot, és tegye félre a fájlt egy embernek. Az eredmény olvasásakor szabályazonosítókra elemezze az XML-t, ne az emberi olvasásra szánt szövegre. A szabályazonosítók túlélik a validátorfrissítéseket, az üzenetek szövege nem, és egy stabil kód az, amire egy támogatási mérnök rákereshet a régi jegyekben

Az, hogyan futtatja a köteget, ugyanannyit számít, mint az, hogy az egyes fájlok átmennek-e. Fájlonként egy folyamat, ne kötegenként, hogy egy mérgező bemenet csak annak az egy fájlnak az időtúllépésébe kerüljön, semmi többe. A validátorfolyamatok számát a magok számánál zárja le, mert az XML-jelentés felépítése CPU-korlátos, a túljegyzés pedig csak vergődik. És tegyen méretplafont a beérkezésre, mert egy kétgigabájtos beolvasott könyv birtokba veszi a sort, bármilyen türelmes is az elemző. Ezek egyike sem preflight szigorú értelemben. Ez a különbség egy olyan kapu között, amely túléli a hónap végi mennyiséget, és egy olyan között, amelyet kikapcsolnak az első éjszakán, amikor hajnali 2-kor megakasztja a feldolgozósort

A PDF/X az a pont, ahol ez kevésnek bizonyul. A veraPDF nem validálja, tehát a működő ellenőrzés továbbra is az Acrobat Preflight funkciója azzal az ISO 15930 profillal, amelyet a nyomdája megnevezett. Az Acrobat embert kíván, ami mintavételt jelent teljes lefedettség helyett: egy új sablon első fájlját, plusz egy kis véletlen merítést minden kötegből, miközben az automatizált kapu mindent elintéz, ami ember nélkül elintézhető. Egy ténylegesen futó mintavételes ellenőrzés többet ér, mint egy örökre félkészen maradó teljes automatizálás

Olyan jelentés, amelyre egy év múlva is szüksége lesz

A preflight-kapu kétszer térül meg. Egyszer, amikor megállít egy rossz fájlt az ajtóban, és jóval később még egyszer, amikor valaki megkérdezi, miért engedtek át egy bizonyos fájlt. Ez a második pillanat az, amelynek meg kell szabnia a formátumot, mert ez az, ahol egy sovány jelentés magára hagyja. Minden ellenőrzött fájlnál őrizze meg a bemenet kivonatát, a generátor megfelelőségi jelzőit és könyvtárverzióját a fenti naplósorból, a validátor nevét és verzióját, a profilt, amellyel szemben ellenőrizték, az átment vagy megbukott eredményt, valamint a megbukott szabályok azonosítóit oldalszámmal ott, ahol a validátor megadja. Tárolja ezt a jelentést az általa leírt fájl mellett. Tegye külön rendszerbe, és azt a rendszert leszerelik, mielőtt az archívum, amelyet dokumentál, megszűnne

A kivételeket is le kell írni. Amikor egy ügyfél ragaszkodik olyan fájl kiszállításához, amelyet a kapu nem szeret, a válasz nem a szabály fellazítása mindenki számára. Rögzítse, ki hagyta jóvá ezt a fájlt, milyen alapon és milyen dátumig, majd csatolja ezt a felmentést a jelentéséhez. Az a felmentés, amelynek neve és lejárata van, olyan döntés, amelyet valaki birtokol. Az „ideiglenesen” kikommentezett ellenőrzés viszont incidens, amely a dátumára vár

Még egy szokás kifizetődik: amikor egy fájl megbukik, másolja be egy megnevezett regressziós mappába, mielőtt bárki hozzáérne. Szinte minden hibakeresésre érdemes preflight-probléma egyetlen konkrét bemenetre vezethető vissza, és azok a csapatok, amelyek megőrzik ezeket a bemeneteket, egy óra alatt javítják az ismétlődést, ahelyett hogy megvárnák, míg éles környezetben újra felbukkan. Az itt bemutatott megfelelőségi tulajdonságok és a Direct File API a Delphihez és C++Builderhez készült HotPDF Delphi Component részei, amelynek dokumentációja minden hívást teljes egészében lefed