出力の手引きWeb[2010年03月]
1
2010年03月31日 ｜ 文字に透明度グラデーションを使う
＜2010年7月27日追記＞
この問題はTrueflow側での対策が完了しています。
詳細は記事「2010年07月27日｜7つの問題の対策、完了しました」を参照してください。
■概要
Illustrator CS4を用いて、文字に透明度グラデーションを用いた場合、Acrobat 8以前では正しく表示されません。
■実例(右図は2つのセットアップを合成しています)
1) 右図の様に、文字を並べて、アピアランスから透明度グラデーションを設定
2) PDF/X-4など、透明の活きたPDF形式で保存する
3) Acrobat 8以前とAcrobat 9で表示を比較
■Trueflowでの処理結果
処理結果は以下の通りとなります。
*1最新演算(Adobe PDF Print Engine)で、入力データをPDF1.3に変換する設定
*2入構データのPDFバージョンを保持し透明を活かす設定 (推奨設定)
*3現在開発中のパッチで修正予定(時期未定ですが、このサイトにてお知らせ致します)
■再現条件
以下の全ての条件が揃った場合にこの問題が発生します。
・Illustrator CS4で文字属性の塗りに透明度グラデーションを使用する
・Trueflowの従来演算、PDF1.3化する最新演算、Acrobat 8以前での表示
・PDF/X-4など透明が活きたデータで書き出し
・文字列が2文字以上で、2文字目以降が結果不正
■まとめ
PDFの記述としては文字列にTextClipとsh（シェーディング）とSMask（ソフトマスク）が設定された場合に、2文字目以降で発生する問題となっていますが、現状のDTPアプリケーションにおいては、Illustrator CS4のアピアランスから塗りの属性として透明度グラデーションを使用した場合が該当します。
Trueflowでは最新演算系で処理を行えば、内部でPDF1.3化の処理が入らない限り問題は発生しません。
OutlinePDF-Adv.を作成する場合にもPDF1.3化をしなければ2サイト運用でも問題がありません。
TextClipは文字をアウトライン化せずに文字形状でClipする、というPostScriptにはない記述なため、その分割統合処理は何かと鬼門です。
分割統合処理の必要のないPDF/X-4 + Adobe PDF Print Engineなら全て問題ありません。
2010年03月26日 ｜ 白ノセ取り込み設定も万全ではない
興味深い現象ですが、役には立たないかもしれません…
■概要
Trueflowでは自動墨ノセ機能だけでなく、間違いの多い白ノセを取り込むかどうか設定できる機能があります。
しかし、この白ノセの取り込み設定もRIP上でデータを書き換えており、条件によって期待通り動作しない場合があるのは、以前の記事「「白ノセ」トラブルを解決する(2)」でも紹介した通りで、この機能も、間違った入力データに対処するための最後の手段であり、万全な対応ではない事を知っておく必要があります。
ここでは、もう一つの事例を紹介します。白ノセ指定された様に見えるデータをTrueflowで「白色のオーバープリントを取り込む」設定にチェックを入れて処理をします。この場合、理論的には白ノセのオブジェクトが消えて出力されると考えられますが、実際には消えずに白いオブジェクトが見える状態で出力されるケースがあります。
■実例
この事例の最初のきっかけは、意図的に変な設定をしたところから始まります。
1) スウォッチの作成
再現するためには、Illustrator(CS4で試しています)のスウォッチで、CMYK全ての色値を0.003等の数値を入力します。この時、別のフィールドを入力しようとすると、表示上「0」に戻りますが、気にせずに4色とも入力します。(実験では、こういう事をする場合があります…)
この時に、見た目「0」に戻っているので入力できていないように見えますが、内部的には設定されている様です。
2) データへの適応
Illustratorでこのスウォッチを用いて色指定を行い、さらにそのオブジェクトにオーバープリント設定をします。
この時、あの意味の分からない警告ダイアログは表示されません。
しかし、オーバープリントプレビューで確認すると、確かにそのオブジェクトは白ノセの原理の通り消えて見えます。
このデータをEPS形式で書き出します。
3) InDesignへの配置
上記で作成したIllustratorEPSをInDesignに配置します。
この時、InDesignでのオーバープリントプレビューでも、該当オブジェクトは消えて見えます。他のオブジェクトの条件によっては白く見える場合もあります。
ここから、Trueflowの推奨設定でPostScript出力をします。
4) PDFの作成と表示
上記で作成されたPostScriptからDistiller(Distiller 9で試しています)を用いてPDF/X-1a形式で作成し、Acrobat 9で表示します。
そうすると、該当部分の白ノセが消えずに、白く見えます。
つまり、IllustratorやInDesignでのオーバープリントプレビューとは異なる表示になり、Trueflow(最新PDF処理で試しました)でもAcrobatでの表示と同じ処理結果になります。
■発生条件
発生条件は以下の通りです。
・Illustratorのスウォッチで、見えない0.003%などの値を設定する
・IllustratorからEPS出力
・InDesignからTrueflowの推奨設定でPostScript書き出し
■発生原理
Acrobat 9のオブジェクトインスペクタで該当部分を見てみます。
・下の4つが本来は白ノセになるはずのオブジェクト
・1つのオブジェクトが4つのオブジェクトに分解されている
・すべて分離、つまりSeparationカラースペース
・色名がそれぞれBlack、Yellow、Magenta、Cyanとなっている
・4つのオブジェクトは全てオーバープリント設定されている
・全てカラー値は[0.00]が、ここでは有効桁数が足らないようです。
この状態で、白ノセの様なオブジェクトは見えるようになってしまいました。この原因は2つあります。
1) 色値が0ではない
実際は0.003という色値があるので、ノセにはならないのですが、このゼロ付近の色値については、最終的な丸め誤差によって、処理系によって0と見なされる場合もあり、これだけが原因とは言えません。
2) Separationカラースペースは「0%の色がある」
DeviceCMYKでは、0%のオーバープリントを透過と解釈していましたが、Separationカラースペースでは、DeviceNと同じ様に「0%の色がある」と解釈されるので、色値に関わらず透過にはなりません。
4版とも0%の色で描画されるため、白いオブジェクトが見える状態で出力されます。
■まとめと回避策
確かに、最初のスウォッチの設定で0.003などと設定するのは不自然ですが、一旦その様なスウォッチが設定されてしまうと、特別なツールでも使わない限りもう二度とその色値を確認する事はできず、しかもIllustratorやInDesignのオーバープリントプレビューでも、完全な白と同じ様な挙動を示すために、理論通りの結果にならない原因を発見することは困難です。
しかも、元のIllustratorのデータ一の一部の再利用などで使い回され、さらに特殊なスウォッチの存在は分からなくなります。
この4つのオブジェクトに分かれてSeparationカラースペースに変換される、という挙動は、微小な色値の入った白っぽい色が用いられた場合にのみ発生する様で、この分解を行っているのはInDesignでの最後のPostScript出力時です。
回避方法というか理論通りの結果を確認する方法としては以下の様な事が考えられます。
・スウォッチで微小な値を設定しない 試したとしても、試したことを忘れない
・Acrobatでのオーバープリントプレビューは、このデータを正しく表示できる
・IllustratorEPSを用いずにIllustratorネイティブを使用する 本来の推奨運用です
・InDesignからPostScript出力をせずに、PDFをダイレクトに出力する 本来の推奨運用です
白ノセが見えるようになるからと言って、絶対にこの様な設定を使ってはいけません。
[第13版] [オーバープリント] [Acrobat] [Illustrator] [InDesign] [解説追加] ｜ 固定リンク｜ 
2010年03月26日 ｜ 自動墨ノセは万全ではない（Adobe情報）
以前の記事「自動墨ノセは万全ではない」でお知らせした問題について、Adobeのサポートデータベースに「文章番号cpsid_82798 透明を使用した箇所がオーバープリントにならない（Illustrator CS-CS4）」が掲載されていました。
回避方法として、リッチブラックを用いる方法も紹介されています。
ケヌキのEPSとしては間違ってないのに、情報は公開するという姿勢は評価できます。
2010年03月24日 ｜ 自動墨ノセは万全ではない
■概要
Trueflowでは「自動オーバープリント設定」として、平網や文字がK=100%のみの場合、そのオブジェクトをオーバープリントとして出力する事ができます。
この処理は、入力されたデータ上でオーバープリントがOffの場合でも、そのデータを書き換えてオーバープリントOnとして演算します。
しかし、この機能は入力データの状態によって、期待通り出力されない場合があります。
この様な、RIP上でのデータの書き換えは、間違った入力データに対処するための最後の手段であり、万全な対応ではない事を知っておく必要があります。
■実例
以下の手順で作成されたEPSは、Trueflowで「自動オーバープリント設定」を用いても、墨ベタ部分は下のグラデーションに対してオーバープリントになりません。
1) Illustrator(10～CS4)で右図の様なデータを作成します。
2) オブジェクトの重なりは、下からグラデーション、墨ベタ、画像の順で、僅かに墨ベタと画像が重なってします。(ここがミソ)
3) 墨ベタの部分の下にはグラデーションがあります。
4) ここで使用する画像は、この記事の手順で作成した(必要のない透明が含まれた)Photoshopネイティブです。
5) このデータをEPS保存します。
■発生条件
発生条件は以下の通りです。
・グラデーションや画像の上部に墨ベタの平網がある
・その平網に影響する透明オブジェクトがある
・EPS形式で保存する(Illustratorで透明の分割統合処理を行う)
・Trueflowの「自動オーバープリント設定」で墨ベタをノセに
■発生原理
データ上で、どの様な事が発生しているのでしょうか？
発生条件を満たす、もう少し単純なデータで確認してみます。
右図の様なデータでもEPS形式で保存すれば条件を満たします。
以下の手順で発生原理を確認します。
1) このEPSをDistillerでPDFに変換し、Acrobatで開く
2) AcrobatのTouchUpオブジェクトツールで墨ベタの部分を削除
・この手順で確認すると、右図のように墨ベタの部分にグラデーションがなく、白く抜けており、上部の墨ベタ部分にオーバープリント属性を加えても、下部のグラデーションとは合成されません。
・もし、この墨ベタ部分に透明オブジェクトが関係していなければ（右下図参照）、TouchUpオブジェクトツールを用いて削除しても、その下にグラデーションが存在しているので、墨ベタの部分にオーバープリント属性を加えると期待通り墨ノセになります。
・TouchUpオブジェクトツールで墨ベタを消去して見える部分は、あくまでもデータ上そのオブジェクトがあることを確認しているだけで、実際に出力されるかどうかは、墨ベタのノセ、ケヌキ設定に依存します。
・つまり、このデータを、RIP側でデータ通り(つまりケヌキで)出力すると、演算結果として、この部分にはグラデーションは描画されません。
■まとめと回避策
つまりIllustratorのEPS出力で行われる透明の分割統合では、データ通り、つまりケヌキであることを解釈して、分割統合を行う為に、下のグラデーションの部分が抜けています。(つまりRIP演算の一部をケヌキ前提で済ませている訳です)
RIPでデータの書き換えを行わない場合、この部分はケヌキで出せばいいので、EPSの記述内容には問題ありません。
しかし、RIP側でデータを書き換えて、間違ったデータを期待通り出力しようとしても、データの時点でオーバープリントの対象となるオブジェクトがないので、期待通りにはなりません。
上記のダッキーの例の様に、オーバープリントになるべきオブジェクトに、透明が関係していることが簡単に発見できない場合もあります。
以下の回避方法によって、この問題を確実に防ぐことができます。
・正しくオーバープリント設定を行い、データ通り出力する
・aiネイティブやPDF/X-4など、透明を活かした出力を行う
1
