CMYK-overprint-proofing en renderdevices in HotPDF

HotPDF rendert een geladen PDF-pagina via één ingangspunt, RenderLoadedPageToDevice, en het device dat je meegeeft beslist of het resultaat een bitmap is, een tekening op een externe device-context zoals een printercanvas, of een vector enhanced-metafile. Zet RenderOverprintPreview op True en dezelfde aanroep simuleert CMYK-procesinkt-overprint, zodat een operator op het scherm ziet wat de inktinteractie is die anders alleen op de pers verschijnt

Die twee functies lossen verschillende problemen op die toevallig in hetzelfde codepad samenkomen. De deviceabstractie verwijdert de vertakking waarbij voorbeeld, druk en export elk hun eigen renderaanroep hadden met hun eigen drift. Overprint-proofing verwijdert de klasse productiefouten waarbij een document in elke viewer goed lijkt en van de pers verkeerd komt

Waarom drukt een pagina anders dan hij wordt weergegeven?

Omdat overprint een instructie is aan het imaging-device, geen verfoperatie. Wanneer een pagina /OP of /op op true zet in de graphics-state, vertelt het de RIP de inkten eronder niet uit te klokken — een cyaan object over geel getekend laat het geel op zijn plaats, en het vel toont groen. Een viewer die overprint negeert klokkt normaal uit en toont cyaan. Geen van beide is op zichzelf verkeerd, en dat is precies het probleem: het scherm en de pens zijn het oneens, en niemand komt erachter tot de proeven terugkomen

RenderOverprintPreview zorgt dat HotPDF de instructie serieus neemt voor DeviceCMYK-verven die door /OP, /op en /OPM 1 worden bestuurd. Het resultaat is een proof-voorbeeld in plaats van een viewer-voorbeeld: zwart dat over een kleurtint overprint blijft een rijke overlay in plaats van een gat te slaan, en de accidentele overprint van een ontwerper op witte tekst wordt zichtbaar als de verdwijnende tekst die het zal zijn

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;

De instelling neemt deel aan de render-cache-identiteit, in geheugen en op schijf, zodat een gewoon voorbeeld en een proof-voorbeeld nooit een bitmap delen. Het schakelen van de eigenschap vereist niet dat je zelf iets invalideert — een cache die de verkeerde van deze twee retourneerde zou erger zijn dan helemaal geen cache

Drie devices, één renderaanroep

THPDFRenderDevice is een abstracte klasse met twee leden die er toe doen: Kind, dat het doel rapporteert als rdkBitmap, rdkDeviceContext of rdkEnhancedMetafile, en Execute, dat de bibliotheek aanroept. Drie concrete devices worden met HotPDF geleverd, en elk bezit zijn uitvoer verschillend

THPDFBitmapRenderDevice bezit een TBitmap tot TakeBitmap het eigendom aan jou overdraagt. THPDFDeviceContextRenderDevice neemt een bestaande HDC plus breedte en hoogte en tekent er rechtstreeks in, wat is hoe je op een printercanvas rendert zonder een bitmap-roundtrip. THPDFMetafileRenderDevice bezit een TMetafile tot TakeMetafile het overdraagt, wat vectorcontent als vectoren behoudt voor de verbruikers die het nodig hebben

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 lezen in plaats van de runtime-klasse testen is bewust. Applicatiecode die dispatcht op device-kind blijft werken wanneer een device wordt gewikkeld, gedecoreerd of vervangen, en code die is THPDFBitmapRenderDevice test niet

Wat eigendomsoverdracht in de praktijk betekent

Vóór TakeBitmap of TakeMetafile bezit het device het object en bevrijdt het in zijn destructor. Na de aanroep bezit jij het en het device niet meer. Beide patronen zijn legitiem: gebruik de eigenschap Bitmap of Metafile wanneer het object alleen de renderaanroep hoeft te overleven, en neem het eigendom over wanneer het object het device overleeft

De faalmodus is de gewone Delphi-variant. Neem de bitmap, bevrijd het device, vergeet de bitmap te bevrijden, en je hebt een lek dat meegroeit met het aantal pagina's — onzichtbaar bij een test van vijf pagina's en voor de hand liggend bij een batch van vijfhonderd. Wikkel beide objecten in hun eigen try/finally in plaats van er één te delen, en de eigendomsvraag beantwoordt zichzelf

Overprint-proofing en transparantie op dezelfde pagina

Knockout van transparantiegroepen blijft actief wanneer overprint-preview aan staat, en beide worden gecompositeerd in hetzelfde begrensde paint-snapshot-pad. Dat talt omdat echte drukklare bestanden de twee constant mengen: een transparantiegroep met artwork zit op een achtergrond waarvan het zwart op overprint staat, en het een simuleren zonder het ander levert een proof die op een nieuwe manier verkeerd is in plaats van goed

Houd de grenzen wel in beeld. Overprint-preview simuleert procesinktgedrag voor DeviceCMYK-verven onder de hierboven genoemde overprint-besturingselementen. Het is een proof van inktinteractie, geen kleurbeheerde contractproof: het vervangt geen ICC-workflow en het vertelt je niet wat een specifieke pers en een specifiek papier zullen opleveren. Behandel het zoals een prepress-operator een overprint-preview in een professionele viewer behandelt — als de controle die de fouten vangt die niemand vangt door naar een gewoon voorbeeld te kijken

Proofing passen in een preflight-stap

De nuttige plek hiervoor is naast de controles die je al draait. Een preflight-pass rapporteert dat zwarte tekst op overprint staat; een proof-render toont een operator wat dat op de pagina betekent; en beide gaan in hetzelfde rapport. Voor steunkleuren, die in verpakkingswerk vaak samengaan met overprint, behandelt de doorloop van Separation- en DeviceN-steunkleuren renderen de kleurantzijde van dezelfde pagina, terwijl de notities over een PDF-pagina naar een bitmap renderen en over een geladen PDF via TPrinter afdrukken de twee doeldoelen in hun gewone, niet-proof-vorm behandelen

HotPDF rendert, prooft en drukt geladen PDF-pagina's af vanuit native VCL-code voor Delphi en C++Builder, zonder een externe rendering-DLL om naast de applicatie uit te leveren — de HotPDF-componentpagina heeft de renderfunctielijst en een trial-build