Proofing overprintu CMYK i urządzenia renderujące w HotPDF

HotPDF renderuje wczytaną stronę PDF przez jeden punkt wejścia, RenderLoadedPageToDevice, a urządzenie, jakie mu przekażesz, decyduje, czy wynikiem jest bitmapa, rysunek na zewnętrznym kontekście urządzenia takim jak płótno drukarki, czy wektorowy rozszerzony metaplik. Ustaw RenderOverprintPreview na True, a to samo wywołanie symuluje overprint farb procesowych CMYK, więc operator widzi na ekranie interakcję farb, która inaczej pojawiłaby się dopiero na arkuszu maszyny

Te dwie funkcje rozwiązują różne problemy, które akurat spotykają się w tej samej ścieżce kodu. Abstrakcja urządzenia usuwa gałąź, w której podgląd, druk i eksport miały każde własne wywołanie renderowania z własnym dryfem. Proofing overprintu usuwa klasę błędu produkcyjnego, w której dokument wygląda poprawnie w każdym viewerze, a z maszyny schodzi źle

Dlaczego strona drukuje się inaczej, niż podgląda?

Ponieważ overprint to instrukcja dla urządzenia obrazującego, a nie operacja malowania. Gdy strona ustawia /OP lub /op na true w stanie grafiki, mówi RIP-owi, żeby nie wybijał farb spodem — cyjanowy obiekt narysowany nad żółtym zostawia żółty na miejscu, a arkusz pokazuje zielony. Viewer, który ignoruje overprint, wybija normalnie i pokazuje cyjan. Żaden z nich sam w sobie nie jest błędny i właśnie w tym problem: ekran i maszyna się nie zgadzają, a nikt nie dowiaduje się, dopóki nie wrócą proofy

RenderOverprintPreview sprawia, że HotPDF bierze instrukcję poważnie dla malowań DeviceCMYK rządzonych przez /OP, /op i /OPM 1. Wynikiem jest podgląd proofowy zamiast podglądu viewera: czarna overprintująca na tinie zostaje bogatą nakładką zamiast wybijać dziurę, a przypadkowy overprint projektanta na białym tekście staje się widoczny jako znikający tekst, jakim będzie

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;

Ustawienie uczestniczy w tożsamości pamięci podręcznej renderowania, w pamięci i na dysku, więc zwykły podgląd i podgląd proofowy nigdy nie współdzielą bitmapy. Przełączenie właściwości nie wymaga ręcznego unieważniania niczego — pamięć podręczna, która zwróciłaby niewłaściwą z tych dwóch, byłaby gorsza niż brak pamięci podręcznej w ogóle

Trzy urządzenia, jedno wywołanie renderowania

THPDFRenderDevice to klasa abstrakcyjna z dwoma elementami, na których zależy: Kind, który raportuje cel jako rdkBitmap, rdkDeviceContext lub rdkEnhancedMetafile, oraz Execute, który wywołuje biblioteka. Trzy konkretne urządzenia są dostarczane z HotPDF i każde inaczej posiada swój wynik

THPDFBitmapRenderDevice posiada TBitmap, dopóki TakeBitmap nie przeniesie własności do Ciebie. THPDFDeviceContextRenderDevice przyjmuje istniejący HDC plus szerokość i wysokość i rysuje prosto w niego, co jest sposobem na renderowanie na płótno drukarki bez pośrednictwa bitmapy. THPDFMetafileRenderDevice posiada TMetafile, dopóki TakeMetafile go nie przeniesie, co zachowuje treść wektorową jako wektory dla konsumentów, którzy tego potrzebują

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;

Czytanie Kind zamiast testowania klasy runtime jest celowe. Kod aplikacji, który dysponuje po rodzaju urządzenia, działa dalej, gdy urządzenie jest opakowane, dekorowane lub zastąpione, a kod, który testuje is THPDFBitmapRenderDevice — nie

Co transfer własności oznacza w praktyce

Przed TakeBitmap lub TakeMetafile urządzenie posiada obiekt i zwalnia go w swoim destruktorze. Po wywołaniu Ty go posiadasz, a urządzenie już nie. Oba wzorce są legitimne: używaj właściwości Bitmap lub Metafile, gdy obiekt musi przeżyć tylko wywołanie renderowania, a bierz własność, gdy obiekt przeżywa urządzenie

Tryb porażki to zwyczajny tryb Delphi. Weź bitmapę, zwolnij urządzenie, zapomnij zwolnić bitmapę i masz przeciek, który rośnie z liczbą stron — niewidoczny na teście pięciostronicowym i oczywisty na partii pięćsetstronicowej. Opraw oba obiekty we własne try/finally zamiast współdzielić jedno, a kwestia własności odpowiada sama na siebie

Proofing overprintu i przezroczystość na tej samej stronie

Wybijanie grupy przezroczystości pozostaje aktywne, gdy podgląd overprintu jest włączony, i oba są komponowane w tej samej ograniczonej ścieżce migawki malowania. To ma znaczenie, bo realne pliki gotowe do druku stale mieszają jedno z drugim: grupa przezroczystości niosąca grafikę siedzi na tle, którego czarny jest ustawiony na overprint, a symulowanie jednego bez drugiego produkuje proof, który jest błędny w nowy sposób zamiast poprawny

Utrzymuj jednak w polu widzenia ograniczenia. Podgląd overprintu symuluje zachowanie farb procesowych dla malowań DeviceCMYK pod kontrolami overprintu wymienionymi wyżej. To proof interakcji farb, a nie kolor-zarządzany proof kontraktowy: nie zastępuje przepływu ICC ani nie mówi, co wyda konkretna maszyna i konkretny papier. Traktuj to tak, jak operator prepress traktuje podgląd overprintu w profesjonalnym viewerze — jako sprawdzenie, które łapie błędy nieuchwycone przez patrzenie na zwykły podgląd

Wpisanie proofingu w krok preflighitu

Użyteczne miejsce na to jest obok sprawdzeń, które już uruchamiasz. Przebieg preflighitu raportuje, że czarny tekst jest ustawiony na overprint; render proofowy pokazuje operatorowi, co to oznacza na stronie; a oba trafiają do tego samego raportu. Dla kolorów spotowych, które często towarzyszą overprintowi w pracy opakowaniowej, przewodnik po renderowaniu kolorów spotowych Separation i DeviceN obejmuje stronę kolorantów tej samej strony, podczas gdy notatki o renderowaniu strony PDF do bitmapy i o drukowaniu wczytanego PDF przez TPrinter obejmują dwa cele urządzeń w ich zwykłej, nieproofowej formie

HotPDF renderuje, proofuje i drukuje wczytane strony PDF z natywnego kodu VCL dla Delphi i C++Builder, bez zewnętrznej DLL renderującej do dostarczenia obok aplikacji — strona komponentu HotPDF ma listę funkcji renderowania i wersję próbną