HotPDF ile CMYK Baskı-Üstü Proofing ve İşleme Aygıtları

Bir camgöbeği kutu, sarı bir zemin üzerinde durur ve onu boyayan grafik durumu /op true ile /OPM 1 taşır. Ekranda çakışma düz camgöbeğidir. Baskı levhasında aynı çakışma yeşil çıkar; çünkü RIP sarı levhayı yerinde bırakmış ve camgöbeğini üstüne sermiştir. İki sonuç da dosyaya harfiyen uyar; ekran işlemesi o bayrağin bir görüntüleme aygıtında ne yaptığını hiç sormamıştır, dolayısıyla ekranda verilen bir onay, kâğıda hiç varmayacak bir rengi kapatır

Bir sayfa neden önizlemesinden farklı yazdırılır?

Baskı-üstü, çıktı aygıtına levhalar hakkında verilen bir yönergedir ve bir RGB ekranın levhası yoktur. ISO 32000-1 §8.6.7, bir ExtGState'in OP (kontur) ya da op (dolgu) girdisi true olduğunda ne olacağını tanımlar: geçerli boyanın adlandırmadığı renklendiriciler, sıfıra silinmek yerine levhalarında zaten var olanı korur. Bu şekilde boyanmış bir camgöbeği nesne, sarı levhadan hiçbir şey almaz. RGB'de birleştiren bir görüntüleyicinin sarıyı tutacak bir yeri yoktur; camgöbeğini üstüne boyar ve geçer

İki çıktı da bozuk değildir. Anlaşmazlık iki görüntüleme modeline yapısal olarak gömülüdür ve biri, basılı bir proof'u monitörün yanına tutana kadar görünmez kalmaktadır. Siyah metni yanlışlıkla dışarı itecek şekilde ayarlayan ya da beyaz bir logoyu baskı-üstü bırakıp görünmesini bekleyen bir tasarımcı için bu, işte çok geç bir andır

Proof'u RenderOverprintPreview ile açmak

HotPDF proof'u belge üzerinde tek bir Boolean olarak açar: THotPDF.RenderOverprintPreview, öntanımlı değeri False'tur. Ayarlandığında bitmap işlemesi, her baskı-üstü boyanın altındaki işlem levhalarını izler ve pikseli yazmadan önce §8.6.7 kurallarını uygular; böylece çakışmalar, baskının üreteceği mürekkep bileşimini gösterir. Sıradan görüntüleme için öntanımlıyı kapalı bırakmak doğrudur, çünkü bir ofis PDF'inin okuyucuları onu her zamanki görüntüleyicilerinin gösterdiği gibi görmeyi bekler. Çıktısı bir ön baskı operatörüne giden adımda açın

var
  Pdf: THotPDF;
  Device: THPDFBitmapRenderDevice;
  Proof: TBitmap;
begin
  Pdf := THotPDF.Create(nil);
  try
    Pdf.LoadFromFile('cover-cmyk.pdf');
    Pdf.RenderOverprintPreview := True;    // plakaları proof et, öntanımlı değer False
    Device := THPDFBitmapRenderDevice.Create;
    try
      if Pdf.RenderLoadedPageToDevice(0, 150, Device) then
      begin
        Proof := Device.TakeBitmap;        // sahiplik çağırana geçer
        try
          Image1.Picture.Assign(Proof);
        finally
          Proof.Free;
        end;
      end;
    finally
      Device.Free;
    end;
  finally
    Pdf.Free;
  end;
end;

Levha kuralları, baskı-üstü boyanın renk uzayına bağlıdır ve her biri bir proof'ta farklı bir sürprizi açıkladığı için bilinmeye değerler:

• /OPM 1 altında DeviceCMYK: sıfır olan bir bileşen levhasına dokunmaz, sıfır olmayan bir bileşen onun yerine geçer. Sarı bir zemin üzerinde cyan 100 / yellow 0, sarıyı korur ve yeşile çevirir
• DeviceGray: boya yalnızca siyah levhayı adlandırır; altındaki camgöbeği, macenta ve sarı hayatta kalır. CMY bir zeminin üzerinde baskı-üstü ayarlı beyaz bir DeviceGray logo bu yüzden kaybolur
• Separation ve DeviceN: Cyan, Magenta, Yellow ya da Black adlı bir renklendirici o işlem levhasının doğrudan yerine geçer; /None hiçbir şey boyamaz ve /All her işlem levhasını yazar
• Spot renklendiriciler: öbür her ad spot mürekkep sayılır; tint dönüşümü alternatif bir renk verir ve alttaki işlem levhalarının üzerinden çarpılır, dolayısıyla spot, kapladığı yeri ikame etmek yerine koyulaştırır

