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 metarchivo vectorial enriquecido. Pon RenderOverprintPreview en True y la misma llamada simula el overprint de tintas de proceso CMYK, así que un operador ve en pantalla la interacción de tintas que de otro modo solo aparecería en la hoja de la prensa
Estas dos características resuelven problemas distintos que coinciden en la misma ruta de código. La abstracción de dispositivo elimina la bifurcación donde 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 overprint elimina la clase de error de producción en la que un documento se ve correcto en todos los visores y sale mal de la prensa
¿Por qué una página se imprime distinto a como se previsualiza?
Porque el overprint es una instrucción al dispositivo de formado de imagen, no una operación de pintura. Cuando una página pone /OP o /op en verdadero en el estado de gráficos, le está diciendo al RIP que no tire las tintas que están debajo — un objeto cian dibujado sobre amarillo deja el amarillo en su lugar, y la hoja muestra verde. Un visor que ignora el overprint hace el knockout normalmente y muestra cian. Ninguno está equivocado en sus propios términos, y ese es exactamente el problema: la pantalla y la prensa discrepan, y nadie se entera hasta que las pruebas regresan
RenderOverprintPreview hace que HotPDF tome en serio la instrucción para pinturas DeviceCMYK gobernadas por /OP, /op y /OPM 1. El resultado es una vista previa de prueba en vez de una vista previa de visor: el negro que sobrepinta un tono se mantiene como un sobrelape rico en vez de perforar un hueco, y el overprint accidental de un diseñador sobre texto blanco se vuelve 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 en la identidad de la caché de render, en memoria y en disco, así que una vista previa normal y una vista previa de prueba nunca comparten un mismo mapa de bits. Alternar la propiedad no requiere que invalides nada a mano — una caché que devolviera la equivocada de estas dos sería peor que ninguna caché
Tres dispositivos, una llamada de render
THPDFRenderDevice es una clase abstracta con dos miembros que importan: Kind, que reporta el destino como rdkBitmap, rdkDeviceContext o rdkEnhancedMetafile, y Execute, al que la biblioteca llama. Tres dispositivos concretos se incluyen con HotPDF, y cada uno es dueño de su salida de forma distinta
THPDFBitmapRenderDevice posee un TBitmap hasta que TakeBitmap transfiere la propiedad a ti. THPDFDeviceContextRenderDevice toma un HDC existente más ancho y alto y dibuja directamente en él, que es cómo renderizas sobre el lienzo de una impresora sin un viaje intermedio por mapa de bits. THPDFMetafileRenderDevice posee un TMetafile hasta que TakeMetafile lo transfiere, lo cual 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 vez de probar la clase en tiempo de ejecución es deliberado. El código de aplicación que despacha según el tipo 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, tú lo posees 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 falla es el habitual de Delphi. Toma el mapa de bits, libera el dispositivo, olvida liberar el mapa de bits, y tienes una fuga que crece con la cantidad 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 vez de compartir uno, y la pregunta de propiedad se responde sola
Prueba de overprint y transparencia en la misma página
El knockout del grupo de transparencia se mantiene activo cuando la vista previa de overprint está activada, y ambos se componen en la misma ruta de instantánea de pintura acotada. Esto importa porque los archivos reales listos para imprenta mezclan ambos constantemente: un grupo de transparencia que sostiene el arte va sobre un fondo cuyo negro está puesto en overprint, y simular uno sin el otro produce una prueba equivocada de una forma nueva en vez de correcta
Sí mantén los límites a la vista. La vista previa de overprint simula el comportamiento de tintas de proceso para pinturas DeviceCMYK bajo los controles de overplay nombrados arriba. Es una prueba de interacción de tintas, no una prueba contractual con gestión de color: no reemplaza un flujo ICC, y no te dice qué rendimiento darán una prensa y un sustrato específicos. Trátala como un operador de preprensas trata una vista previa de overprint en un visor profesional — como la verificación que atrapa los errores que nadie atrapa mirando una vista previa normal
Dónde encaja la prueba junto a un paso de preflight
El lugar útil para esto es junto a las verificaciones que ya ejecutas. Un pase de preflight reporta que el texto negro está puesto en overprint; un render de prueba le muestra a un operador qué significa eso en la página; y ambos van al mismo reporte. Para los colores de tinta directa, que con frecuencia acompañan al overprint en trabajo de empaque, 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 DLL de render externo para desplegar junto con la aplicación — la página del componente HotPDF tiene la lista de características de render y una compilación de prueba