Пробний друкарський контроль CMYK-нашарування та пристрої рендерингу в HotPDF

HotPDF рендерить завантажену сторінку PDF через одну точку входу, RenderLoadedPageToDevice, і пристрій, який ви йому передаєте, визначає, чи результатом буде bitmap, малюнок на зовнішньому контексті пристрою (наприклад, полотні принтера), чи векторний розширений метафайл. Установіть RenderOverprintPreview у True, і той самий виклик симулює нашарування триадних фарб CMYK, тож оператор бачить на екрані взаємодію фарб, яка інакше з'явилася б лише на друкарському відбитку

Ці дві можливості розв'язують різні проблеми, що трапилося зустрітися в одному шляху коду. Абстракція пристрою прибирає гілку, де попередній перегляд, друк та експорт мали кожен власний виклик рендерингу з власним відхиленням. Пробне нашарування прибирає клас виробничих помилок, де документ виглядає правильним у кожному переглядачі й сходить із друкарського станка неправильним

Чому сторінка друкується інакше, ніж відображається в перегляді?

Тому що ourprint — це інструкція для пристрою відображення, а не операція малювання. Коли сторінка встановлює /OP або /op у true у графічному стані, вона наказує RIP не вибивати фарби під низом — ціанізований об'єкт, намальований поверх жовтого, залишає жовтий на місці, і відбиток показує зелений. Переглядач, що ігнорує ourprint, вибиває зазвичай і показує циан. Жоден не помиляється за власними мірками, і саме в цьому проблема: екран і друкарський стан не згодні, і ніхто не дізнається, поки не повернуться пробы

RenderOverprintPreview змушує HotPDF взяти інструкцію серйозно для фарб DeviceCMYK, керованих /OP, /op та /OPM 1. Результат — пробний попередній перегляд, а не перегляд переглядача: чорний, що нашаровується на відтінок, залишається багатим накладенням замість того, щоб вибивати дірку, а випадкове ourprint на білому тексті стає помітним як зникаючий текст, яким він і буде

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;

Це налаштування бере участь в ідентичності кешу рендерингу, у пам'яті та на диску, тож звичайний перегляд і пробний перегляд ніколи не поділяють bitmap. Перемикання властивості не вимагає від вас інвалідувати щось вручну — кеш, що повернув би не той із двох, був би гірший за відсутність кешу взагалі

Три пристрої, один виклик рендерингу

THPDFRenderDevice — це абстрактний клас із двома важливими членами: Kind, що повідомляє ціль як rdkBitmap, rdkDeviceContext або rdkEnhancedMetafile, та Execute, що викликає бібліотека. Три конкретні пристрої постачаються з HotPDF, і кожен володіє своїм виводом по-різному

THPDFBitmapRenderDevice володіє TBitmap, поки TakeBitmap не передасть власність вам. THPDFDeviceContextRenderDevice приймає наявний HDC плюс ширину та висоту й малює прямо в нього, що й дозволяє рендерити на полотно принтера без обхідного шляху через 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, а не перевірка класу під час виконання, навмисне. Код застосунку, що розгалужується за типом пристрою, продовжує працювати, коли пристрій огортається, декорується або замінюється, а код, що перевіряє is THPDFBitmapRenderDevice, — ні

Що передача власності означає на практиці

До TakeBitmap або TakeMetafile пристрій володіє об'єктом і звільняє його у своєму деструкторі. Після виклику ним володієте ви, а пристрій вже ні. Обидва шаблони правомочні: використовуйте властивість Bitmap або Metafile, коли об'єкт має пережити лише виклик рендерингу, і заберіть власність, коли об'єкт переживає пристрій

Режим відмови — звичайний для Delphi. Візьміть bitmap, звільніть пристрій, забудьте звільнити bitmap — і ви маєте виток, що зростає зі кількістю сторінок: непомітний на п'ятисторінковому тесті й очевидний на партії в п'ятсот сторінок. Огортайте обидва об'єкти у власні try/finally, а не в один спільний, і питання власності розв'язується само

Пробне нашарування та прозорість на одній сторінці

Вибивання групи прозорості лишається активним, коли увімкнено попередній перегляд нашарування, і обидва компонуються в тому самому обмеженому шляху знімка малювання. Це важливо, бо справжні придатні до друку файли постійно змішують обидва: група прозорості з графікою сидить на фоні, чорний якого встановлено на нашарування, а симуляція одного без іншого дає пробу, що хибна по-новому, а не правильну

Межі також варто тримати в полі зору. Попередній перегляд нашарування симулює поведінку триадних фарб для DeviceCMYK під контролем ourprint, названим вище. Це проба взаємодії фарб, а не керований кольором контрактний proof: вона не замінює робочого процесу ICC і не повідомляє, що дасть конкретний друкарський стан і конкретний папір. Ставтеся до неї так, як оператор допечатної підготовки ставиться до попереднього перегляду ourprint у професійному переглядачі — як до перевірки, що ловить помилки, яких ніхто не ловить, дивлячись на звичайний попередній перегляд

Вписування проби в крок префлайта

Корисне місце для цього — поруч із перевірками, які ви вже запускаєте. Прохід префлайта повідомляє, що чорний текст установлено на нашарування; пробний рендер показує операторові, що це означає на сторінці; і обидва потрапляють у той самий звіт. Щодо плашкових кольорів, що часто супроводжують нашарування в пакувальній роботі, нарис рендерингу плашкових кольорів Separation та DeviceN описує бік барвників тієї самої сторінки, тоді як нотатки рендерингу сторінки PDF у bitmap та друку завантаженого PDF через TPrinter описують дві цілі пристрою у їхньому звичайному, непробному вигляді

HotPDF рендерить, пробує та друкує завантажені сторінки PDF з рідного VCL-коду для Delphi та C++Builder, без зовнішньої DLL рендерингу, яку треба розгортати поруч із застосунком — сторінка компонента HotPDF містить список можливостей рендерингу та пробну збірку