HotPDF renderizza una pagina PDF caricata attraverso un unico punto di ingresso, RenderLoadedPageToDevice, e il device che gli passi decide se il risultato è una bitmap, un disegno su un device context esterno come una canvas di stampa, o un enhanced metafile vettoriale. Imposta RenderOverprintPreview a True e la stessa chiamata simula l'overprint degli inchiostri di quadricromia CMYK, così un operatore vede a schermo l'interazione tra inchiostri che altrimenti apparirebbe solo sul foglio di stampa
Queste due funzionalità risolvono problemi diversi che si incontrano casualmente nello stesso percorso di codice. L'astrazione del device rimuove il branch in cui anteprima, stampa ed esportazione avevano ciascuna la propria chiamata di rendering con la propria deriva. Il proofing overprint rimuove la classe di errori di produzione in cui un documento appare corretto in ogni visualizzatore e arriva dalla stampa sbagliato
Perché una pagina si stampa diversamente da come si vede in anteprima?
Perché l'overprint è un'istruzione al dispositivo di imaging, non un'operazione di paint. Quando una pagina imposta /OP o /op a true nello stato grafico, sta dicendo al RIP di non abbattere gli inchiostri sottostanti — un oggetto ciano disegnato sopra il giallo lascia il giallo al suo posto, e il foglio mostra verde. Un visualizzatore che ignora l'overprint abbatte normalmente e mostra ciano. Nessuno dei due è sbagliato nei propri termini, ed è esattamente questo il problema: lo schermo e la stampa non sono d'accordo, e nessuno lo scopre finché non tornano le bozze
RenderOverprintPreview fa sì che HotPDF prenda sul serio l'istruzione per le tinte DeviceCMYK governate da /OP, /op e /OPM 1. Il risultato è un'anteprima di proofing anziché di visualizzazione: il nero che sovrastampa una tinta resta una sovrapposizione ricca invece di scavare un buco, e l'overprint accidentale di un designer su testo bianco diventa visibile come il testo che scompare che sarà
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;L'impostazione partecipa all'identità della render cache, in memoria e su disco, così un'anteprima normale e una di proofing non condividono mai una bitmap. Attivare o disattivare la proprietà non richiede di invalidare nulla a mano — una cache che restituisse quella sbagliata tra le due sarebbe peggiore di nessuna cache
Tre device, una chiamata di rendering
THPDFRenderDevice è una classe astratta con due membri che contano: Kind, che riporta il target come rdkBitmap, rdkDeviceContext o rdkEnhancedMetafile, ed Execute, che la libreria chiama. Tre device concreti sono forniti con HotPDF, e ciascuno possiede il proprio output in modo diverso
THPDFBitmapRenderDevice possiede una TBitmap finché TakeBitmap non trasferisce la proprietà a te. THPDFDeviceContextRenderDevice prende una HDC esistente più larghezza e altezza e disegna direttamente dentro di essa, che è come renderizzi su una canvas di stampa senza un passaggio tramite bitmap. THPDFMetafileRenderDevice possiede un TMetafile finché TakeMetafile non lo trasferisce, il che mantiene il contenuto vettoriale come vettori per i consumer che lo richiedono
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;Leggere Kind anziché testare la classe a runtime è deliberato. Il codice applicativo che fa dispatch sul tipo di device continua a funzionare quando un device viene avvolto, decorato o sostituito, e il codice che testa is THPDFBitmapRenderDevice no
Cosa significa in pratica il trasferimento di proprietà
Prima di TakeBitmap o TakeMetafile, il device possiede l'oggetto e lo libera nel proprio distruttore. Dopo la chiamata, lo possiedi tu e il device non più. Entrambi gli schemi sono legittimi: usa la proprietà Bitmap o Metafile quando l'oggetto deve solo sopravvivere alla chiamata di rendering, e prendine la proprietà quando l'oggetto sopravvive al device
La modalità di fallimento è quella ordinaria di Delphi. Prendi la bitmap, liberi il device, dimentichi di liberare la bitmap, e hai una perdita che cresce con il numero di pagine — invisibile in un test da cinque pagine ed evidente in un batch da cinquecento. Avvolgi entrambi gli oggetti nel loro try/finally anziché condividerne uno, e la questione della proprietà si risolve da sola
Proofing overprint e trasparenza nella stessa pagina
Il knockout del gruppo di trasparenza resta attivo quando l'anteprima overprint è attiva, ed entrambi vengono composti nello stesso percorso di paint snapshot delimitato. Questo conta perché i file reali pronti per la stampa mescolano costantemente i due: un gruppo di trasparenza che contiene artwork sta su uno sfondo il cui nero è impostato a overprint, e simularne uno senza l'altro produce una bozza sbagliata in un modo nuovo anziché giusta
Tieni comunque presenti i limiti. L'anteprima overprint simula il comportamento degli inchiostri di processo per le tinte DeviceCMYK sotto i controlli di overprint nominati sopra. È una prova di interazione tra inchiostri, non una bozza contrattuale gestita nel colore: non sostituisce un flusso ICC, e non ti dice cosa restituirà uno specifico stampo e supporto. Trattala come un operatore di prepress tratta un'anteprima overprint in un visualizzatore professionale — come il controllo che intercetta gli errori che nessuno intercetta guardando un'anteprima normale
Inserire il proofing in un passo di preflight
Il posto utile per questa funzionalità è accanto ai controlli che già esegui. Un passo di preflight riporta che il testo nero è impostato a overprint; un render di proofing mostra a un operatore cosa significa sulla pagina; ed entrambi finiscono nello stesso rapporto. Per i colori spot, che accompagnano spesso l'overprint nel lavoro di packaging, la guida sul rendering dei colori spot Separation e DeviceN copre il lato coloranti della stessa pagina, mentre le note sul rendering di una pagina PDF in bitmap e sulla stampa di un PDF caricato tramite TPrinter coprono i due target di device nella loro forma semplice, non di proofing
HotPDF renderizza, fa proofing e stampa pagine PDF caricate da codice VCL nativo per Delphi e C++Builder, senza alcuna DLL di rendering esterna da distribuire insieme all'applicazione — la pagina del componente HotPDF ha la lista delle funzionalità di rendering e una build di prova