CMYK-övertrycksskanning och renderingsenheter i HotPDF

HotPDF renderar en laddad PDF-sida genom en ingång, RenderLoadedPageToDevice, och enheten du lämnar över bestämmer huruvida resultatet är en bitmap, en ritning på en extern enhetskontext såsom en skrivaryta, eller en vektoriell förbättrad metafil. Sätt RenderOverprintPreview till True så simulerar samma anrop CMYK-processfärgsövertryck, så en operatör ser på skärmen den färgerverkan som annars bara skulle synas på tryckarket

De två funktionerna löser olika problem som råkar mötas i samma kodväg. Enhetsabstraktionen tar bort den gren där förhandsvisning, utskrift och export var och en hade sitt eget renderingsanrop med sin egen drift. Övertrycksskanningen tar bort den klass av produktionsfel där ett dokument ser korrekt ut i varje visare och kommer från pressen fel

Varför skrivs en sida ut annorlunda än den förhandsvisas?

Eftersom övertryck är en instruktion till avbildningsenheten, inte en målningsoperation. När en sida sätter /OP eller /op sant i grafiktillståndet säger den till RIP:en att inte slå ut färgerna under — ett cyanobjekt ritat över gult lämnar det gula på plats, och arket visar grönt. En visare som ignorerar övertryck slår ut normalt och visar cyan. Inget av dem är fel på egna villkor, och det är precis problemet: skärmen och pressen är oense, och ingen får veta förrän korrekturet kommer tillbaka

RenderOverprintPreview får HotPDF att ta instruktionen på allvar för DeviceCMYK-målningar styrda av /OP, /op och /OPM 1. Resultatet är en skanningsförhandsvisning i stället för en visarförhandsvisning: svart som övertrycker en toning förblir ett riktigt överlag i stället för att slå ut en bit, och en designers oavsiktliga övertryck på vit text blir synlig som den försvinnande text den kommer 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;

Inställningen deltar i renderingscache-identiteten, i minnet och på disk, så en normal förhandsvisning och en skanningsförhandsvisning delar aldrig en bitmap. Att växla egenskapen kräver inte att du invaliderar någonting för hand — en cache som returnerade fel av dessa två skulle vara värre än ingen cache alls

Tre enheter, ett renderingsanrop

THPDFRenderDevice är en abstrakt klass med två medlemmar som betyder något: Kind, som rapporterar målet som rdkBitmap, rdkDeviceContext eller rdkEnhancedMetafile, och Execute, som biblioteket anropar. Tre konkreta enheter skeppas med HotPDF, och var och en äger sin utdata olika

THPDFBitmapRenderDevice äger en TBitmap tills TakeBitmap överför ägandeskapet till dig. THPDFDeviceContextRenderDevice tar en befintlig HDC plus bredd och höjd och ritar rakt in i den, vilket är hur du renderar på en skrivaryta utan en bitmap-rundtur. THPDFMetafileRenderDevice äger en TMetafile tills TakeMetafile överför den, vilket behåller vektoriellt innehåll som vektorer för de konsumenter som behöver 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;

Att läsa Kind i stället för att testa den runtime-klass är avsiktligt. Applikationskod som dispatchar på enhetsslag fungerar fortfarande när en enhet sveps in, dekoreras eller byts ut, och kod som testar is THPDFBitmapRenderDevice gör det inte

Vad ägarövertagande betyder i praktiken

Innan TakeBitmap eller TakeMetafile äger enheten objektet och frigör det i sin destruktor. Efter anropet äger du det och enheten gör det inte längre. Båda mönstren är legitima: använd egenskapen Bitmap eller Metafile när objektet bara ska överleva renderingsanropet, och ta ägandeskap när objektet överlever enheten

Felltillståndet är det vanliga Delphi-fallet. Ta bitmappen, frigör enheten, glöm att frigöra bitmappen, och du har en läcka som växer med sidantal — osynlig på ett femsidors test och uppenbar på en femhundrasidors batch. Svep in båda objekten i sina egna try/finally i stället för att dela en, och ägarfrågan besvarar sig själv

Övertrycksskanning och genomskinlighet på samma sida

Genomskinlighetsgruppens knockout förblir aktiv när övertrycksförhandsvisning är på, och båda komponeras i samma avgränsade målningsögonblicksbilds-väg. Detta betyder något eftersom verkliga tryckfärdiga filer hela tiden blandar de två: en genomskinlighetsgrupp som håller grafik sitter på en bakgrund vars svart är satt till övertryck, och att simulera den ena utan den andra producerar ett skanning som är fel på ett nytt sätt i stället för rätt

Behåll gränserna i sikte. Övertrycksförhandsvisning simulerar processfärgsbeteende för DeviceCMYK-målningar under de övertryckskontroller som namnges ovan. Det är ett skanning av färgerverkan, inte ett färghanterat kontraktskorrekt: det ersätter inte ett ICC-arbetsflöde, och det talar inte om för dig vad en specifik press och ett specifikt papper kommer ge. Behandla det så som ett prepress-operatör behandlar en övertrycksförhandsvisning i en professionell visare — som den kontroll som fångar de fel ingen fångar genom att titta på en normal förhandsvisning

Att passa in skanning i ett preflight-steg

Den användbara platsen för detta är bredvid de kontroller du redan kör. En preflight-pass rapporterar att svart text är satt till övertryck; en skanningsrendering visar en operatör vad det betyder på sidan; och båda hamnar i samma rapport. För toningsfärger, som ofta följer med övertryck i förpackningsarbete, täcker genomgången av Separation- och DeviceN-toningsfärgsrendering färghalvan av samma sida, medan noterna om att rendera en PDF-sida till en bitmap och om att skriva ut en laddad PDF genom TPrinter täcker de två enhetsmålen i deras vanliga, icke-skannings form

HotPDF renderar, skannar och skriver ut laddade PDF-sidor från inbyggd VCL-kod för Delphi och C++Builder, utan extern renderings-DLL att distribuera bredvid applikationen — HotPDF-komponentsidan har renderingsfunktionslistan och ett testbygge