HotPDF rendert eine geladene PDF-Seite über einen einzigen Einstiegspunkt, RenderLoadedPageToDevice, und das Gerät, das man ihm übergibt, entscheidet, ob das Ergebnis ein Bitmap, eine Zeichnung auf einem externen Geräte-Kontext wie einer Drucker-Canvas oder eine vektorielle Enhanced-Metadatei ist. Setzt man RenderOverprintPreview auf True, simuliert derselbe Aufruf den CMYK-Prozessfarben-Überdruck, sodass ein Bediener auf dem Bildschirm die Farbstoff-Interaktion sieht, die sonst nur auf dem Druckbogen erscheint
Die beiden Eigenschaften lösen unterschiedliche Probleme, die zufällig im selben Code-Pfad aufeinandertreffen. Die Geräte-Abstraktion beseitigt jenen Zweig, in dem Vorschau, Druck und Export jeweils einen eigenen Render-Aufruf mit eigenem Drift hatten. Das Überdruck-Proofing beseitigt die Klasse von Produktionsfehlern, bei denen ein Dokument in jedem Betrachter korrekt aussieht und von der Druckmaschine falsch kommt
Warum druckt eine Seite anders, als sie in der Vorschau erscheint?
Weil Überdruck eine Anweisung an das Belichtungsgerät ist, kein Mal-Vorgang. Wenn eine Seite /OP oder /op im Graphics-State auf wahr setzt, weist sie den RIP an, die darunter liegenden Farben nicht auszuknocken — ein Cyan-Objekt, das über Gelb gezeichnet wird, lässt das Gelb stehen, und der Bogen zeigt Grün. Ein Betrachter, der Überdruck ignoriert, knockt normal aus und zeigt Cyan. Keines von beiden ist für sich genommen falsch, und genau das ist das Problem: Bildschirm und Druckmaschine sind unterschiedlicher Meinung, und niemand erfährt es, bis die Proof-Bögen zurückkommen
RenderOverprintPreview bringt HotPDF dazu, die Anweisung für DeviceCMYK-Farben, die über /OP, /op und /OPM 1 gesteuert werden, ernst zu nehmen. Das Ergebnis ist eine Proof-Vorschau statt einer Betrachter-Vorschau: Schwarz, das eine Nuance überdruckt, bleibt eine satte Überlagerung statt ein Loch zu stanzen, und ein versehentlicher Überdruck des Designers auf weißem Text wird als der verschwindende Text sichtbar, der er sein wird
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;Die Einstellung geht in die Render-Cache-Identität ein, im Speicher und auf der Platte, sodass eine normale Vorschau und eine Proof-Vorschau niemals ein Bitmap teilen. Die Eigenschaft umzuschalten verlangt nicht, dass man etwas per Hand invalidiert — ein Cache, der hier die falsche der beiden zurückgäbe, wäre schlimmer als gar kein Cache
Drei Geräte, ein Render-Aufruf
THPDFRenderDevice ist eine abstrakte Klasse mit zwei Mitgliedern, die zählen: Kind, das das Ziel als rdkBitmap, rdkDeviceContext oder rdkEnhancedMetafile meldet, und Execute, das die Bibliothek aufruft. Drei konkrete Geräte werden mit HotPDF ausgeliefert, und jedes owned seine Ausgabe anders
THPDFBitmapRenderDevice owned ein TBitmap, bis TakeBitmap das Eigentum an den Aufrufer übergibt. THPDFDeviceContextRenderDevice nimmt einen bestehenden HDC samt Breite und Höhe und zeichnet direkt hinein, was es ermöglicht, auf eine Drucker-Canvas ohne Bitmap-Roundtrip zu rendern. THPDFMetafileRenderDevice owned ein TMetafile, bis TakeMetafile es übergibt, was Vektor-Inhalt für die Konsumenten, die ihn brauchen, als Vektor erhält
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;Dass Kind gelesen wird statt die Laufzeit-Klasse zu testen, ist Absicht. Anwendungs-Code, der nach Geräte-Art verzweigt, funktioniert weiter, wenn ein Gerät gewrappt, dekoriert oder ersetzt wird, und Code, der is THPDFBitmapRenderDevice testet, funktioniert nicht
Was die Eigentums-Übergabe in der Praxis bedeutet
Vor TakeBitmap oder TakeMetafile owned das Gerät das Objekt und gibt es in seinem Destruktor frei. Nach dem Aufruf owned man es selbst und das Gerät nicht mehr. Beide Muster sind legitim: die Eigenschaft Bitmap oder Metafile verwenden, wenn das Objekt nur den Render-Aufruf überdauern muss, und das Eigentum übernehmen, wenn das Objekt das Gerät überdauert
Der Fehlermodus ist der gewöhnliche Delphi-Fehlermodus. Das Bitmap nehmen, das Gerät freigeben, vergessen, das Bitmap freizugeben — und man hat ein Leak, das mit der Seitenzahl wächst, unsichtbar bei einem Fünf-Seiten-Test und offensichtlich bei einem Fünfhundert-Seiten-Batch. Beide Objekte jeweils in ein eigenes try/finally hüllen statt eines zu teilen, und die Eigentums-Frage beantwortet sich von selbst
Überdruck-Proofing und Transparenz auf derselben Seite
Das Knockout der Transparenz-Gruppe bleibt aktiv, wenn die Überdruck-Vorschau eingeschaltet ist, und beide werden in demselben begrenzten Paint-Snapshot-Pfad zusammengeführt. Das ist wichtig, weil echte druckfertige Dateien die beiden ständig mischen: eine Transparenz-Gruppe mit Grafik sitzt auf einem Hintergrund, dessen Schwarz auf Überdruck gesetzt ist, und das eine ohne das andere zu simulieren liefert einen Proof, der auf neue Weise falsch ist statt richtig
Die Grenzen im Blick behalten. Die Überdruck-Vorschau simuliert das Prozessfarben-Verhalten für DeviceCMYK-Farben unter den oben genannten Überdruck-Kontrollen. Sie ist ein Proof der Farbstoff-Interaktion, kein farbverwalteter verbindlicher Proof: Sie ersetzt keinen ICC-Workflow und sagt nicht, was eine bestimmte Druckmaschine mit einem bestimmten Papier ergeben wird. Man betrachte sie so, wie ein Prepress-Bediener eine Überdruck-Vorschau in einem professionellen Betrachter betrachtet — als jene Prüfung, die die Fehler einfängt, die niemand beim Blick auf eine normale Vorschau findet
Proofing in einen Preflight-Schritt einpassen
Der nützliche Ort dafür ist neben den Prüfungen, die ohnehin laufen. Ein Preflight-Durchlauf meldet, dass schwarzer Text auf Überdruck gesetzt ist; ein Proof-Render zeigt einem Bediener, was das auf der Seite bedeutet; und beides geht in denselben Bericht ein. Für Schmuckfarben, die in der Verpackungs-Arbeit häufig zusammen mit Überdruck auftreten, behandelt die Erläuterung zur Separation- und DeviceN-Schmuckfarben-Darstellung die Farbstoff-Seite derselben Seite, während die Hinweise zum Rendern einer PDF-Seite auf ein Bitmap und zum Drucken eines geladenen PDF über TPrinter die beiden Geräte-Ziele in ihrer schlichten, nicht Proof-Form behandeln
HotPDF rendert, prüft und druckt geladene PDF-Seiten aus nativem VCL-Code für Delphi und C++Builder, ohne dass eine externe Render-DLL neben der Anwendung ausgeliefert werden muss — die HotPDF-Komponenten-Seite führt die Render-Funktionsliste und einen Trial-Build