הוכחת Overprint ב-CMYK והתקני רינדור ב-HotPDF

HotPDF מרנדרת עמוד PDF טעון דרך נקודת כניסה אחת, RenderLoadedPageToDevice, וההתקן שאתה מוסר לה מכריע אם התוצאה היא מפת סיביות, ציור על הקשר התקן חיצוני כגון קנבס מדפסת, או metafile וקטורי משופר. הגדר את RenderOverprintPreview ל-True ואותה קריאה מדמה overprint של דיו process ב-CMYK, כך שמפעיל רואה על המסך את אינטראקציית הדיו שאחרת תופיע רק על גיליון הדפוס

שתי תכונות אלה פותרות בעיות שונות שקורות להיפגש באותו נתיב קוד. אבסטרקציית ההתקן מסירה את הענף שבו תצוגה מקדימה, הדפסה וייצוא היו לכל אחת קריאת רינדור משלה עם סטייה משלה. הוכחת overprint מסירה את מחלקת שגיאות הייצור שבה מסמך נראה נכון בכל קורא ויוצא מבית הדפוס שגוי

למה עמוד מודפס שונה מאיך שהוא מוצג בתצוגה מקדימה?

מפני ש-overprint הוא הוראה להתקן ההדמיה, לא פעולת צביעה. כשעמוד מגדיר /OP או /op כ-true במצב הגרפיקה, הוא אומר ל-RIP לא להדוף את הדיו שמתחת — אובייקט ציאן שמצויר מעל צהוב משאיר את הצהוב במקומו, והגיליון מראה ירוק. קורא שמתעלם מ-overprint דוחה כרגיל ומראה ציאן. אף אחד מהם אינו שגוי בתנאים שלו, וזה בדיוק הבעיה: המסך ובית הדפוס חלוקים, ואף אחד לא מגלה עד שהוכחות חוזרות

RenderOverprintPreview גורם ל-HotPDF לקחת את ההוראה ברצינות עבור צבעי DeviceCMYK הנשלטים על ידי /OP, /op ו-/OPM 1. התוצאה היא תצוגת הוכחה במקום תצוגה רגילה: שחור שמדפיס מעל גוון נשאר כשכבה עשירה במקום לנקב חור, ו-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;

ההגדרה משתתפת בזהות מטמון הרינדור, בזיכרון ועל דיסק, כך שתצוגה רגילה ותצוגת הוכחה לעולם אינן חולקות מפת סיביות. החלפת המאפיין אינה דורשת ממך לבטל תוקף של דבר ביד — מטמון שהיה מחזיר את האחת משתי אלה היה גרוע משום מטמון כלל

שלושה התקנים, קריאת רינדור אחת

THPDFRenderDevice היא מחלקה מופשטת עם שני חברים שחשובים: Kind, שמדווח על היעד כ-rdkBitmap, rdkDeviceContext או rdkEnhancedMetafile, ו-Execute, שהספרייה קוראת לו. שלושה התקנים קונקרטיים מגיעים עם HotPDF, וכל אחד מחזיק בפלט שלו אחרת

THPDFBitmapRenderDevice מחזיק ב-TBitmap עד ש-TakeBitmap מעביר בעלות אליך. THPDFDeviceContextRenderDevice לוקח HDC קיים בתוספת רוחב וגובה ומצייר ישירות אליו, שזה איך אתה מרנדר על קנבס מדפסת בלי מעבר מפת-סיביות. 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 במקום בדיקת מחלקת זמן-הריצה היא מכוונת. קוד יישום שמבצע dispatch על סוג ההתקן ממשיך לעבוד כשהתקן נעטף, מקושט או מוחלף, וקוד שבודק is THPDFBitmapRenderDevice לא

מה מעבירת בעלות אומרת בפועל

לפני TakeBitmap או TakeMetafile, ההתקן מחזיק באובייקט ומשחרר אותו ב-destructor שלו. אחרי הקריאה, אתה מחזיק בו וההתקן כבר לא. שני הדפוסים לגיטימיים: השתמש במאפיין Bitmap או Metafile כשהאובייקט רק צריך לשרוד את קריאת הרינדור, וקח בעלות כשהאובייקט שורד את ההתקן

אופן הכישלון הוא זה הרגיל של דלפי. קח את מפת הסיביות, שחרר את ההתקן, שכח לשחרר את מפת הסיביות, ויש לך דליפה שגדלה עם מספר העמודים — בלתי-נראית על ניסוי של חמישה עמודים וברורה על אצווה של חמש-מאות. עטוף את שני האובייקטים ב-try/finally משלהם במקום לחלוק אחד, ושאלת הבעלות עונה על עצמה

הוכחת overprint ושקיפות באותו עמוד

knockout של קבוצת שקיפות נשאר פעיל כשתצוגת overprint דלוקה, ושניהם מרוכבים באותו נתיב צבע מקובץ בגבול. זה חשוב מפני שקבצים אמיתיים מוכני-דפוס מערבבים את השניים כל הזמן: קבוצת שקיפות שמחזיקה אמנות יושבת על רקע שהשחור שלו מוגדר ל-overprint, ודמוי אחד בלי השני מייצר הוכחה שגויה בדרך חדשה במקום נכונה

יש להחזיק את המגבלות בתודעה. תצוגת overprint מדמה התנהגות דיו-process עבור צבעי DeviceCMYK תחת בקרות ה-overprint שנקראו לעיל. זוהי הוכחה של אינטראקציית דיו, לא הוכחת חוזה מנוהלת-צבע: היא אינה מחליפה זרימת עבודה ICC, ואינה אומרת לך מה בית דפוס ונייר מסוימים יניבו. התייחס אליה כפי שמפעיל קדם-דפוס מתייחס לתצוגת overprint בקורא מקצועי — כבדיקה שתופסת את השגיאות שאף אחד לא תופס על ידי הסתכלות בתצוגה רגילה

שילוב הוכחה בשלב preflight

המקום השימושי לזה הוא לצד הבדיקות שאתה כבר מריץ. מעבר preflight מדווח שטקסט שחור מוגדר ל-overprint; רינדור הוכחה מראה למפעיל מה זה אומר על העמוד; ושניהם נכנסים לאותו דוח. עבור צבעי spot, שלעיתים קרובות מלווים overprint בעבודת אריזות, הסקירה של רינדור צבעי spot של Separation ו-DeviceN מכסה את צד ה-colorant של אותו עמוד, בעוד ההערות על רינדור עמוד PDF למפת סיביות ועל הדפסת PDF טעון דרך TPrinter מכסות את שני יעדי ההתקן בצורתם הרגילה, הלא-הוכחתית

HotPDF מרנדרת, מוכיחה ומדפיסה עמודי PDF טעונים מקוד VCL מקורי לדלפי ו-C++Builder, ללא DLL רינדור חיצוני לפרוס לצד היישום — דף רכיב ה-HotPDF מכיל את רשימת תכונות הרינדור ובניית ניסיון