Három könyvtár (library). Három különböző feladat. A rossz kiválasztása hetekig tartó megkerülő megoldásokba (workarounds) kerül Önnek, mind a három kiválasztása pedig – amikor csak egyre van szüksége – olyan karbantartási többletköltséget (maintenance overhead) okoz, amivel nem számolt. Íme egy közvetlen beszámoló arról, hogy mit csinál valójában az egyes losLab PDF könyvtárak, hová illeszkednek, és hol adják át a feladatot a testvéreiknek
HotPDF: PDF írása a semmiből Delphiben
A HotPDF egy natív VCL komponens PDF dokumentumok generálásához. Modellje imperatív és oldalközpontú (page-centric): létrehoz egy THotPDF példányt (instance), beállítja a dokumentum tulajdonságait, meghívja a BeginDoc-ot, rajzol a CurrentPage-re, szükség szerint hozzáad oldalakat, és lezárja az EndDoc-al. A sorrend számít, mert a BeginDoc a futása pillanatában véglegesíti (commits) a titkosítási szótárat (encryption dictionary) és a tömörítési beállításokat; bármit, amit ezen a ponton túl rendelnek hozzá, csendben figyelmen kívül hagy, ahelyett, hogy visszamenőleg (retroactively) alkalmazná
A rajzfelület lefedi a teljes PDF operátorkészletet Delphi szinten: TextOut pozicionált Unicode szöveghez, SetFont TrueType beágyazással, vektor primitívek (vonalak, Bezier-görbék, ellipszisek, téglalapok), képelhelyezés fájlból vagy memóriából, és vonalkód generálás (barcode generation). A koordináták pontokban (points) vannak megadva a bal alsó sarokból kiindulva úgy, hogy az Y felfelé növekszik, ami egyszer mindenkit megfog. A betűtípus-állapot (font state) nem éli túl az AddPage hívást, így egy SetFont hívás szükséges minden oldaltörés után
Az AcroForm mezők (fields) első osztályú polgárok. Szövegmezőket (text fields), jelölőnégyzeteket (checkboxes), rádiógombokat (radio buttons), kombinált listákat (combo boxes), listapanelokat (list boxes) és nyomógombokat (push buttons) adhat hozzá közvetlenül az oldalobjektumhoz, egyetlen hívással (call) mindegyiket. A HotPDF betölthet egy meglévő PDF-et is a LoadFromFile segítségével, és kitöltheti (fill) vagy olvashatja a mezőértékeket, ami két külön munkafolyamatban (workflow) is hasznossá teszi: űrlapok építésében és a kitöltésük automatizálásában
A titkosítás (encryption) is dokumentum szinten (document level) van kezelve. A CryptKeyLength kiválasztja a sémát (40 bites RC4-től az AES-256-ig), az ActivateProtection élesíti (arms) azt, a ProtectOptions pedig beállítja az ISO engedélyezési jelzőket (permission flags). A két AES-256 felülvizsgálati (revision) mód (R5 és R6, amelyeket a UseAES256R6 vezérel) azért létezik, mert a 6. revízió (revision) kijavít egy ismert gyengeséget az 5. revízióban, de egy PDF 2.0-képes nézegetőt (viewer) igényel; a közöttük lévő választás egy kompatibilitási döntés (compatibility decision), nem pedig kényelmi
A HotPDF digitális aláírás támogatása (digital signature support) lefedi a PAdES alap profiljait (baseline profiles), így olyan munkafolyamatokhoz is alkalmas, ahol az aláírásnak meg kell felelnie az ETSI EN 319 142 követelményeknek. Ha az Ön igénye csak a kimenet generálása (generating output), akkor a HotPDF az a könyvtár, amelyhez elsőként érdemes nyúlnia
PDFium Component: meglévő PDF-ek renderelése, megtekintése és olvasása
A PDFium Component a Google PDFium motorját csomagolja egy VCL komponensbe, ami alapvetően eltérő szerepet (role) ad neki a HotPDF-hez képest. Ahol a HotPDF ír, ott a PDFium Component olvas és renderel (renders). Az alapobjektum (core object) a TPdf, egy dokumentumkezelő (document manager), amely úgy nyit meg egy fájlt, hogy beállítja a FileName-t, majd az Active := True értéket. A betöltési hibák (load failures) nem kerülnek kivételként (exceptions) felvetésre; az Active egyszerűen False marad, így a hozzárendelés utáni ellenőrzése (checking) nem választható (optional) opció
A renderelés a TPdfView-n keresztül fut, egy vizuális komponensen, amit ráejt egy űrlapra (form) és összekapcsol (link) egy TPdf példánnyal a PdfView.Pdf := Pdf segítségével. A nagyítás (zoom) és az illesztési (fit) mód a nézeten (view) él, nem pedig a dokumentumon. Egy finomság, amin megbotlanak az emberek: a Pdf.PageNumber és a PdfView.PageNumber független tulajdonságok (independent properties). Az egyik beállítása nem frissíti (update) a másikat, és a nézet-alapú kinyerési API-k (view-based extraction APIs) (szódobozok (word boxes), olvasási egységek (reading units)) a nézet (view) aktuális oldalát használják, nem pedig a dokumentumét
A szövegkinyerés (text extraction) az a terület, ahol a PDFium Component-nek nincs közvetlen versenytársa a losLab kínálatában. A ReadablePageContent strukturált szöveget (structured text) ad vissza az olvasási sorrend (reading-order) tudatosságával, a PageWordBoxes szó-szintű határoló téglalapokat (bounding rectangles) ad, a DocumentReadingUnits pedig végigsétál a teljes dokumentumon. A hozzáférhetőségi (accessibility) munkához az IsTagged megmondja Önnek, hogy jelen van-e egy struktúrafa (structure tree), a ValidatePdfUa pedig egy UA megfelelőségi ellenőrzést (conformance check) futtat. Ezek az API-k a PDFium Component-t természetes választássá teszik minden olyan munkafolyamat (workflow) számára, amelynek meg kell értenie, mi van egy meglévő PDF-ben (existing PDF), ahelyett, hogy újat hozna létre
Az űrlapkitöltés (form filling) a PDFium oldalon is működik, ugyanazon az AcroForm rétegen (layer) keresztül, amit a mögöttes motor (underlying engine) tesz elérhetővé. Ez akkor megfelelő (appropriate), amikor a forrásdokumentum (source document) már létezik, és a kitöltését (completion) automatizálja, ahelyett, hogy Ön maga építené meg az űrlapmezőket
PDFlibPas: manipuláció, megfelelőségi aláírás és közvetlen fájlhozzáférés (direct-file access)
A PDFlibPas (3.73.0-as verzió) a komplexitás (complexity) spektrumának másik végén ül. Három API-réteget (API layers) tesz elérhetővé ugyanazon dokumentummodell tetején: egy lapos leíró-alapú homlokzatot (handle-based facade) (TPDFlib), amely kompatibilis a Quick-PDF hívási konvenciójával, egy teljes objektumfa-réteget (object-tree layer) (TPDFDocument), és egy streamelő elemzőt (streaming parser) (TSmartPDFReader / TSmartPDFWriter), amely közvetlenül a fájl bájtjain (file bytes) operál anélkül, hogy betöltené a teljes objektumgráfot (object graph)
A streamelő réteg (streaming layer) az, ami a PDFlibPas-t megfelelő választássá teszi nagy dokumentumok (large documents) esetében. A TSmartPDFWriter egy növekményes frissítést (incremental update) fűzhet (append) a lemezen (disk) lévő fájlhoz a teljes kereszthivatkozási tábla (cross-reference table) rekonstruálása nélkül, ami a hatékony (efficient) újramentés (resaving) és a PAdES hosszú távú érvényesítési bélyegzők (long-term validation stamps) mögöttes mechanizmusa. A megfelelőségi szintű (compliance-grade) aláírási munkafolyamatokhoz, ahol az aláírt hash-nek (signed hash) egy meghatározott bájttartományt (byte range) kell lefednie, és az aláírást a dokumentum újraírása nélkül alkalmazzák, ez a réteg (layer) az egyetlen járható (viable) út
A dokumentum-manipuláció a TPDFDocument szinten magában foglalja az egyesítést (merging) a Merge-el, a szelektív oldalmásolást (selective page copying) a CopyPagesFromDoc-al egy tartománystring (range string) segítségével, és a verzióirányítást (version governance) a SetMinimumVersion és a LockSaveVersion által. A verziózár (version lock) 602-es hibát vet fel (raises error 602), ha megpróbál elmenteni (save) egy olyan funkciót (feature), amely a kimenetet a zárolt verzió fölé tolná, ami akkor hasznos, ha garantálnia kell, hogy a kimenet (output) egy meghatározott PDF revízión (revision) belül marad az archiválási megfelelőség (archival compliance) érdekében
A PDF/A támogatás (ISO 19005) a PDFlibPas megfelelőségi munkapadján (conformance workbench) ül. Vegye figyelembe, hogy a titkosítás (encryption) és a PDF/A a specifikáció szerint kölcsönösen kizárják egymást: nem lehet mindkettő egy fájlban (file). Azoknak a munkafolyamatoknak (workflows), amelyeknek titkosított (encrypted) terjesztési (distribution) másolatra és PDF/A archív másolatra (archive copy) is szükségük van, két különálló (separate) műterméket (artifacts) kell előállítaniuk
Választás (choosing) közöttük
A tipikus döntési fa (decision tree) rövid. Ha egy új dokumentumot generál adatokból (data), használja a HotPDF-et. Ha renderel vagy szöveget nyer ki (extracting text) egy meglévő dokumentumból (existing document) egy Delphi VCL alkalmazásban, használja a PDFium Component-t. Ha meglévő PDF-eket manipulál, egyesít vagy megfelelőségi szinten aláír (compliance-signing) méretben (at scale) vagy inkrementális mentési (incremental-save) szemantikával, használja a PDFlibPas-t. Számos termelési rendszer (production systems) a háromból kettőt használ: például a HotPDF-et a kimenet (output) generálására, a PDFlibPas-t pedig egy hosszú távú érvényesítési bélyegző (long-term validation stamp) alkalmazására archiválás előtt, vagy a PDFium Component-t a HotPDF által előállított (produced) kimenet előnézetének (preview) megtekintésére, mielőtt azt továbbküldenék (downstream)
Mind a három natív (native) Pascal forráskódként (source) érkezik (ship) a Delphihez és a C++Builderhez, a VCL-en túl nincsenek futásidejű függőségek (runtime dependencies). A PDFium Component emellett tartalmazza a PDFium DLL-t is, amely lefedi (covers) a motor renderelési és elemzési (parsing) munkáját. Minden egyes könyvtár (library) termékoldala tartalmazza a teljes API-referenciát és az aktuális verziótörténetet (version history)
Részletek az egyes könyvtárakról (libraries): HotPDF Component, PDFium Component és PDFlibPas