HotPDF renderiza una página PDF cargada a través de un único punto de entrada, RenderLoadedPageToDevice, y el dispositivo que le entregas decide si el resultado es un mapa de bits, un dibujo sobre un contexto de dispositivo externo como el lienzo de una impresora o un metafile vectorial mejorado. Pon RenderOverprintPreview a True y la misma llamada simula la sobimpresión de tintas de cuatricromía, de modo que un operario ve en pantalla la interacción de tintas que de otro modo solo aparecería en el pliego de imprenta
Esas dos características resuelven problemas distintos que por casualidad se encuentran en el mismo cauce de código. La abstracción de dispositivo elimina la rama en que la vista previa, la impresión y la exportación tenían cada una su propia llamada de render con su propia deriva. La prueba de sobimpresión elimina la clase de error de producción en que un documento se ve correcto en cualquier visor y sale mal de la imprenta
¿Por qué una página imprime distinto de como se previsualiza?
Porque la sobimpresión es una instrucción al dispositivo de impresión, no una operación de pintado. Cuando una página activa /OP o /op en el estado gráfico, le está diciendo al RIP que no elimine las tintas que hay debajo —un objeto cian dibujado sobre amarillo deja el amarillo en su sitio, y el pliego muestra verde—. Un visor que ignora la sobimpresión elimina con normalidad y muestra cian. Ninguno está equivocado en sus propios términos, y ese es justamente el problema: la pantalla y la imprenta discrepan, y nadie se entera hasta que vuelven las pruebas
RenderOverprintPreview hace que HotPDF tome en serio la instrucción para pintas DeviceCMYK gobernadas por /OP, /op y /OPM 1. El resultado es una vista previa de prueba en lugar de una vista previa de visor: el negro que sobimprime sobre un tono sigue siendo un solapado rico en lugar de abrir un agujero, y la sobimpresión accidental de un diseñador sobre texto en blanco se hace visible como el texto que desaparece que llegará 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;El ajuste participa de la identidad de la caché de render, en memoria y en disco, de modo que una vista previa normal y una de prueba nunca comparten mapa de bits. Conmutar la propiedad no exige invalidar nada a mano —una caché que devolviera la equivocada de las dos sería peor que no tener caché alguna—
Tres dispositivos, una sola llamada de render
THPDFRenderDevice es una clase abstracta con dos miembros relevantes: Kind, que informa del destino como rdkBitmap, rdkDeviceContext o rdkEnhancedMetafile, y Execute, al que la librería invoca. HotPDF se entrega con tres dispositivos concretos, y cada uno es dueño de su salida de forma distinta
THPDFBitmapRenderDevice posee un TBitmap hasta que TakeBitmap te transfiere la propiedad. THPDFDeviceContextRenderDevice toma un HDC existente más ancho y alto y dibuja directamente en él, que es como se renderiza sobre el lienzo de una impresora sin un ir y venir de mapa de bits. THPDFMetafileRenderDevice posee un TMetafile hasta que TakeMetafile lo transfiere, lo que mantiene el contenido vectorial como vectores para los consumidores que lo necesitan
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;Leer Kind en lugar de probar la clase en tiempo de ejecución es deliberado. El código de aplicación que despacha según la clase de dispositivo sigue funcionando cuando un dispositivo se envuelve, decora o sustituye, y el código que prueba is THPDFBitmapRenderDevice no
Qué significa en la práctica la transferencia de propiedad
Antes de TakeBitmap o TakeMetafile, el dispositivo posee el objeto y lo libera en su destructor. Después de la llamada, lo posees tú y el dispositivo ya no. Ambos patrones son legítimos: usa la propiedad Bitmap o Metafile cuando el objeto solo tiene que sobrevivir a la llamada de render, y toma la propiedad cuando el objeto sobrevive al dispositivo
El modo de fallo es el ordinario de Delphi. Toma el mapa de bits, libera el dispositivo, olvidate de liberar el mapa de bits, y tienes una fuga que crece con el número de páginas —invisible en una prueba de cinco páginas y obvia en un lote de quinientas—. Envuelve ambos objetos en su propio try/finally en lugar de compartir uno, y la cuestión de la propiedad se responde sola
Prueba de sobimpresión y transparencia en la misma página
El knockout del grupo de transparencia sigue activo cuando la vista previa de sobimpresión está activada, y ambos se componen en el mismo cauce de instantánea de pintado delimitada. Esto importa porque los archivos reales listos para imprimir mezclan ambos constantemente: un grupo de transparencia que contiene la ilustración se asienta sobre un fondo cuyo negro está fijado a sobimpresión, y simular uno sin el otro produce una prueba errónea de una forma nueva en lugar de acertada
Eso sí, mantén los límites a la vista. La vista previa de sobimpresión simula el comportamiento de las tintas de cuatricromía para pintas DeviceCMYK bajo los controles de sobimpresión mencionados. Es una prueba de interacción de tintas, no una prueba contractual con gestión de color: no sustituye a un flujo ICC, y no dice lo que rendirán una imprenta y un sustrato concretos. Trátala como un operario de preimpresión trata una vista previa de sobimpresión en un visor profesional —como la comprobación que atrapa los errores que nadie atrapa mirando una vista previa normal—
Encajar la prueba en un paso de preflight
El sitio útil para esto es junto a las comprobaciones que ya ejecutas. Un paso de preflight informa de que el texto en negro está fijado a sobimpresión; un render de prueba muestra a un operario qué significa eso en la página; y ambas cosas van al mismo informe. Para los colores de tinta directa, que con frecuencia acompañan a la sobimpresión en el trabajo de envases, el recorrido por el render de colores directos Separation y DeviceN cubre el lado de los colorantes de la misma página, mientras que las notas sobre cómo renderizar una página PDF a un mapa de bits y sobre cómo imprimir un PDF cargado a través de TPrinter cubren los dos destinos de dispositivo en su forma simple, sin prueba
HotPDF renderiza, prueba e imprime páginas PDF cargadas desde código VCL nativo para Delphi y C++Builder, sin ninguna DLL de render externa que desplegar junto a la aplicación; la página del componente HotPDF tiene la lista de características de render y una build de prueba