HotPDF rend une page PDF chargée via un seul point d'entrée, RenderLoadedPageToDevice, et le périphérique que vous lui fournissez décide si le résultat est un bitmap, un dessin sur un contexte de périphérique externe tel qu'un canvas d'imprimante, ou un métafichier amélioré vectoriel. Réglez RenderOverprintPreview à True et le même appel simule la surimpression CMYK d'encres process, donc un opérateur voit à l'écran l'interaction d'encres qui n'apparaîtrait autrement que sur la feuille de presse
Ces deux fonctionnalités résolvent des problèmes différents qui se rencontrent par hasard dans le même chemin de code. L abstraction de périphérique supprime la branche où aperçu, impression et export avaient chacun leur propre appel de rendu avec leur propre dérive. L épreuvage de surimpression supprime la classe d'erreur de production où un document paraît correct dans chaque visionneuse et sort de presse faux
Pourquoi une page s'imprime-t-elle différemment de son aperçu ?
Parce que la surimpression est une instruction au périphérique d'impression, pas une opération de peinture. Quand une page règle /OP ou /op à true dans l'état graphique, elle dit au RIP de ne pas réserver les encres du dessous — un objet cyan dessiné sur du jaune laisse le jaune en place, et la feuille montre du vert. Une visionneuse qui ignore la surimpression réserve normalement et montre du cyan. Aucun n'a tort en ses propres termes, et c'est exactement le problème : l'écran et la presse ne sont pas d'accord, et personne ne le découvre jusqu'au retour des épreuves
RenderOverprintPreview fait que HotPDF prend l'instruction au sérieux pour les peintures DeviceCMYK régies par /OP, /op et /OPM 1. Le résultat est un aperçu d'épreuve plutôt qu'un aperçu de visionneuse : le noir surimprimant une teinte reste un riche recouvrement au lieu de percer un trou, et la surimpression accidentelle d'un designer sur du texte blanc devient visible comme le texte disparaissant qu'il sera
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;Le réglage participe à l'identité du cache de rendu, en mémoire et sur disque, donc un aperçu normal et un aperçu d'épreuve ne partagent jamais un bitmap. Basculer la propriété ne vous demande rien d'invalider à la main — un cache qui renverrait la mauvaise de ces deux-là serait pire qu'aucun cache du tout
Trois périphériques, un appel de rendu
THPDFRenderDevice est une classe abstraite avec deux membres qui comptent : Kind, qui signale la cible comme rdkBitmap, rdkDeviceContext ou rdkEnhancedMetafile, et Execute, que la bibliothèque appelle. Trois périphériques concrets sont livrés avec HotPDF, et chacun possède sa sortie différemment
THPDFBitmapRenderDevice possède un TBitmap jusqu'à ce que TakeBitmap transfère la propriété à vous. THPDFDeviceContextRenderDevice prend un HDC existant plus largeur et hauteur et dessine directement dedans, ce qui est la façon de rendre sur un canvas d'imprimante sans aller-retour bitmap. THPDFMetafileRenderDevice possède un TMetafile jusqu'à ce que TakeMetafile le transfère, ce qui garde le contenu vectoriel comme vecteurs pour les consommateurs qui en ont besoin
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;Lire Kind plutôt que tester la classe à l'exécution est délibéré. Le code applicatif qui se répartit sur le genre de périphérique continue de fonctionner quand un périphérique est encapsulé, décoré ou remplacé, et le code qui teste is THPDFBitmapRenderDevice non
Ce que le transfert de propriété signifie en pratique
Avant TakeBitmap ou TakeMetafile, le périphérique possède l'objet et le libère dans son destructeur. Après l'appel, vous le possédez et le périphérique ne le fait plus. Les deux motifs sont légitimes : utilisez la propriété Bitmap ou Metafile quand l'objet n'a qu'à survivre à l'appel de rendu, et prenez possession quand l'objet survit au périphérique
Le mode d'échec est celui de Delphi ordinaire. Prenez le bitmap, libérez le périphérique, oubliez de libérer le bitmap, et vous avez une fuite qui grandit avec le nombre de pages — invisible sur un test de cinq pages et évidente sur un lot de cinq cents. Encapsulez les deux objets dans leur propre try/finally plutôt que d'en partager un, et la question de propriété se répond elle-même
Épreuvage de surimpression et transparence dans la même page
Le knockout de groupe de transparence reste actif quand l'aperçu de surimpression est activé, et les deux sont composés dans le même chemin de snapshot de peinture bornée. Cela compte car les fichiers réels prêts à imprimer mélangent constamment les deux : un groupe de transparence portant de l'artwork est posé sur un arrière-plan dont le noir est réglé pour surimprimer, et simuler l'un sans l'autre produit une épreuve fausse d'une nouvelle façon plutôt que juste
Gardez les limites en vue. L aperçu de surimpression simule le comportement des encres process pour les peintures DeviceCMYK sous les contrôles de surimpression nommés ci-dessus. C'est une épreuve d'interaction d'encres, pas une épreuve contractuelle gérée en couleur : elle ne remplace pas un flux ICC et ne vous dit pas ce qu'une presse et un support spécifiques produiront. Traitez-la comme un opérateur de prépresse traite un aperçu de surimpression dans une visionneuse professionnelle — comme le contrôle qui attrape les erreurs que personne n'attrape en regardant un aperçu normal
Intégrer l'épreuvage dans une étape de préflight
L endroit utile pour cela est à côté des contrôles que vous exécutez déjà. Une passe de préflight signale que du texte noir est réglé pour surimprimer ; un rendu d'épreuve montre à un opérateur ce que cela signifie sur la page ; et les deux vont dans le même rapport. Pour les couleurs d'aplats, qui accompagnent fréquemment la surimpression dans le travail d'emballage, la visite guidée de rendu des couleurs d'aplats Separation et DeviceN couvre le côté colorants de la même page, tandis que les notes sur le rendu d'une page PDF en bitmap et sur l'impression d'un PDF chargé via TPrinter couvrent les deux cibles de périphérique dans leur forme simple non épreuve
HotPDF rend, épreuve et imprime des pages PDF chargées depuis du code VCL natif pour Delphi et C++Builder, sans aucune DLL de rendu externe à déployer à côté de l'application — la page composant HotPDF a la liste des fonctionnalités de rendu et une version d'essai