การพิสูจน์ CMYK Overprint และอุปกรณ์เรนเดอร์ใน HotPDF

HotPDF เรนเดอร์หน้า PDF ที่โหลดผ่านจุดเข้าเดียวคือ RenderLoadedPageToDevice และอุปกรณ์ที่คุณส่งให้มันตัดสินว่าผลลัพธ์จะเป็นบิตแมป การวาดบน device context ภายนอกเช่นแคนวัสเครื่องพิมพ์ หรือ enhanced metafile แบบเวกเตอร์ ตั้ง RenderOverprintPreview เป็น True และคำสั่งเดียวกันจะจำลอง CMYK process-ink overprint ทำให้ผู้ปฏิบัติงานเห็นบนหน้าจอถึงปฏิกิริยาของหมึกที่มิฉะนั้นจะปรากฏเฉพาะบนแผ่นพิมพ์

สองคุณสมบัตินี้แก้ปัญหาที่ต่างกันแต่บังเอิญมาพบกันในเส้นทางโค้ดเดียวกัน นามธรรมอุปกรณ์เอาส่วนที่แยกกันออกไป เมื่อก่อนพรีวิว พิมพ์ และส่งออกแต่ละอย่างมีคำสั่งเรนเดอร์เป็นของตัวเองพร้อมความคลาดเคลื่อนของตัวเอง การพิสูจน์ overprint เอาประเภทของข้อผิดพลาดการผลิตออกไป ที่เอกสารดูถูกต้องในทุกตัวอ่านแต่ออกจากแท่นพิมพ์ผิด

ทำไมหน้าพิมพ์จึงออกมาต่างจากพรีวิว

เพราะ overprint เป็นคำสั่งไปยังอุปกรณ์ถ่ายภาพ ไม่ใช่การดำเนินการวาด เมื่อหน้าหนึ่งตั้ง /OP หรือ /op เป็น true ใน graphics state มันกำลังสั่ง RIP ไม่ให้เอาหมึกด้านล่างออก — วัตถุสีฟ้าที่วาดทับเหลืองจะปล่อยเหลืองไว้ และแผ่นพิมพ์แสดงสีเขียว ตัวอ่านที่ไม่สนใจ overprint จะเอาออกตามปกติและแสดงสีฟ้า ไม่มีอันไหนผิดในเงื่อนไขของตัวมันเอง และนั่นคือปัญหาพอดี หน้าจอกับแท่นพิมพ์ไม่ลงรอยกัน และไม่มีใครพบมันจนกว่าพรูฟจะกลับมา

RenderOverprintPreview ทำให้ HotPDF จริงจังกับคำสั่งนั้นสำหรับสี DeviceCMYK ที่ควบคุมโดย /OP, /op และ /OPM 1 ผลคือพรีวิวพิสูจน์แทนพรีวิวตัวอ่าน สีดำที่ overprint ทับสีจางยังคงเป็นการทับที่สมบูรณ์แทนที่จะเจาะรู และ 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 identity ทั้งในหน่วยความจำและดิสก์ ดังนั้นพรีวิวปกติและพรีวิวพิสูจน์จึงไม่เคยแชร์บิตแมปเดียวกัน การสลับคุณสมบัตินี้ไม่ต้องให้คุณเพิกถอนอะไรด้วยมือ — แคชที่คืนสิ่งที่ผิดระหว่างสองอย่างนี้จะแย่ไปกว่าไม่มีแคชเลย

สามอุปกรณ์ หนึ่งคำสั่งเรนเดอร์

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 แทนที่จะทดสอบรันไทม์คลาสเป็นเรื่องตั้งใจ โค้ดแอปพลิเคชันที่กระจายตามชนิดอุปกรณ์จะยังทำงานเมื่ออุปกรณ์ถูกหุ้ม ตกแต่ง หรือแทนที่ แต่โค้ดที่ทดสอบ is THPDFBitmapRenderDevice ไม่เช่นนั้น

การโอนความเป็นเจ้าของหมายถึงอะไรในทางปฏิบัติ

