Prova de Overprint CMYK e Dispositivos de Render no HotPDF

O HotPDF renderiza uma página PDF carregada por um único ponto de entrada, RenderLoadedPageToDevice, e o dispositivo que você entrega decide se o resultado é um bitmap, um desenho em um contexto de dispositivo externo como uma canvas de impressora, ou um enhanced metafile vetorial. Defina RenderOverprintPreview como True e a mesma chamada simula overprint de tintas CMYK de processo, então um operador vê na tela a interação de tintas que de outro modo só apareceria na chapa da impressora

Esses dois recursos resolvem problemas diferentes que por acaso se encontram no mesmo caminho de código. A abstração de dispositivo elimina o ramo em que preview, impressão e exportação tinham cada um sua própria chamada de render com sua própria deriva. A prova de overprint elimina a classe de erro de produção em que um documento parece correto em todos os visualizadores e sai errado da impressora

Por que uma página imprime diferente de como pré-visualiza?

Porque overprint é uma instrução ao dispositivo de imagem, não uma operação de pintura. Quando uma página define /OP ou /op true no estado gráfico, está dizendo ao RIP para não remover as tintas por baixo — um objeto ciano desenhado sobre amarelo deixa o amarelo no lugar, e a chapa mostra verde. Um visualizador que ignora overprint remove normalmente e mostra ciano. Nenhum dos dois está errado em seus próprios termos, e esse é exatamente o problema: a tela e a impressora discordam, e ninguém descobre até as provas voltarem

RenderOverprintPreview faz o HotPDF levar a instrução a sério para pinturas DeviceCMYK governadas por /OP, /op e /OPM 1. O resultado é uma preview de prova em vez de uma preview de visualizador: preto sobreimprimindo uma tintura segue como uma sobreposição rica em vez de abrir um buraco, e o overprint acidental de um designer em texto branco torna-se visível como o texto desaparecido que ele virá a ser

var
  Pdf: THotPDF;
  Device: THPDFBitmapRenderDevice;
  Proof: TBitmap;
begin
  Pdf := THotPDF.Create(nil);
  try
    Pdf.LoadFromFile('cover-cmyk.pdf');
    Pdf.RenderOverprintPreview := True;    // prova, não uma pré-visualização simples
    Device := THPDFBitmapRenderDevice.Create;
    try
      if Pdf.RenderLoadedPageToDevice(0, 150, Device) then
      begin
        Proof := Device.TakeBitmap;        // a posse passa para o chamador
        try
          Image1.Picture.Assign(Proof);
        finally
          Proof.Free;
        end;
      end;
    finally
      Device.Free;
    end;
  finally
    Pdf.Free;
  end;
end;

A configuração participa da identidade do cache de render, em memória e em disco, então uma preview normal e uma preview de prova nunca compartilham um bitmap. Alternar a propriedade não exige que você invalide nada à mão — um cache que devolvesse a errada entre essas duas seria pior do que nenhum cache

Três dispositivos, uma chamada de render

THPDFRenderDevice é uma classe abstrata com dois membros que importam: Kind, que informa o destino como rdkBitmap, rdkDeviceContext ou rdkEnhancedMetafile, e Execute, que a biblioteca chama. Três dispositivos concretos vêm com o HotPDF, e cada um detém sua saída de modo diferente

THPDFBitmapRenderDevice detém um TBitmap até que TakeBitmap transfira a propriedade a você. THPDFDeviceContextRenderDevice recebe uma HDC existente mais largura e altura e desenha direto nela, que é como você renderiza em uma canvas de impressora sem uma ida e volta por bitmap. THPDFMetafileRenderDevice detém um TMetafile até que TakeMetafile o transfira, o que mantém conteúdo vetorial como vetorial para os consumidores que precisam disso

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;

Ler Kind em vez de testar a classe em runtime é deliberado. Código de aplicação que faz dispatch sobre o tipo de dispositivo continua funcionando quando um dispositivo é envolvido, decorado ou substituído, e código que testa is THPDFBitmapRenderDevice não continua

O que a transferência de propriedade significa na prática

Antes de TakeBitmap ou TakeMetafile, o dispositivo detém o objeto e o libera em seu destrutor. Depois da chamada, você o detém e o dispositivo não mais. Ambos os padrões são legítimos: use a propriedade Bitmap ou Metafile quando o objeto só precisa sobreviver à chamada de render, e tome a propriedade quando o objeto sobrevive ao dispositivo

O modo de falha é o Delphi comum. Pegue o bitmap, libere o dispositivo, esqueça de liberar o bitmap, e você tem um vazamento que cresce com a contagem de páginas — invisível em um teste de cinco páginas e óbvio em um lote de quinhentas. Envolva ambos os objetos em seu próprio try/finally em vez de compartilhar um, e a questão de propriedade se responde sozinha

Prova de overprint e transparência na mesma página

O knockout de transparency group segue ativo quando a preview de overprint está ligada, e ambos são compostos no mesmo caminho de snapshot de pintura delimitado. Isso importa porque arquivos reais prontos para impressão misturam o tempo todo os dois: um transparency group segurando arte está sobre um fundo cujo preto está configurado para overprint, e simular um sem o outro produz uma prova errada de um jeito novo em vez de certa

Mas mantenha os limites à vista. A preview de overprint simula o comportamento de tinta de processo para pinturas DeviceCMYK sob os controles de overprint nomeados acima. É uma prova de interação de tintas, não uma prova contratual gerida por cores: não substitui um fluxo ICC, e não diz o que uma impressora e um papel específicos vão produzir. Trate como um operador de pré-impressão trata uma preview de overprint em um visualizador profissional — como a verificação que pega os erros que ninguém pega olhando uma preview normal

Encaixando a prova em uma etapa de preflight

O lugar útil para isso é ao lado das verificações que você já roda. Uma passagem de preflight relata que texto preto está configurado para overprint; uma render de prova mostra a um operador o que isso significa na página; e ambas vão para o mesmo relatório. Para spot colors, que frequentemente acompanham overprint em trabalho de embalagens, o guia sobre render de Separation e DeviceN para spot colors cobre o lado dos corantes da mesma página, enquanto as notas sobre renderizar uma página PDF em bitmap e sobre imprimir um PDF carregado por TPrinter cobrem os dois destinos de dispositivo em sua forma simples, sem prova

O HotPDF renderiza, prova e imprime páginas PDF carregadas a partir de código VCL nativo para Delphi e C++Builder, sem nenhuma DLL externa de render para implantar ao lado da aplicação — a página do componente HotPDF tem a lista de recursos de render e uma build de avaliação