Proof, dolgu ve kontur yollarına ve metne uygulanır; kontur işleme modundaki metin dâhil, orada kararı op değil OP kontur bayrağı verir. Görüntüler, satır içi görüntüler ve sh gölgelendirmeleri kendi tam raster renk hatlarından geçmeye devam eder ve sıradan opaklıklarıyla boyar. Pratikte bu, preflight raporlarının en çok işaretlediğini kapsar: baskı-üstü kuralları, kılavuz çizgileri, dizgi ve düz tonlar

Proof açıkken saydamlık canlı kalır. Dışarı itme ayarlı bir saydamlık grubu yine de dışarı iter ve grup, baskı-üstü kurallarıyla aynı geçişte birleştirilir; böylece baskı-üstü siyah bir zemin üzerinde saydam yapıt taşıyan baskıya hazır bir dosya, iki etkiyi birlikte proof'lar. Birini doğru diğerini yanlış yapmak, yalnızca başka biçimde yanlış bir proof üretirdi

Ayar ayrıca önbelleğe alınmış işlemelerin kimliğine katılır. RenderLoadedPageToBitmapCached, girdilerini sayfa, DPI ve RenderOverprintPreview'i de içeren işleme ayarlarından kurulan bir varyantla anahtarlar; disk katmanı aynı varyantı kullanır. Normal ile proof önizlemesi arasında geçiş yapan bir görüntüleyici iki ayrı önbellek girdisi alır ve yalnızca anahtar değiştiği için InvalidateRenderedPageCache çağırması gerekmez

DeviceCMYK dosyalarında /OPM 0 tuzağı

İnsanları hata aramaya gönderen durum işte budur. Bir dosya, DeviceCMYK bir camgöbeği dolgusuna /op true ayarlar ama OPM'yi öntanımlı 0'da bırakır; sonra proof hâlâ camgöbeğinin sarıyı dışarı ittiğini gösterir. Proof doğrudur. Baskı-üstü mod 0 altında §8.6.7, bir DeviceCMYK boyasının dört işlem renklendiricisini de — sıfırlar dâhil — ayarladığını söyler; dolayısıyla sıfır sarı bileşeni, sarı levhasını tam olarak bir dışarı itmenin yapacağı gibi ikame eder. Baskı-üstü mod 0, yalnızca boyanın adlandırmadığı levhaları korur; dört bileşenli bir CMYK renk için bu, spot levhalar demektir ve başka hiçbir şey değildir

Birleşik bir proof'un gösterdiği işlem levhalarında mod 0 ile düz bir dışarı itme aynı pikselleri verir; HotPDF bu yüzden o DeviceCMYK nesnelerini sıradan dışarı itmeler olarak boyar. Bir CMYK nesnesinin diğer işlem mürekkeplerinin üzerine baskı yapması için /op true taşıyan ExtGState'in ayrıca /OPM 1'e ihtiyacı vardır. Bir proof ile tasarımcının niyeti bir DeviceCMYK nesnesinde anlaşmadığında başka her şeyden şüphelenmeden önce o ExtGState'i açın ve OPM girdisine bakın

Ters sürpriz de vardır. /OPM 1 altında CMYK beyazı dört sıfırdır ve baskı-üstü altında dört sıfır, her levhayı olduğu gibi bırakır. Baskı-üstü ayarlı beyaz dizgi levhada kaybolur ve proof onun kaybolduğunu gösterir; ki proof çalıştırmanın bütün nedeni budur

RenderLoadedPageToDevice'un ardındaki üç aygıt

