A HotPDF egyetlen belépési ponton, a RenderLoadedPageToDevice-on keresztül renderel egy betöltött PDF-oldalt, és a általunk átadott eszköz dönti el, hogy az eredmény bitmap, egy külső eszközkontextuson — például nyomtatóvásznon — való rajz, vagy egy vektoros enhanced metafájl-e. Állítsuk a RenderOverprintPreview-t True-ra, és ugyanaz a hívás szimulálja a CMYK processz-tinta rányomást, így egy operátor a képernyőn látja azt a tintainterakciót, amely egyébként csak a nyomdai lapon jelenne meg
Ez a két funkció különböző problémákat old meg, amelyek véletlenül ugyanabban a kódrészben találkoznak. Az eszközabsztrakció eltávolítja azt az elágazást, ahol a preview, a nyomtatás és az export mind a saját renderelő hívásával és a saját eltérésével rendelkezett. A rányomtatási proof eltávolítja azt a termelési hibaosztályt, ahol egy dokumentum minden megjelenítőben helyesnek tűnik, és hibásan kerül le a nyomdáról
Miért nyomtat máshogy egy oldal, mint ahogy megjeleníti?
Mert a rányomtatás egy utasítás a képalkotó eszköznek, nem egy festési művelet. Amikor egy oldal /OP vagy /op true értéket állít be a grafikai állapotban, a RIP-et arra utasítja, hogy ne üsse ki az alatta lévő tintákat — egy cián objektum, amelyet sárgára rajzoltak, a sárgát a helyén hagyja, és a lap zöld lesz. Egy olyan megjelenítő, amely figyelmen kívül hagyja a rányomást, normálisan kiveri és ciánt mutat. Egyik sem saját szempontjából hibás, és pontosan ez a probléma: a képernyő és a nyomda nem ért egyet, és senki nem tudja meg, amíg a proofok vissza nem érkeznek
A RenderOverprintPreview arra kényszeríti a HotPDF-t, hogy komolyan vegye az utasítást a /OP, /op és /OPM 1 által vezérelt DeviceCMYK festékekre. Az eredmény proof-preview, nem megjelenítő-preview: egy árnyalatot rányomtató fekete gazdag átfedés marad ahelyett, hogy lyukat ütne, és egy tervező véletlen rányomása fehér szövegen láthatóvá válik az eltűnő szövegként, amivé válni fog
var
Pdf: THotPDF;
Device: THPDFBitmapRenderDevice;
Proof: TBitmap;
begin
Pdf := THotPDF.Create(nil);
try
Pdf.LoadFromFile('cover-cmyk.pdf');
Pdf.RenderOverprintPreview := True; // proof, not plain preview
Device := THPDFBitmapRenderDevice.Create;
try
if Pdf.RenderLoadedPageToDevice(0, 150, Device) then
begin
Proof := Device.TakeBitmap; // ownership moves to the caller
try
Image1.Picture.Assign(Proof);
finally
Proof.Free;
end;
end;
finally
Device.Free;
end;
finally
Pdf.Free;
end;
end;A beállítás részt vesz a render-gyorsítótár-identitásban, memóriában és lemezen, így egy normál preview és egy proof-preview sosem oszt egy bitmapot. A tulajdonság váltogatása nem igényel semmi kézi érvénytelenítést — egy olyan gyorsítótár, amely visszaadta ezen kettő közül a rosszat, rosszabb lenne, mint egyáltalán semmilyen gyorsítótár
Három eszköz, egyetlen renderhívás
A THPDFRenderDevice egy absztrakt osztály két fontos taggal: Kind, amely a célt rdkBitmap, rdkDeviceContext vagy rdkEnhancedMetafile értékként jelenti, és Execute, amelyet a könyvtár hív. Három konkrét eszköz érkezik a HotPDF-fel, és mindegyik máshogy birtokolja a kimenetet
A THPDFBitmapRenderDevice egy TBitmap-et birtokol, amíg a TakeBitmap át nem adja a tulajdont. A THPDFDeviceContextRenderDevice egy meglévő HDC-t vesz át szélességgel és magassággal, és egyenesen bele rajzol, ami úgy renderelünk egy nyomtatóvászonra, hogy nincs bitmap oda-vissza út. A THPDFMetafileRenderDevice egy TMetafile-t birtokol, amíg a TakeMetafile át nem adja, ami vektoros tartalmat vektorként tart azoknak a fogyasztóknak, amelyeknek szükségük van rá
var
Device: THPDFDeviceContextRenderDevice;
begin
Printer.BeginDoc;
try
Device := THPDFDeviceContextRenderDevice.Create(
Printer.Canvas.Handle, Printer.PageWidth, Printer.PageHeight);
try
Pdf.RenderLoadedPageToDevice(PageIndex, 300, Device);
finally
Device.Free;
end;
finally
Printer.EndDoc;
end;
end;A Kind olvasása a futásidejű osztály tesztelése helyett szándékos. Az alkalmazáskód, amely az eszköztípusra diszpécse, tovább működik, amikor egy eszközt becsomagolnak, dekorálnak vagy lecserélnek, a is THPDFBitmapRenderDevice tesztelő kód pedig nem
Mit jelent a tulajdonátruházás a gyakorlatban
A TakeBitmap vagy TakeMetafile előtt az eszköz birtokolja az objektumot, és a destruktorában felszabadítja. A hívás után mi birtokoljuk, és az eszköz már nem. Mindkét minta jogszerű: használjuk a Bitmap vagy Metafile tulajdonságot, amikor az objektumnak csak a renderhívást kell túlélnie, és vegyük át a tulajdont, amikor az objektum túléli az eszközt
A hibaüzemmód a mindennapi Delphi. Vegyük el a bitmapot, szabadítsuk fel az eszközt, felejtsük el felszabadítani a bitmapot, és egy olyan szivárgásunk van, amely az oldalszámmal nő — láthatatlan egy ötoldalas teszten, nyilvánvaló egy ötszázoldalas kötegen. Csomagoljuk mindkét objektumot a saját try/finally-jébe, ahelyett hogy megosztanánk egyet, és a tulajdonkérdés magától megválaszolódik
Rányomtatási proof és átlátszóság ugyanazon az oldalon
A transzparenciacsoport-knockout aktív marad, amikor a rányomtatási preview be van kapcsolva, és mindkettő ugyanabban a korlátozott festési pillanatkép-úton kompozitálódik. Ez azért számít, mert a valódi nyomdakész fájlok folyamatosan keverik a kettőt: egy művészetet tartalmazó transzparenciacsoport olyan háttéren ül, amelynek feketéje rányomtatásra van állítva, és az egyik szimulálása a másik nélkül egy olyan proofot eredményez, amely új módon hibás, nem helyes
A korlátokat tartsuk szem előtt. A rányomtatási preview a processz-tinta viselkedést szimulálja a fent nevezett rányomtatás-vezérlők alatti DeviceCMYK festékekre. Ez a tintainterakció proofja, nem színkezelt szerződéses proof: nem helyettesíti az ICC-workflow-t, és nem mondja meg, mit fog eredményezni egy adott nyomda és papír. Úgy kezeljük, ahogy egy prepress-operátor kezeli a rányomtatási preview-t egy professzionális megjelenítőben — mint azt az ellenőrzést, amely elkapja azokat a hibákat, amelyeket senki nem kap el egy normál preview megnézésével
A proof beillesztése egy preflight lépésbe
Ennek hasznos helye a már futtatott ellenőrzések mellett van. Egy preflight-menet arról jelent, hogy a fekete szöveg rányomtatásra van állítva; egy proof-render megmutatja egy operátornak, mit jelent ez az oldalon; és mindkettő ugyanabba a jelentésbe kerül. A spot színekhez, amelyek gyakran kísérik a rányomást a csomagolási munkában, a Separation és DeviceN spot szín renderelés átjárása ugyanannak az oldalnak a színező oldalát tárgyalja, míg a PDF-oldal bitmapra renderelése és a betöltött PDF nyomtatása TPrinteren keresztül jegyzetei a két eszközcélt sima, nem-proof formájukban tárgyalják
A HotPDF natív VCL kódból renderel, proofol és nyomtat betöltött PDF-oldalakat Delphihez és C++Builderhez, külső renderelő DLL nélkül, amelyet az alkalmazás mellé telepíteni kellene — a HotPDF komponens oldal tartalmazza a render-funkciólistát és egy próbaverziót