ก่อน TakeBitmap หรือ TakeMetafile อุปกรณ์เป็นเจ้าของออบเจกต์และคืนอิสระใน destructor หลังคำสั่ง คุณเป็นเจ้าของและอุปกรณ์ไม่เป็นอีกต่อไป ทั้งสองรูปแบบสุจริต ใช้คุณสมบัติ Bitmap หรือ Metafile เมื่อออบเจกต์ต้องอยู่รอดเพียงให้พ้นคำสั่งเรนเดอร์ และรับความเป็นเจ้าของเมื่อออบเจกต์ต้องอยู่รอดพ้นอุปกรณ์

รูปแบบความล้มเหลวคือแบบ Delphi ปกติ รับบิตแมป คืนอิสระอุปกรณ์ ลืมคืนอิสระบิตแมป แล้วคุณมีรั่วที่โตตามจำนวนหน้า — มองไม่เห็นบนการทดสอบห้าหน้าและชัดเจนบนชุดห้าร้อยหน้า หุ้มทั้งสองออบเจกต์ใน try/finally ของตัวเองแทนที่จะแชร์อันเดียว แล้วคำถามความเป็นเจ้าของจะตอบเอง

การพิสูจน์ overprint กับความโปร่งใสในหน้าเดียวกัน

transparency-group knockout ยังคงทำงานเมื่อเปิดพรีวิว overprint และทั้งสองถูกคอมโพสิตในเส้นทาง bounded paint snapshot เดียวกัน นี่สำคัญเพราะไฟล์ที่พร้อมพิมพ์จริงผสมสองสิ่งนี้ตลอด กลุ่มความโปร่งใสที่พกงานศิลปะนั่งอยู่บนพื้นหลังที่สีดำตั้งให้ overprint และการจำลองอันหนึ่งโดยไม่มีอีกอันจะผลิตพรูฟที่ผิดในทางใหม่แทนที่จะถูก

จงมองขีดจำกัดไว้ พรีวิว overprint จำลองพฤติกรรมหมึกกระบวนการสำหรับสี DeviceCMYK ภายใต้การควบคุม overprint ที่กล่าวนามข้างต้น มันเป็นพรูฟของปฏิกิริยาหมึก ไม่ใช่พรูฟคอนแทรกต์ที่จัดการสี มันไม่แทนที่เวิร์กโฟลว์ ICC และไม่บอกคุณว่าแท่นพิมพ์และกระดาษเฉพาะจะให้ผลอะไร ปฏิบัติต่อมันเหมือนที่ผู้ปฏิบัติงานพรีเพรสปฏิบัติต่อพรีวิว overprint ในตัวอ่านระดับมืออาชีพ — เป็นการตรวจที่จับข้อผิดพลาดที่ไม่มีใครจับได้จากการมองพรีวิวปกติ

การสอดสนิทของการพิสูจน์เข้ากับขั้นตอน preflight

ที่ที่เป็นประโยชน์คือข้างการตรวจสอบที่คุณรันอยู่แล้ว การผ่าน preflight รายงานว่าข้อความสีดำตั้งให้ overprint การเรนเดอร์พรูฟแสดงให้ผู้ปฏิบัติงานเห็นว่านั่นหมายถึงอะไรบนหน้า และทั้งสองเข้าไปในรายงานเดียวกัน สำหรับสีพิเศษ ซึ่งมักมาพร้อม overprint ในงานบรรจุภัณฑ์ คู่มือ การเรนเดอร์สีพิเศษ Separation และ DeviceN ครอบคลุมด้าน colorant ของหน้าเดียวกัน ขณะที่บันทึกของ การเรนเดอร์หน้า PDF ไปบิตแมป และของ การพิมพ์ PDF ที่โหลดผ่าน TPrinter ครอบคลุมเป้าหมายอุปกรณ์ทั้งสองในรูปแบบธรรมดาที่ไม่ใช่พรูฟ

HotPDF เรนเดอร์ พิสูจน์ และพิมพ์หน้า PDF ที่โหลดจากโค้ด VCL พื้นเมืองสำหรับ Delphi และ C++Builder โดยไม่มี DLL เรนเดอร์ภายนอกที่ต้องจัดส่งข้างแอปพลิเคชัน — หน้าคอมโพเนนต์ HotPDF มีรายการคุณสมบัติการเรนเดอร์และรุ่นทดลอง