HotPDF یک صفحه PDF بارگذاریشده را از طریق یک نقطه ورودی، RenderLoadedPageToDevice رندر میکند، و دستگاهی که تحویلش میدهید تصمیم میگیرد نتیجه یک bitmap، یک رسم روی یک device context خارجی مانند canvas چاپگر، یا یک enhanced metafile برداری است. RenderOverprintPreview را روی True تنظیم کنید و همان فراخوانی overprint جوهر فرآیندی CMYK را شبیهسازی میکند، تا یک اپراتور روی صفحه تعامل جوهری را ببیند که در غیر این صورت تنها روی برگه چاپ ظاهر میشد
آن دو ویژگی مسئلههای متفاوتی را حل میکنند که اتفاقاً در همان مسیر کد ملاقات میکنند. انتزاع دستگاه آن شاخه را حذف میکند که پیشنمایش، چاپ و صادرات هر کدام فراخوانی رندر خودشان با انحراف خودشان داشتند. اثبات overprint آن دسته از خطای تولید را حذف میکند که در آن سندی در هر viewer درست بهنظر میرسد و از چاپخانه اشتباه بیرون میآید
چرا یک صفحه متفاوت از پیشنمایشاش چاپ میشود؟
چون overprint یک دستور به دستگاه تصویربرداری است، نه یک عملیات رنگ. وقتی یک صفحه /OP یا /op را در graphics state درست تنظیم میکند، به RIP میگوید جوهرهای زیرین را knockout نکند — یک شیء فیروزهای روی زرد کشیدهشده زرد را سر جای خود نگه میدارد، و برگه سبز نشان میدهد. viewerی که overprint را نادیده میگیرد بهطور معمولی knockout میکند و فیروزهای نشان میدهد. هیچکدام بهتنهایی اشتباه نیست، و دقیقاً مسئله همین است: صفحه و چاپخانه مخالفند، و هیچکس تا زمانی که proofها برنمیگردند نمیفهمد
RenderOverprintPreview HotPDF را وامیدارد دستور را برای رنگهای DeviceCMYK که توسط /OP، /op و /OPM 1 اداره میشوند جدی بگیرد. نتیجه یک پیشنمایش اثبات است نه یک پیشنمایش viewer: سیاه overprint روی یک رنگ، یک overlay غنی میماند بهجای آنکه یک سوراخ بزند، و overprint تصادفی یک طراح روی متن سفید بهعنوان متن ناپدیدشدهای که خواهد بود قابلمشاهده میشود
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;تنظیم در هویت render-cache، در حافظه و روی دیسک مشارکت میکند، پس یک پیشنمایش معمولی و یک پیشنمایش اثبات هرگز یک bitmap را به اشتراک نمیگذارند. تغییر وضعیت ویژگی نیاز به ابطال دستی هیچچیزی ندارد — یک cache که یکی اشتباه از این دو را برگرداند بدتر از هیچ cacheی نبود
سه دستگاه، یک فراخوانی رندر
THPDFRenderDevice یک کلاس انتزاعی با دو عضوی است که اهمیت دارند: Kind، که هدف را بهعنوان rdkBitmap، rdkDeviceContext یا rdkEnhancedMetafile گزارش میدهد، و Execute، که کتابخانه فراخوانی میکند. سه دستگاه ملموس با HotPDF میآیند، و هر یک خروجیاش را متفاوت مالک میشود
THPDFBitmapRenderDevice یک TBitmap را تا زمانی که TakeBitmap مالکیت را به شما منتقل کند مالک است. THPDFDeviceContextRenderDevice یک HDC موجود بهاضافه عرض و ارتفاع میگیرد و مستقیماً در آن رسم میکند، که همان روشی است روی canvas چاپگر بدون یک رفتوبرگشت bitmap رندر کنید. THPDFMetafileRenderDevice یک TMetafile را تا زمانی که TakeMetafile آن را منتقل کند مالک است، که محتوای برداری را بهعنوان برداری برای مصرفکنندههایی که به آن نیاز دارند نگه میدارد
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;خواندن Kind بهجای آزمایش کلاس runtime عمدی است. کد کاربردی که بر اساس نوع دستگاه dispatch میکند وقتی یک دستگاه پیچانده، تزئین یا جایگزین میشود به کارش ادامه میدهد، و کدی که is THPDFBitmapRenderDevice را آزمایش میکند نمیکند
انتقال مالکیت در عمل چه معنایی دارد
قبل از TakeBitmap یا TakeMetafile، دستگاه شیء را مالک است و در destructor خود آزاد میکند. بعد از فراخوانی، شما آن را مالک هستید و دستگاه دیگر نیست. هر دو الگو قانونیاند: از ویژگی Bitmap یا Metafile وقتی شیء فقط باید از فراخوانی رندر دوام بیاورد استفاده کنید، و وقتی شیء از دستگاه دوام میآورد مالکیت را بگیرید
حالت شکست همان Delphi معمولی است. bitmap را بگیرید، دستگاه را آزاد کنید، فراموش کنید bitmap را آزاد کنید، و یک نشتی دارید که با تعداد صفحه رشد میکند — نامرئی روی یک آزمون پنجصفحهای و واضح روی یک دسته پانصدصفحهای. هر دو شیء را در try/finally خودشان پیچیدید بهجای به اشتراکگذاشتن یک نفر، و سؤال مالکیت خودش را پاسخ میدهد
اثبات overprint و شفافیت در همان صفحه
knockout گروه شفافیت وقتی پیشنمایش overprint روشن است فعال میماند، و هر دو در همان مسیر snapshot رنگ محدود composited میشوند. این مهم است چون فایلهای واقعی آماده چاپ دائماً آن دو را ترکیب میکنند: یک گروه شفافیت که اثر هنری را نگه میدارد روی یک پسزمینه مینشیند که سیاهاش برای overprint تنظیم شده، و شبیهسازی یکی بدون دیگری proofی تولید میکند که به روش جدیدی اشتباه است نه درست
محدودیتها را در دید نگه دارید. پیشنمایش overprint رفتار جوهر فرآیندی را برای رنگهای DeviceCMYK تحت کنترلهای overpass نامبردهشده بالا شبیهسازی میکند. این یک اثبات تعامل جوهر است، نه یک proof قراردادی مدیریتشده با رنگ: یک workflow ICC را جایگزین نمیکند، و به شما نمیگوید یک چاپخانه و کاغذ خاص چه چیزی تولید خواهد کرد. آن را همانطور در نظر بگیرید که یک اپراتور prepress یک پیشنمایش overprint را در یک viewer حرفهای در نظر میگیرد — بهعنوان بررسیای که خطاهایی را میگیرد که هیچکس با نگاه به یک پیشنمایش معمولی نمیگیرد
جا دادن اثبات در یک مرحله preflight
مکان مفید برای این کنار بررسیهایی است که از قبل اجرا میکنید. یک پاس preflight گزارش میدهد متن سیاه برای overprint تنظیم شده؛ یک رندر اثبات به یک اپراتور نشان میدهد آن روی صفحه چه معنایی دارد؛ و هر دو در همان گزارش میروند. برای رنگهای اختصاصی، که اغلب در کار بستهبندی همراه overprint میآیند، مرور رندر رنگ اختصاصی Separation و DeviceN جانب colorant همان صفحه را پوشش میدهد، در حالی که یادداشتهای رندر یک صفحه PDF به bitmap و چاپ یک PDF بارگذاریشده از طریق TPrinter دو هدف دستگاه را در فرم ساده و غیر اثباتی پوشش میدهند
HotPDF صفحات PDF بارگذاریشده را از کد VCL بومی برای Delphi و C++Builder رندر، اثبات و چاپ میکند، بدون هیچ DLL رندر خارجی که در کنار کاربرد deploy شود — صفحه جزء HotPDF لیست ویژگی رندر و یک build آزمایشی دارد