CMYK-overtrykk-korrektur og rendringsenheter i HotPDF

HotPDF renderer en innlastet PDF-side gjennom ett inngangspunkt, RenderLoadedPageToDevice, og enheten du gir den avgjør om resultatet er et bitmap, en tegning på en ekstern enhetskontekst som et skriverlerret, eller en vektoriell forbedret metafil. Sett RenderOverprintPreview til True, og det samme kallet simulerer CMYK-prosessblekk-overtrykk, slik at en operatør ser på skjermen den blekkinteraksjonen som ellers bare ville dukke opp på trykkarket

De to funksjonene løser forskjellige problemer som tilfeldigvis møtes i den samme kodebanen. Enhetsabstraksjonen fjerner forgreningen der forhåndsvisning, utskrift og eksport hver hadde sitt eget rendringskall med sin egen avdrift. Overtrykk-korrektur fjerner klassen av produksjonsfeil der et dokument ser riktig ut i hver eneste leser og kommer fra trykket feil

Hvorfor skriver en side annerledes ut enn den forhåndsvises?

Fordi overtrykk er en instruks til bildeenheten, ikke en male-operasjon. Når en side setter /OP eller /op til true i grafikktilstanden, sier den til RIP-en at den ikke skal slå ut blekkene under — et cyan-objekt tegnet over gult lar det gule ligge, og arket viser grønt. En leser som ignorerer overtrykk slår ut normalt og viser cyan. Ingen av dem er feil på sine egne premisser, og det er akkurat problemet: skjermen og trykket er uenige, og ingen finner det ut før korrekturer kommer tilbake

RenderOverprintPreview får HotPDF til å ta instruksen alvorlig for DeviceCMYK-maling styrt av /OP, /op og /OPM 1. Resultatet er en korrektur-forhåndsvisning snarere enn en leser-forhåndsvisning: svart som overtrykker en toning forblir et rikt overlegg i stedet for å slå et hull, og en designers utilsiktede overtrykk på hvit tekst blir synlig som den forsvinnende teksten den vil bli

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;

Innstillingen deltar i render-cache-identitet, i minne og på disk, slik at en vanlig forhåndsvisning og en korrektur-forhåndsvisning aldri deler et bitmap. Å veksle egenskapen krever ikke at du invaliderer noe for hånd — en cache som returnerte feil av disse to ville være verre enn ingen cache i det hele tatt

Tre enheter, ett rendringskall

THPDFRenderDevice er en abstrakt klasse med to medlemmer som betyr noe: Kind, som rapporterer målet som rdkBitmap, rdkDeviceContext eller rdkEnhancedMetafile, og Execute, som biblioteket kaller. Tre konkrete enheter leveres med HotPDF, og hver eier sin utdata ulikt

THPDFBitmapRenderDevice eier et TBitmap frem til TakeBitmap overfører eierskapet til deg. THPDFDeviceContextRenderDevice tar en eksisterende HDC pluss bredde og høyde og tegner rett inn i den, noe som er hvordan du renderer over på et skriverlerret uten en bitmap-rundtur. THPDFMetafileRenderDevice eier en TMetafile frem til TakeMetafile overfører den, noe som holder vektorinnhold som vektorer for de konsumentene som trenger 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;

Å lese Kind i stedet for å teste runtime-klassen er bevisst. Applikasjonskode som forsender på enhets-type fortsetter å virke når en enhet blir pakket inn, dekorert eller erstattet, og kode som tester is THPDFBitmapRenderDevice gjør ikke det

Hva eierskapsoverføring betyr i praksis

Før TakeBitmap eller TakeMetafile eier enheten objektet og frigjør det i sin destruktor. Etter kallet eier du det og enheten gjør det ikke lenger. Begge mønstre er legitime: bruk Bitmap- eller Metafile-egenskapen når objektet bare skal overleve rendringskallet, og ta eierskap når objektet overlever enheten

Feilmodusen er den vanlige Delphi-en. Ta bitmap-en, frigjør enheten, glem å frigjøre bitmap-en, og du har en lekkasje som vokser med sideantallet — usynlig på en fem-siders test og åpenbar på en fem-hundre-siders gruppe. Pakk begge objektene inn i sine egne try/finally i stedet for å dele én, og eierskapsspørsmålet svarer på seg selv

Overtrykk-korrektur og gjennomsiktighet på samme side

Knockout i gjennomsiktighetsgruppe forblir aktiv når overtrykk-forhåndsvisning er på, og begge komponeres i den samme begrensede male-øyeblikksbild-stien. Dette betyr noe fordi virkelige trykk-klare filer konstant blander de to: en gjennomsiktighetsgruppe som bærer kunstverk sitter på en bakgrunn hvis svart er satt til overtrykk, og å simulere én uten den andre produserer en korrektur som er feil på en ny måte snarere enn riktig

Behold grensene i sikte. Overtrykk-forhåndsvisning simulerer prosessblekk-oppførsel for DeviceCMYK-maling under de overtrykk-kontrollene som er navngitt ovenfor. Det er en korrektur av blekkinteraksjon, ikke en fargestyrt kontraktskorrektur: den erstatter ikke en ICC-arbeidsflyt, og den forteller deg ikke hva et spesifikt trykk og papir vil gi. Behandle den slik en prepress-operatør behandler en overtrykk-forhåndsvisning i en profesjonell leser — som sjekken som fanger feilene ingen fanger ved å se på en vanlig forhåndsvisning

Å passe korrektur inn i et preflight-trinn

Den nyttige plassen for dette er ved siden av sjekkene du allerede kjører. Et preflight-pass rapporterer at svart tekst er satt til overtrykk; en korrektur-rendring viser en operatør hva det betyr på siden; og begge går inn i den samme rapporten. For spot-farger, som ofte følger med overtrykk i emballasjearbeid, dekker gjennomgangen av Separation- og DeviceN-spot-farge-rendring fargeleggs-siden av den samme siden, mens notatene om rendring av en PDF-side til et bitmap og om utskrift av en innlastet PDF gjennom TPrinter dekker de to enhetsmålene i sin vanlige, ikke-korrektur-form

HotPDF renderer, korrektur-leser og skriver ut innlastede PDF-sider fra ren VCL-kode for Delphi og C++Builder, uten noen ekstern rendrings-DLL å utrulle ved siden av applikasjonen — HotPDF-komponentsiden har rendringsfunksjonslisten og en prøvebygg