CMYK-overprint-korrektur og render-enheder i HotPDF

HotPDF renderer en indlæst PDF-side gennem ét indgangspunkt, RenderLoadedPageToDevice, og den enhed, du rækker den, afgør, om resultatet er en bitmap, en tegning på en ekstern enhedskontekst såsom et printer-canvas, eller en vektor forbedret metafil. Sæt RenderOverprintPreview til True, og samme kald simulerer CMYK-proces-blek-overprint, så en operatør ser på skærmen den blek-interaktion, der ellers kun ville dukke op på tryk-arket

De to funktioner løser forskellige problemer, der tilfældigvis mødes i samme kode-sti. Enheds-abstraktionen fjerner den forgrening, hvor preview, print og eksport hver havde deres eget render-kald med deres egen drift. Overprint-korrektur fjerner den klasse produktionsfejl, hvor et dokument ser korrekt ud i enhver fremviser og kommer af pressen forkert

Hvorfor printer en side anderledes end den previewer?

Fordi overprint er en instruks til billed-enheden, ikke en male-operation. Når en side sætter /OP eller /op sand i grafik-tilstanden, siger den til RIP'en, at den ikke skal knocke de underliggende blek ud — et cyan-objekt tegnet over gult efterlader det gule, og arket viser grønt. En fremviser, der ignorerer overprint, knock-er normalt ud og viser cyan. Ingen af delene er forkerte på deres egne vilkår, og det er netop problemet: skærmen og pressen er uenige, og ingen finder ud af det, før korrektur kommer retur

RenderOverprintPreview får HotPDF til at tage instruksen alvorligt for DeviceCMYK-maling styret af /OP, /op og /OPM 1. Resultatet er et korrektur-preview frem for et fremviser-preview: sort der overprinter en nuance forbliver et rigt overlay frem for at slå et hul, og en designers tilfældige overprint på hvid tekst bliver synlig som den forsvindende tekst, den vil blive

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;

Tilgangen deltager i render-cache-identitet, i hukommelse og på disk, så et normalt preview og et korrektur-preview aldrig deler en bitmap. At skifte egenskaben kræver ikke, at du invaliderer noget manuelt — en cache, der returnerede den forkerte af disse to, ville være værre end slet ingen cache

Tre enheder, ét render-kald

THPDFRenderDevice er en abstrakt klasse med to medlemmer, der betyder noget: Kind, som rapporterer målet som rdkBitmap, rdkDeviceContext eller rdkEnhancedMetafile, og Execute, som biblioteket kalder. Tre konkrete enheder shipper med HotPDF, og hver ejer sit output forskelligt

THPDFBitmapRenderDevice ejer en TBitmap, indtil TakeBitmap overfører ejerskab til dig. THPDFDeviceContextRenderDevice tager en eksisterende HDC plus bredde og højde og tegner direkte ind i den, hvilket er, hvordan du renderer på et printer-canvas uden en bitmap-rundtur. THPDFMetafileRenderDevice ejer en TMetafile, indtil TakeMetafile overfører den, hvilket bevarer vektor-indhold som vektorer for de forbrugere, der har brug for det

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;

At læse Kind frem for at teste runtime-klassen er bevidst. Applikations-kode, der dispatcher på enheds-kind, fortsætter med at virke, når en enhed indpakkes, dekoreres eller udskiftes, og kode der tester is THPDFBitmapRenderDevice gør ikke

Hvad ejerskabsoverførsel betyder i praksis

Før TakeBitmap eller TakeMetafile ejer enheden objektet og frigør det i sin destruktor. Efter kaldet ejer du det, og enheden gør ikke længere. Begge mønstre er legitime: brug egenskaben Bitmap eller Metafile, når objektet kun skal overleve render-kaldet, og tag ejerskab, når objektet overlever enheden

Fejltilstanden er den almindelige Delphi-en. Tag bitmap'en, frigør enheden, glem at frigive bitmap'en, og du har en lækage, der vokser med sidetallet — usynlig på en fem-siders test og åbenlys på en femhundred-siders batch. Indpak begge objekter i deres egen try/finally frem for at dele én, og ejerskabsspørgsmålet besvarer sig selv

Overprint-korrektur og gennemsigtighed på samme side

Transparency-group-knockout forbliver aktiv, når overprint-preview er slået til, og begge komponeres i samme afgrænsede paint-snapshot-sti. Det betyder noget, fordi rigtige tryk-klare filer konstant blander de to: en gennemsigtigheds-gruppe, der holder artwork, sidder på en baggrund, hvis sort er sat til overprint, og at simulere den ene uden den anden producerer en korrektur, der er forkert på en ny måde frem for rigtig

Hold dog begrænsningerne for øje. Overprint-preview simulerer proces-blek-opførsel for DeviceCMYK-maling under de overprint-kontroller, der er navngivet ovenfor. Det er et korrektur af blek-interaktion, ikke et farve-styret kontrakt-proof: det erstatter ikke en ICC-arbejdsgang, og det fortæller dig ikke, hvad et specifikt tryk og papir vil levere. Behandl det, som en prepress-operatør behandler et overprint-preview i en professionel fremviser — som det tjek, der fanger de fejl, ingen fanger ved at kigge på et normalt preview

Placering af korrektur i et preflight-trin

Det nyttige sted for dette er ved siden af de tjek, du allerede kører. Et preflight-pass rapporterer, at sort tekst er sat til overprint; et korrektur-render viser en operatør, hvad det betyder på siden; og begge går i samme rapport. For spot-farver, der ofte ledsager overprint i emballage-arbejde, dækker gennemgangen af Separation- og DeviceN-spot-farve-rendering farve-siden af samme side, mens noterne om rendering af en PDF-side til en bitmap og om udskrivning af en indlæst PDF gennem TPrinter dækker de to enhedsmål i deres almindelige, ikke-korrektur-form

HotPDF renderer, korrekturlæser og printer indlæste PDF-sider fra native VCL-kode til Delphi og C++Builder, uden nogen ekstern render-DLL at udrulle ved siden af applikationen — HotPDF-komponent-siden har render-funktionslisten og en trial-build