HotPDF 的 CMYK Overprint 打樣與算繪裝置

HotPDF 透過單一入口 RenderLoadedPageToDevice 來算繪已載入的 PDF 頁面，而你交給它的裝置決定了結果是一張點陣圖、一份繪製到外部裝置內容（例如印表機畫布）上的圖，還是一份向量增強型中繼檔。把 RenderOverprintPreview 設為 True，同一次呼叫就會模擬 CMYK 印墨 overprint，讓操作人員在螢幕上看到原本只會出現在印刷紙張上的印墨互動

這兩項功能解決的是不同問題，只是剛好在同一條程式碼路徑上相遇。裝置抽象移除了那個預覽、列印、匯出各自擁有獨立算繪呼叫與獨自漂移的分支。Overprint 打樣移除了那一類生產錯誤——文件在每個閱讀器裡看起來都正確，從印刷機送出來卻是錯的

為什麼頁面印出來與預覽時不一樣？

因為 overprint 是給成像裝置的指令，而不是一項繪製操作。當頁面在繪圖狀態裡把 /OP 或 /op 設為 true 時，它是在告訴 RIP 不要挖空底下的印墨——一個青色物件畫在黃色之上，會讓黃色留在原處，紙張於是顯示綠色。一個無視 overprint 的閱讀器會正常挖空並顯示青色。兩者各自來看都不算錯，而這正是問題所在：螢幕與印刷機意見不一，沒有人會在打樣送回來之前發現

RenderOverprintPreview 讓 HotPDF 針對受 /OP、/op 與 /OPM 1 控制的 DeviceCMYK 塗色，認真看待這道指令。結果是一份打樣預覽，而不是閱讀器預覽：overprint 在淡色之上的黑色會維持為一道豐富的疊印，而不是穿一個洞，而設計師在白色文字上不小心套用的 overprint，則會以它即將變成的消失文字現形

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;

這項設定會參與算繪快取的識別，無論是在記憶體或磁碟上，所以普通預覽與打樣預覽永遠不會共用到同一張點陣圖。切換這個屬性不需要你手動讓任何東西失效——一個會在這兩者之間回傳錯誤那一個的快取，比完全沒有快取還糟

三種裝置，單一算繪呼叫

THPDFRenderDevice 是一個抽象類別，有兩個重要的成員：Kind，把目標回報為 rdkBitmap、rdkDeviceContext 或 rdkEnhancedMetafile；以及 Execute，由函式庫呼叫。HotPDF 隨附三種具體裝置，而每一種擁有自身輸出的方式不同

THPDFBitmapRenderDevice 持有一個 TBitmap，直到 TakeBitmap 把擁有權轉移給你。THPDFDeviceContextRenderDevice 接受一個既有的 HDC 加上寬度與高度，並直接繪製進去，這就是你不必繞一圈點陣圖就能算繪到印表機畫布的方式。THPDFMetafileRenderDevice 持有一個 TMetafile，直到 TakeMetafile 把它轉移出去，這讓向量內容對需要它的消費端來說仍然是向量

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;

刻意選擇讀取 Kind 而不是測試執行時期類別。當一個裝置被包裹、裝飾或替換時，依裝置種類分派的應用程式碼能繼續運作，而測試 is THPDFBitmapRenderDevice 的程式碼則否

擁有權轉移在實務上代表什麼

在 TakeBitmap 或 TakeMetafile 之前，裝置擁有該物件，並會在解構函式中釋放它。呼叫之後，你擁有它，而裝置不再擁有。兩種模式都合法：當物件只需要活得比算繪呼叫更久時，使用 Bitmap 或 Metafile 屬性；當物件需要活得比裝置更久時，就取走擁有權

失敗模式是普通的 Delphi 失敗模式。取走點陣圖、釋放裝置、忘了釋放點陣圖，你就得到一個會隨頁數增長的洩漏——在五頁的測試裡看不出來，在五百頁的批次裡一目了然。把兩個物件各自包進自己的 try/finally，而不是共用一個，擁有權的問題就會自己回答自己

同一頁裡的 overprint 打樣與透明

當 overprint 預覽開啟時，透明群組的挖空仍然保持作用，而兩者會在同一條有界的繪製快照路徑中合成。這一點很重要，因為真實的可印檔案不斷混合兩者：一個裝著美工圖的透明群組，坐落在一片黑色被設為 overprint 的背景上，而只模擬其中一者、不模擬另一者，會產生一份以全新方式出錯的打樣，而不是正確的打樣

請把限制放在心上。Overprint 預覽為上述 overprint 控制項下的 DeviceCMYK 塗色模擬印墨行為。它是印墨互動的打樣，而不是色彩管理的合約打樣：它不會取代 ICC 工作流程，也不會告訴你特定的印刷機與紙材會得到什麼結果。把它當作印前操作人員看待專業閱讀器裡 overprint 預覽的方式——也就是那道用來抓出沒有人會在普通預覽裡看出的錯誤的檢查

把打樣嵌進預檢步驟裡

這項功能最適合放的位置，就在你已經在跑的那些檢查旁邊。一道預檢掃瞄回報黑色文字被設為 overprint；一次打樣算繪讓操作人員看到那在頁面上代表什麼；兩者都進入同一份報告。對於在包裝工作中經常伴隨 overprint 出現的特別色，Separation 與 DeviceN 特別色算繪的逐步解說涵蓋了同一個頁面的色料側，而 將 PDF 頁面算繪為點陣圖與透過 TPrinter 列印已載入的 PDF的筆記，則涵蓋了兩種裝置目標在普通、非打樣形式下的運作

HotPDF 從 Delphi 與 C++Builder 的原生 VCL 程式碼，對已載入的 PDF 頁面進行算繪、打樣與列印，沒有任何需要隨應用程式一起部署的外部算繪 DLL——HotPDF 元件頁提供算繪功能清單與試用組建