CMYK overprint proofing a renderovacie zariadenia v HotPDF

HotPDF renderuje načítanú stranu PDF jedným vstupným bodom, RenderLoadedPageToDevice, a zariadenie, ktoré mu odovzdáte, rozhoduje, či bude výsledkom bitmapa, kresba na externom zariadenovom kontexte, akým je plátno tlačiarne, alebo vektorový rozšírený metafile. Nastavte RenderOverprintPreview na True a to isté volanie simuluje CMYK overprint procesných farieb, takže operátor vidí na obrazovke interakciu farieb, ktorá by sa inak prejavila až na tlačovom hárku

Tieto dve vlastnosti riešia rozličné problémy, ktoré sa náhodou stretávajú v rovnakej ceste kódu. Abstrakcia zariadenia odstraňuje vetvu, kde mali náhľad, tlač a export každý svoje vlastné volanie renderovania so svojím vlastným posunom. Overprint proofing odstraňuje triedu produkčnej chyby, kde dokument vyzerá správne v každom prehliadači a z tlačiarne príde zle

Prečo sa strana tlačí inak než sa zobrazuje v náhľade?

Pretože overprint je inštrukcia zobrazovaciemu zariadeniu a nie operácia maľovania. Keď strana nastaví /OP alebo /op na true v grafickom stave, hovorí RIP, aby nevyraďoval farby pod sebou — azúrový objekt nakreslený cez žltú nechá žltú na mieste a hárok ukáže zelenú. Prehliadač, ktorý overprint ignoruje, vyraďuje normálne a ukáže azúrovú. Žiadny nie je sám o sebe chybný a to je presne problém: obrazovka a tlačiareň sa nezhodnú a nikto sa to nedovie, kým sa nevrátia farebné skúšky

RenderOverprintPreview prinúti HotPDF brať inštrukciu vážne pre DeviceCMYK farby riadené /OP, /op a /OPM 1. Výsledkom je náhľad skúšky a nie náhľad prehliadača: Čierne prekrývajúce odtieň zostáva bohatým prekrytím namiesto vyrazenia diery a náhodný overprint dizajnéra na bielom texte sa prejaví ako miznúci text, ktorým pri tlači skutočne bude

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;

Nastavenie sa zúčastňuje identity renderovacej vyrovnávacej pamäte, v pamäti aj na disku, takže bežný náhľad a náhľad skúšky nikdy nezdieľajú bitmapu. Prepínanie vlastnosti nevyžaduje, aby ste čokoľvek manuálne invalidovali — vyrovnávacia pamäť, ktorá by vrátila nesprávnu z týchto dvoch, by bola horšia než žiadna

Tri zariadenia, jedno volanie renderovania

THPDFRenderDevice je abstraktná trieda s dvoma členmi, na ktorých záleží: Kind, ktorý hlási cieľ ako rdkBitmap, rdkDeviceContext alebo rdkEnhancedMetafile, a Execute, ktorý knižnica volá. S HotPDF sa dodávajú tri konkrétne zariadenia a každé vlastní svoj výstup odlišne

THPDFBitmapRenderDevice vlastni TBitmap, kým TakeBitmap neprenesie vlastníctvo na vás. THPDFDeviceContextRenderDevice prijíma existujúce HDC plus šírku a výšku a kreslí priamo doňho, čo je spôsob, ako renderovať na plátno tlačiarne bez bitmapovej okružnej cesty. THPDFMetafileRenderDevice vlastní TMetafile, kým TakeMetafile ho neprenesie, čo zachováva vektorový obsah ako vektory pre konzumentov, ktorí ho potrebujú

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;

Čítanie Kind namiesto testovania runtime triedy je zámerne. Aplikačný kód, ktorý sa dispatchuje podľa druhu zariadenia, bude naďalej fungovať, keď je zariadenie obalené, dekorované alebo nahradené, a kód, ktorý testuje is THPDFBitmapRenderDevice, nebude

Čo znamená prevod vlastníctva v praxi

Pred TakeBitmap alebo TakeMetafile vlastní zariadenie objekt a uvoľní ho vo svojom deštruktore. Po volaní ho vlastníte vy a zariadenie už nie. Obe vzory sú legitímne: použite vlastnosť Bitmap alebo Metafile, keď má objekt prežiť iba volanie renderovania, a prevezmite vlastníctvo, keď objekt prežije zariadenie

Režim zlyhania je obyčajný Delphi. Vezmite bitmapu, uvoľnite zariadenie, zabudnite uvoľniť bitmapu a máte únik, ktorý rastie s počtom strán — neviditeľný na päťstranovom teste a zjavný na päťstostranovej dávke. Obalte oba objekty do ich vlastného try/finally namiesto zdieľania jedného a otázka vlastníctva sa zodpovie sama

Overprint proofing a transparentnosť na tej istej strane

Knockout skupiny transparentnosti zostáva aktívny, keď je zapnutý náhľad overprintu, a obe sa kompozitujú v rovnakej ceste obmedzeného snímku maľby. To je dôležité, pretože reálne tlačové súbory miešajú obe neustále: skupina transparentnosti nesúca grafiku sedí na pozadí, ktorého čierna je nastavená na overprint, a simulácia jednej bez druhej produkuje skúšku, ktorá je chybná novým spôsobom namiesto správnej

Majte na pamäti limity. Náhľad overprintu simuluje správanie procesných farieb pre DeviceCMYK farby pod kontrolami overprintu uvedenými vyššie. Je to dôkaz interakcie farieb a nie farebne spravovaná zmluvná skúška: nenahrádza ICC workflow a nepovie vám, čo konkrétna tlačiareň a materiál prinesie. Zaobchádzajte s ním tak, ako sa operátor predtlačovej prípravy zhovára s náhľadom overprintu v profesionálnom prehliadači — ako s kontrolou, ktorá zachytí chyby, ktoré nikto nezachytí pozeraním sa na bežný náhľad

Zaradenie proofingu do kroku preflight

Užitočné miesto pre toto je vedľa kontrol, ktoré už spúšťate. Prechod preflightu nahlási, že čierny text je nastavený na overprint; render skúšky ukáže operátorovi, čo to na strane znamená; a obe skončia v rovnakom reporte. Pre spotové farby, ktoré často sprevádzajú overprint v obalovom priemysle, návod k renderovaniu Separation a DeviceN spotových farieb pokrýva farebnú stránku tej istej strany, zatiaľ čo poznámky k renderovaniu strany PDF do bitmapy a k tlači načítaného PDF cez TPrinter pokrývajú dva ciele zariadení v ich obyčajnej, ne-skúšobnej forme

HotPDF renderuje, kontroluje a tlačí načítané strany PDF z natívneho VCL kódu pre Delphi a C++Builder, bez externého renderovacieho DLL, ktoré by sa muselo dodávať spolu s aplikáciou — stránka HotPDF komponentu obsahuje zoznam renderovacích funkcií a skúšobnú zostavu