出力の手引きWeb
2011年04月19日 ｜ Adobe PDF Print Engineでのオーバープリント(6) - 番外編：DeviceGray
前の記事
「Adobe PDF Print Engineでのオーバープリント(5) - 理論通りにならない事例」
の補足です。
この記事は全て従来処理系の内部の処理について言及していますが、出力結果は最新処理系と同じになります。
以下の事例2)について、さらに理解を深めるために2つの事例を紹介します。
前の記事の2)を引用します。
 2) 従来処理系なのにDeviceGrayのオーバープリントがヌキにTrueflowの従来処理系では、透明をそのまま演算できないので、入力処理の内部で透明の分割統合処理が行われます。この透明の分割統合処理を行う部分は（Trueflowのオーバープリントモードの設定に関わらず）PDFの規格に基づいてオーバープリントを再解釈します。 ここで、DeviceGrayのオーバープリントオブジェクトは、（PDFの規格に準じるとノセなくていいので）オーバープリントがOffのDeviceCMYK部品に変換され、結果ヌキになります。 |
2-1) DeviceGrayのオーバープリントがノセにならないといけないケース（Trueflowの従来処理系）上記では（PDFの規格に準じるとノセなくていいので）と説明しましたが、PDFの規格に準じるとDeviceGrayのオーバープリントがノセにならないといけないケースでは、どの様になるのでしょうか？
今までの全ての事例は下部のオブジェクトもプロセスカラーであることが条件です。もし、この例でも下部が特色でDeviceNやSeparationの場合、最新・従来に関わらずノセになる必要があります。
実際の出力結果も、右図の用に確かに元々DeviceGrayだった部分が（透明と同居しているにも関わらず）期待通りノセになります。
これはRIP内部の処理において、オーバープリントに対して、あたかも透明のような分割統合処理が行われています。基本的にDeviceGrayは（PDFの規格に準じるとノセなくていいので）オーバープリントがOffのDeviceCMYKに変換しますが、下部が特色の部分だけはノセる必要があるので、その部分を分割しDeviceCMYKのオーバープリントがOnに変換します。この単純な例では、DeviceGrayを分割せずにDeviceCMYKのノセに設定すれば良さそうですが、他のオブジェクトが絡んでくる事を考えると分割されるのが正解です
2-2) DeviceGrayの墨ベタで自動オーバープリントが効かないケース（Trueflowの従来処理系）
右図は、分かりやすくするために墨ベタを少し薄くしています
前の記事の最後に「DeviceGrayの墨ベタにも自動オーバープリントは効く」と書きました。確かに2)の例（下部が単純なDeviceCMYKの図形）で、もしDeviceGrayが墨ベタの場合は、分割は行われず、単にオーバープリントがOffに変換されるだけなので、その後の自動オーバープリントは効きます。
しかし、自動墨ノセは万全ではありません。
DeviceGrayで記述された墨ベタが、透明と同じページにあった場合、入力処理の分割統合処理において、DeviceCMYKの部品に対しては（PDFの規格に準じるとノセなくていいので）オーバープリントがOffのDeviceCMYK部品に変換されるまでは、上記2)と同じです。
しかし、下部のオブジェクトがグラデーションや画像の場合、分割統合の影響で重なっている部分が画像化されてしまいます。
この分割統合処理で生成された画像は、ノセなくていい前提で分割統合されているので、せっかく分割されたのに、グラデーションとは合成されておらず、単なる墨ベタの画像（トホホ…）になっています。
こうなってしまうと、テキストでも図形でも無いので、自動オーバープリントは効きません。
その上、下部のオブジェクトも欠けているのでどうしようもありません。
＜まとめ＞
・全ての例は、同じページ上に分割されていない透明オブジェクトがある場合に限ります。（つまりPDFのみ）
・Adobe CS3以降など推奨アプリケーションを使えば、この様なことを考える必要はありません。