THotPDF.RenderLoadedPageToDevice(PageIndex, DPI, Device), hedefi geçtiğiniz aygıt nesnesinin belirlediği tek bir giriş noktasıdır. nil aygıt için istisna yükseltir, 1'in altındaki bir DPI'yi 150 sayar ve aygıtın Execute metodunun bildirdiğini döndürür. THPDFRenderDevice, iki sanal üyesi olan soyut tabandır: rdkBitmap, rdkDeviceContext ya da rdkEnhancedMetafile döndüren Kind ve Execute(Document, PageIndex, DPI)

Üç gömülü aygıt çıktısına farklı şekillerde sahiptir:

• THPDFBitmapRenderDevice, Bitmap özelliğinde bir TBitmap tutur ve TakeBitmap onu önce size devretmemişse yıkıcısında serbest bırakır
• THPDFDeviceContextRenderDevice.Create(ADC, AWidth, AHeight), hâlihazırda sahip olduğunuz bir HDC'ye çizer ve hiçbir şeye sahip olmaz; kurucu sıfır bir DC ya da pozitif olmayan bir boyutta istisna yükseltir ve arka plan boyanmaz, dolayısıyla bir ekran DC'sinin kendi beyaz dolgusuna ihtiyacı vardır
• THPDFMetafileRenderDevice, TMetafile'ı TakeMetafile devredene dek tutur. Metin ve vektör yollar geliştirilmiş metafile içinde ölçeklenebilir kalır; görüntü XObject'leri rasterleştirilmiş gelir

Sahiplik sıradan Delphi kurallarını izler. Nesnenin yalnızca aygıt kadar yaşaması gerektiğinde Bitmap ya da Metafile özelliğini okuyun; aygıttan uzun yaşaması gerektiğinde Take metodunu çağırın. Bit eşlemi devralın, aygıtı serbest bırakın, bit eşlemi serbest bırakmayı unutun; sızıntı sayfa sayısıyla büyür: beş sayfalık bir örnekte görünmez, beş yüz sayfalık bir toplu işte bariz. Her nesneye kendi try/finally'sini verin, kim neyi serbest bırakır sorusu kendiliğinden yanıtlanır

Uygulama kodunda is THPDFBitmapRenderDevice denetlemek yerine Kind üzerinden dağıtın. Execute ile Kind genel sanal metotlar olduğundan kendi aygıt sınıfınızı yazabilirsiniz ve türü denetleyen kod, sizinkilerden biri gömülü bir aygıtın yerine geçtiğinde çalışmaya devam eder

Bir yazıcı işlemesi neden bir köşeye düşer?

Aygıt bağlamı yolu sayfayı, geçtiğiniz genişlik ve yükseklikten değil DPI argümanından boyutlandırır. İşleyici PDF birimlerini DPI / 72 ile ölçekler ve yüksekliği yalnızca sayfa orijinini yüzeyin dibine demirlemek için kullanır. 300'ü koda gömüp işi 600 dpi'lik bir yazıcıya gönderin; sayfa yarı boyutta çıkar ve levhanın sol alt köşesine itilir. Yazıcı çözünürlüğü sürücünün özelliğidir; onu sürücüye sorun:

procedure PrintPage(Pdf: THotPDF; PageIndex: Integer);
var
  Device: THPDFDeviceContextRenderDevice;
  PrinterDPI, W, H, Tmp: Integer;
  L, B, R, T: Single;
begin
  if not Pdf.GetLoadedPageVisibleBox(PageIndex, L, B, R, T) then
    Exit;
  Printer.BeginDoc;
  try
    // sürücüye sorun; 300, 600 ve 1200 dpi hep yaygındır
    PrinterDPI := GetDeviceCaps(Printer.Handle, LOGPIXELSX);
    W := Round((R - L) * PrinterDPI / 72);
    H := Round((T - B) * PrinterDPI / 72);
    if (Pdf.GetLoadedPageRotation(PageIndex) mod 180) = 90 then
    begin
      Tmp := W; W := H; H := Tmp;            // 90 / 270 sayfalar için yer değiştir
    end;
    Device := THPDFDeviceContextRenderDevice.Create(
      Printer.Canvas.Handle, W, H);
    try
      Pdf.RenderLoadedPageToDevice(PageIndex, PrinterDPI, Device);
    finally
      Device.Free;
    end;
  finally
    Printer.EndDoc;
  end;
end;

