出力の手引きWeb[2011年]
2011年04月15日 ｜ Adobe PDF Print Engineでのオーバープリント(5) - 理論通りにならない事例
以前の4つの記事
「Adobe PDF Print Engineでのオーバープリント(1) - 概要」
「Adobe PDF Print Engineでのオーバープリント(2) - 技術詳細」
「Adobe PDF Print Engineでのオーバープリント(3) - DTPアプリケーションの挙動」
「Adobe PDF Print Engineでのオーバープリント(4) - 覚えておくべき事」
では、基本的な事例を紹介しました。もう1年以上前ですね…
ここでは、その基本で説明した原理から外れる処理結果について、なぜ結果が異なる場合があるのか、技術的に説明します。
■結論「推奨アプリケーションではこの差違は発生しません」
・AdobeCS以降、QuarkXPress 6以降
オーバープリント処理の違いを意識する必要はほとんどありません
Acrobatのオーバープリントプレビュー通りの出力が得られます
・それよりも古いアプリケーション
オーバープリント処理の違いから出力を予測することが必要です
＜まとめ＞
不具合の要因(リンクで貼るとスジが出るなど)も考慮すると、特にAdobe CS 3以降、QuarkXPress 8以降を推奨します。詳細は、Trueflow出力の手引き 第14版P4「サポート DTP アプリケーション」を参照して下さい。
＜注意＞この記事は、特にIllustrator 10以前やInDesign 2.0.2以前、推奨設定を使用しないQuarkXPressを使用される場合にのみ必要な情報です。
■従来処理系と最新処理系の差違の基本
以下のオブジェクトにオーバープリント指定された場合で、かつ下部のオブジェクトもプロセスカラーの場合、オーバープリント属性が設定されていても、PDFの規格上ノセにならない事になっています。
・グラデーション(DeviceCMYKで指定された)
・パターン(DeviceCMYKで指定された)
・画像(DeviceCMYKで指定された)
・DeviceGrayのオブジェクト
Acrobatでの表示も規格通り、これらのオブジェクトはノセになりません。Trueflowでの出力結果は、基本的には以下の様になります。
・従来演算系：これらのオブジェクトのオーバープリントを処理
・最新演算系：PDFの規格通り、これらのオブジェクトはヌキに
これらの処理の違いから、同じデータをTrueflowの従来演算系と最新演算系の両方で処理した場合、出力結果の差違が表れます。上記、推奨アプリケーションでは、この差違は発生しませんし、デザインとしてもレアケースであること、DeviceGrayによる墨ベタにも自動オーバープリントは効くことを忘れないで下さい。
■基本通りにならない事例
以下の3つの事例は、本来の動作とは逆の結果になっていますが、それぞれ条件と技術的なロジック（理由）があります。
＜事例＞
1) 最新処理系なのに透明があるとDeviceGrayのオーバープリントがノセに
2) 従来処理系なのに透明があるとDeviceGrayのオーバープリントがヌキに
3) 従来処理系なのに透明があるとDeviceCMYKのグラデーションのオーバープリントがヌキに
＜発生条件＞
・同じスプレッド内（ページ内）に透明オブジェクトが含まれている。
・透明オブジェクトと該当オーバープリントとの位置関係は問わない。
・同じスプレッド内（ページ内）に透明オブジェクトが無ければ基本通りの処理になる。
→つまり、同じ処理範囲内に透明オブジェクトがあると、位置的には全く関係のない場所のオーバープリントも含めて動作が基本通りになりません。同じ処理範囲内に透明があると、処理が変わる、ということになります。
＜発生ロジック＞
1) 最新処理系なのにDeviceGrayのオーバープリントがノセに
同じページに一つでも透明オブジェクトがあった場合、透明の処理による色の整合性を保つ（透明が関わるDeviceGrayと、透明が関わらないDeviceGrayの色の結果を合わせる）ため、全てのDeviceGrayオブジェクトはSeparation Blackに置き換える処理を行います。
この処理は、同じページ上であれば、透明との配置関係の有無に関わらず、印刷用の色空間であることを明確に示すSeparation Blackへの置き換えを、Trueflowの入力処理の内部で行います。
DeviceGrayは、DeviceRGBと同じく光の強さを示しており、DTPアプリケーション上グレースケール100%は「黒」ですが、PDFの記述上は0が「黒」、255が「白」になります。
その結果、ノセになります。
従って、同じページに透明オブジェクトが全く存在しない場合は、ヌキになります。
2) 従来処理系なのにDeviceGrayのオーバープリントがヌキに
3) 従来処理系なのにDeviceCMYKのグラデーションのオーバープリントがヌキに
この2)と3)は同じ原理で説明できます。
Trueflowの従来処理系では、透明をそのまま演算できないので、入力処理の内部で透明の分割統合処理が行われます。この透明の分割統合処理を行う部分は（Trueflowのオーバープリントモードの設定に関わらず）PDFの規格に基づいてオーバープリントを再解釈します。
ここで、DeviceGrayのオーバープリントオブジェクトは、（PDFの規格に準じるとノセなくていいので）オーバープリントがOffのDeviceCMYK部品に変換され、結果ヌキになります。
DeviceCMYKのグラデーションも同じく（PDFの規格に準じるとノセなくていいので）オーバープリント設定はOffに変換されます。
逆に、同じページに透明オブジェクトが全く存在しない、などPDF1.3準拠のデータの場合、透明の分割統合処理も行われず、DeviceGrayやDeviceCMYKのグラデーションのオーバープリントオブジェクトは基本通りノセになります。
＜最後に＞くどい様ですが…
「結果は一致しない」事にのみ注目するのではなく、以下の項目を念頭に、「ほとんどの場合結果OK」と冷静に判断し、技術情報として正しく理解しておくことが重要です。
・全てAdobe CS3以降など推奨アプリケーションではこの差違は発生しない
・1)は、規格通りではないがオーバープリントがノセになる方向の違い
DeviceGrayになっている事に気付いていない事の方が多いので、ノセになるのが期待通りでは？
・2)は、DeviceGrayの墨ベタにも自動オーバープリントは効く
・3)は、ほとんどオペレーションミス（意図的にしたい場合は乗算の透明を使いましょう）
「最適な出力」とは、重箱のすみのギリギリの部分で、やむなく規格通りではない処理を行う事も含めて実現されます。今後も「最適な出力」を目指していきます。
2011年01月31日 ｜ 太らせた文字がかすれた様に出力される問題
■出力結果の例（拡大図）
■概要
文字の線幅を指定することで、文字を太らせるデザインを行った場合、RIPの演算結果、文字がかすれた様に出力される場合があります。この問題は低い解像度で、解像度に適さない線幅を指定した場合に発生する問題です。
■発生条件
・出力解像度が低い（この例では360dpi）
・文字の線幅を指定して、文字を太らせる
・この線幅が細い場合（この例では0.2pt）
→解像度が低く、線幅が細い結果、デバイス解像度で1ピクセルの線になる場合。
■回避策
・文字の線幅を指定する事で文字を太らせるのではなく、太い書体を用いる。
・文字に設定された線を太くする。（文字が潰れる弊害があります）
デザイン品質上の問題としても、文字の線幅を太らせる手法は、書体のバランスが失われ、文字が潰れるので、お勧めできません。
■発生原理
・文字はHINT情報により、図形の塗りつぶし (fill) の幅を一致させるために、調整されます。
・文字のアウトラインは、線幅補正機能（SA : stroke adjustment）により、線幅 (stroke) を一致させるために、調整されます。
・fillとstrokeが別々に調整（微細な移動）されることで、解像度が低い場合にstrokeとfillの間に隙間が現れます。
■HINT処理、線幅補正について（右図は概念で、実際の演算はもっと複雑です）
HINT処理や線幅補正処理は、文字や罫線の配置位置による統一性を保つために、理論的な配置位置を最大で0.5デバイスピクセル分移動します。
この移動により、実際の物理的な配置位置は1デバイスピクセル分の差違が出る場合があります。（実際には0.5ピクセルだけ塗ることはできないので、RIP演算時に丸められるから）
今回の線幅として指定された0.2ptは、360dpiではちょうど1ドットつまり1デバイスピクセル分しかありません。2400dpiだと0.2ptも7ドットで描画されます。
HINT処理や線幅保障処理によって、1デバイスピクセル移動した場合、2400dpiなら大きな影響はありませんが、1ドットしか描画されない360dpiでは大きな影響が出ることになります。
本来、HINT処理や線幅保障処理は、特に低い解像度で出力する場合に効果がありますが、360dpiでの出力において0.2ptの線幅を文字の周りにつける処理は、補正の限界を超えていると言えます。
