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; // 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;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