Genişlik ve yükseklik, sayfanın görünür kutusundan — MediaBox'a kırpılmış CropBox'tan — yazıcının kendi çözünürlüğünde gelir ve çağıran, aygıtı oluşturmadan önce döndürülmüş sayfalar için onları yer değiştirir. İşleyicinin orijini demirlerken beklediği budur

Baskı-üstü proofing bu yoldan gitmez. Aygıt bağlamı ve metafile aygıtları GDI çağrılarını doğrudan hedefe yayar ve levha kuralları, her boyanın altında hâlihazırda duran pikselleri ister; onlara yalnızca bitmap işlemesi sahiptir. Kâğıt bir proof için proof bitmap'ini işleyin ve yazıcı tuvaline gerdirin. Küçük bir özel aygıt, bunu aynı giriş noktasının arkasında tutar:

type
  // kendi aygıtınız: önce proof bitmap, sonra yazıcıya gerdirilir
  TPrinterProofDevice = class(THPDFRenderDevice)
  public
    function Kind: THPDFRenderDeviceKind; override;
    function Execute(Document: THotPDF; PageIndex, DPI: Integer): boolean;
      override;
  end;

function TPrinterProofDevice.Kind: THPDFRenderDeviceKind;
begin
  Result := rdkDeviceContext;
end;

function TPrinterProofDevice.Execute(Document: THotPDF;
  PageIndex, DPI: Integer): boolean;
var
  Proof: TBitmap;
  OldProof: Boolean;
begin
  OldProof := Document.RenderOverprintPreview;
  Document.RenderOverprintPreview := True;
  try
    Proof := Document.RenderLoadedPageToBitmap(PageIndex, DPI);
  finally
    Document.RenderOverprintPreview := OldProof;  // çağıranın ayarını olduğu gibi bırak
  end;
  Result := Proof <> nil;
  if Result then
  try
    Printer.Canvas.StretchDraw(
      Rect(0, 0, Printer.PageWidth, Printer.PageHeight), Proof);
  finally
    Proof.Free;
  end;
end;

Onu, bit eşleme levhaya yetecek kadar piksel veren bir DPI ile — harf boyutunda bir proof için kabaca 200 ile 300 — Printer.BeginDoc ile Printer.EndDoc arasında çağırın. Yukarıdaki gerdirme dikdörtgeni yazdırılabilir alanı doldurur; sayfa ile kâğıdın biçimi farklıysa sayfanın en-boy oranını içinde koruyun

Proofing preflight'ın yanında nereye oturur

Proof tek bir soruyu yanıtlar: nesneler çakıştığında hangi mürekkepler hayatta kalır. Öbür işlemealarla aynı 24 bitlik RGB bitmap üzerinde birleştirilir; renkleri mürekkep bileşimini gösterir, ölçülmüş bir levha rengini değil. Baskı koşulları bir renk yönetimi sorusudur ve belge onları ConfigureRenderICCWorkflow ile ele alır — bir proof profili, bir çıktı profili ve bir siyah nokta dengeleme bayrağı alır — ve bırakmak için ClearRenderICCWorkflow

Proof işleme için en verimli yer, hâlihazırda çalıştırdığınız denetimlerin yanıdır. Bir preflight geçişi siyah metnin baskı-üstü ayarlı olduğunu raporlar; proof işlemesi operatöre bunun sayfada ne yaptığını gösterir; ikisi de aynı rapora düşer. Ambalaj işi baskı-üstünü sıkça spot mürekkeplerle karıştırır ve Separation ve DeviceN spot renk işleme yazısı aynı sayfanın renklendirici tarafını — RenderLoadedPageSeparationPlate ile tek levhalık görünümler dâhil — kapsar. bir PDF sayfasını bit eşleme işleme ile yüklenen bir PDF'i TPrinter üzerinden yazdırma yazıları, iki aygıt hedefini düz biçimleriyle ele alır

Bunların hepsi, yürütülebilir dosyanın yanına dağıtılacak bir işleme DLL'i olmaksızın yerel Delphi ve C++Builder kodunda çalışır. HotPDF Delphi bileşeni sayfası, işleme ve ön baskı özelliklerini listeler ve bu örnekleri kendi baskı dosyalarınızda çalıştırmanız için bir deneme derlemesi taşır