ちくちく日記

DTP系備忘録。真面目にやってます。

スクリーントレンドセミナー2008秋-技術セッション-

トレントセミナーの目玉といえば、大日本スクリーンの技術者による「技術セッション」
Trueflowの開発者の方が、出力技術情報を解説してくださるという、このセッション。
商売っ気なし。純粋に技術解説!というすばらしさで一部マニアに大人気…なんだと思う。多分。いや、少なくとも私は大喜びしてるんですけど。

ともかく、その技術セッション。
回を重ねるごとに、というか特に今回、スクリーンの方のふっきれかたがすごくって、セッション冒頭で堂々と「マニア向けです!」と宣言しておられました(笑)
あ、もう内部的にもそういう認識なんですね(笑)ついてこれるやつだけついてこい、と。ついていきます(笑)

さて、セミナーレポート。
今回、45分の内容だったのだけど、セミナー司会者の方曰く「本人2時間ぐらい話したいといってますが45分です。」と。
2時間分ぐらいの分量をみっちり詰め込んだ45分だったようです。(後のインクジェット機セッションでもカラーマネージメント担当の人が「1時間ぐらい話したいんですけど…」って言ってたな。スクリーンの技術の人は、話したい人が多いのか)みっちりの45分、必死でノートとりましたよ。

まず話題はAdobeCS4から。

新発売のCS4。数多くの新機能が搭載されてますが、印刷的には「刷れてナンボ!」と。(こういう時、この会社が関西の会社であることを思い出します…)スクリーンはその辺、きっちり準備して、印刷できるように検証してまっせとのこと。

まずAcrobat9から。
Acrobat9はCS4で初搭載されたわけではないけど、DTP業務必携アプリケーションと言える。それがなぜかを解説。

Acrobat9の印刷向け機能については、いままでのトレンドセミナーでも紹介されていて、たとえばオーバープリントプレビュー。PDF/Xデータは自動的にオーバープリントプレビュー表示されるなど、デフォルト設定がプロ仕様。困ったときの最終兵器、オブジェクトインスペクタもはずせない。

今回はさらにもう一つ、最終兵器機能を紹介。
「透明の変換用カラースペースの対応」

CS系アプリケーションから書き出されたPDFをRIP処理したときに、透明の影響を受ける部分だけが、色が変わってしまうことがある。
これは出力の手引きWebの方でも紹介されている事例ですね。
AdobeCS系のカラー設定と透明効果|出力の手引きWeb|株式会社SCREENグラフィックソリューションズ

CS系アプリケーションから透明を含んだPDFを書き出すとき、カラー変換の設定は「カラー変換なし」を選ぶべきなのだけど、ここの設定をうっかり「出力先の設定に変換」「出力先の設定に変換(カラー値を保持)」などを選んでいるとRIP上でプロファイルに応じた色変換が行われてしまい、結果透明効果の部分の色がかわってしまう。

CSにデフォルトで用意されているX-1a書き出し設定などでは、ここが「出力先の設定に変換(カラー値を保持)」になってる。ちなみに、スクリーンの配布しているTrueflow印刷ユーティリティでは「カラー変換なし」

では、もし、この設定が間違っているPDFが入校されてきたら、どうしたらいいのか。

そこで秘密兵器!

まず、そのPDFがどういう設定で作成されたかを確認する方法。
Acrobat9のアドバンスドメニュー→印刷工程から、出力プレビューまたは分割・統合プレビューを選択。
透明の変換用カラースペースの項目がDeviceCMYKになっていればOK。ここに何らかのプロファイルが指定されていたらNG。

こっからが禁断の技。
残念なことにNGだったPDFファイルを修正する方法。
アドバンスドメニュー→印刷工程から、分割・統合プレビューを選択します。

透明の変換用カラースペースの項目から変更を選び、カラースペースをDeviceCMYKに変更。これでOK。

注意して欲しいのは、この方法はあくまでも緊急時の対策であって、スクリーンとしては推奨するものではないとのこと。いざという時だけ使いましょう。複雑にプロファイルが設定されている場合はこれでは回避できない場合もあるようです。


「カラーマネージメントについて」

上の例も、思わぬプロファイルの添付が事故のもとになっているのだけど、これに限らずカラーマネージメント関連の設定に無頓着な人は多い。
RGBワークフローを使っているならともかく、CMYKのデータのみを触っている分にはプロファイルを意識することはあまりないし、間違ったCMYKプロファイルをつけていてもそれほどトラブルにならない場合が多い(これは、出力側でプロファイルを無視するような設定をしてあるからだと思うのだけど)
でも、今後PDF運用が増えていくなら、プロファイル運用も当然ありだろうし、セミナー内では「RGB運用じゃなくてもプロファイルの設定は大事です。ちゃんとしましょう」って話があってた。

スクリーンの配布しているTrueflow印刷ユーティリティにはCSで使えるカラー設定ファイルも用意されている。
「Trueflow Color Pro」と「Trueflow Color Std」ProとStdの違いは、カラープロファイルの警告がでる(Pro)かでないか(Std)だけで、他は同じ。Bridgeをつかって、カラーの同期設定は必ずしておくこと。

Illustrator CS4 透明グラデーション」

Illustrator CS4ではグラデーションオブジェクトに透明度が設定できるようになりました。
透明+グラデーションって、もうそれだけで出力的にやばそうなにおいぷんぷんなんですけど(笑)

もちろん、この機能もスクリーンはばっちりテスト済み。Trueflowでの出力に問題はないそうな。
でも「ちょっと注意点があります」きたー。

結論からいうと、透明グラデーションを使ったデータをInDesignCS4、Acrobat9以外のアプリケーションで扱ったとき、オブジェクトの欠落などが起きる可能性がある。
IllustratorCS4の透明グラデーション|出力の手引きWeb|株式会社SCREENグラフィックソリューションズ
つまり、IllustratorCS4のデータをInDesignに貼って出力するなら、InDesignはCS4以上を使わなきゃだめってことだ。

透明グラデーションで使われている技術は「ソフトマスク(SMask)」っていうものだそうで、これはドロップシャドウの効果などでよく使われているもので特に目新しいものではない。
で、グラデーションにはグラデーションの指定として「シェーディング(sh)」という指定がされる。
この二つは個別に指定してある分には問題がないのだけど、このたび透明グラデーションとして一つのオブジェクトに同時に指定されるという状況に!
どうもそれが新しいソフト(InDesignCS4、Acrobat9)でないとうまく取り扱えないみたいです。

…でもさ、でもさ、これって、透明+グラデーションがまずいって話ならEPSにして透明分割しちゃえば万事かいけt…げふんげふん。
PDFワークフローを押し進めるスクリーンとしては、口が裂けてもそんなことは言えませんが。

気を取り直して、次の話題へ。
「PDF/X-4についてのおさらい」

PDF/X-4ってのは、印刷用PDFであるPDF/Xの規格の一つなのだけど、大きな特徴としては、なにより「透明を維持している」ってこと。

PDFの中で透明を維持していると何がいいのかというと、透明の分割、統合をアプリケーション側でやる必要がない。つまり透明のままRIPに渡して、RIP側で最適な演算をかけることができる。

透明効果を使ったデータ出力において、例えば、透明の影響を受ける文字データ部分も個別に高解像度でラスタライズすることができたり、透明効果を使ったRGBの画像をRIP上で最適変換できたりすることで品質向上が見込まれる。

ここまでが基本知識。

さて、そのPDF/X-4の作成について。
PDF/X-4は透明を含んだPDFであるので、その作成においても「透明を維持して作る」ことが大事。セミナーでは「活きた透明(Live Transparency)のデータ」って言ってましたが、つまりアプリケーションからダイレクトでPDFを作ること。
アプリケーション→ダイレクトにPDF/X-4書き出し→APPEで処理、のワークフロー。
Postscriptを使用しちゃだめってことです。PSファイルを作るのはもちろん、EPS保存するのもアウト。


「PDFのデジタルトンボについて」

PDF内部にはトンボ情報として「TrimBox:仕上がりサイズ」「BleedBox:裁ち落としサイズ」「MediaBox:用紙サイズ」がある。
これは通常では表示されていないが、Acrobat Professionalの環境設定「アートサイズ、仕上がりサイズ、裁ち落としサイズを表示」にチェックを入れることで、表示されるようになる

このデジタルトンボは、PDF内に記述されているものだが、TrueflowがPostscriptをPDFに変換するとき(デジタルトンボの記述のない)Postscriptからどうやってトンボを生成しているのかという話。
Adobe CS系アプリからはかれたPSには「pdfmark」という記述でデジタルトンボが準備されている(Postscriptとしてはpdfmarkは必要ない記述なんだけど、PDFへの変換を見越していれてあるらしい)ので、それを使って変換。
QuarkからのPSの場合、PSからトンボのパターン記述を読み出してトンボを認識し、PDFのトンボに置き換えているのだそうな。こういう処理をIdiomRecognitionというのだと。

Quarkのトンボといえば、少し前、TrueflowのQuark8への出力対応で対応パッチのリリースが遅れるという話があったのだけど、この時の理由が「QuarkXPress Ver8.01において、このトンボの記述形式に変更があり、用意していたパッチではQuarkXPress Ver8.01に対応できなくなりました」と説明されている。
QuarkXPress 8のPostScript対応リリース延期|出力の手引きWeb|株式会社SCREENグラフィックソリューションズ

なるほど、PSの中から記述パターンを調べて、トンボを読み出す処理をやってたのに、そのトンボをかえられちゃったって事だったのね。



「DeviceNを理解する」
つづいてはDeviceNについて。DeviceNについてはいままでのトレンドセミナーでも何回も説明されているんだけど、もう一度おさらい。

DeviceNとはデバイスの色空間の指定の一つ。
「DeviceN」と「DeviceCMYK」の違いは

「DeviceCMYK」
・(データ内に使用していなくても)CMYKの4色が必要
・(オブジェクトへの指定について)CMYK4色の数値で指定する必要がある。

「DeviceN」
・(データ内での)色数は自由である(一つのオブジェクトに混合して指定できる色は32色まで)
・使われていない色は指定しなくてよい
・色名は自由につけられる(cyan、magentaなどの予約語はある)

詳しくは出力の手引きWebを参照すべし。
DeviceNを理解する|出力の手引きWeb|株式会社SCREENグラフィックソリューションズ

で、DeviceNで大きな違いがでるのは、オーバープリントの処理。
0%の色を「色がない」と判断するDeviceCMYKに大して、DeviceNでは「0%の色がある」と判断する

こちらも出力の手引きWeb参照
オーバープリントを正しく理解する(2) - DeviceNの影響|出力の手引きWeb|株式会社SCREENグラフィックソリューションズ

この考え方を進めると、以前に書いた「DeviceNだと白のオーバープリントは事故にならない?」という話ができる。

白のオーバープリントを「色がない」と判断するDeviceCMYKに対して、「0%の色がある」と判断するDeviceNなら事故にならない(実際にはアプリケーションの動作が絡むので話はそう簡単ではないのだけど…)

「OPMについて」

この0%の色がある、なしを判断する処理、実はDeviceCMYKでも「0%の色がある」とする設定があるのだそうな。
それが/OPM(オーバープリントモード)。PDFの記述の一つ。/OPMが1の時、DeviceCMYKの0%は色がないと判断され、/OPMが0の時は0%は色があると判断される。
Trueflowでは通常の設定は/OPMが1。この設定を変える運用というのはまずないと思う。じゃ、なんでこんな設定が用意されているのか?というと、どうやらRIPのテスト(試験?)に合格するためにこういう設定も必要なんだそうです。

Distillerにもこの設定は用意されていて、詳細設定のなかの「オーバープリントのデフォルトをノンゼロオーバープリントにする」という項目が/OPMの0と1を切り替える設定だそう。
通常はここにチェックが入ってるし、このチェックを外してはだめ。

ちなみに、むかーーーしのIllustratorは/OPM 0で動作していたのだと。
セミナー内でも「通常(この知識は)役に立ちません」みたいなことを言ってましたが、ほんとに知っていたからといって使うことはなさそうな知識です。そんな知識を解説するセミナー…すばらしすぎる。


「特色指定について」

一言でいうと「特色は正しく設定しよう!」ということなのだけど、なぜ特色を正しく設定する必要があるのかの話。

よくあるデータに「プロセス4C印刷なのに、特色スウォッチから特色ばりばりに使って作ったデータ」というのがある。こういうデータを作る人は特色スウォッチを「色見本いっぱいのカラーパレット♪」ぐらいにしか思わず使ってんだろうな…と推測されますが、そういったデータが入校されたとき、以前は「Trueflow側で特色をプロセス4Cに変換して出力」という手が使われていた。(RIP側でこういう処理をしてあげていた、という事がそもそも「特色スウォッチ使ってても問題ないじゃん、色パレット代わりにつかおう」というデータ作成者を育ててしまったともいえますね)

ところが、最近の透明を扱えるアプリケーションでは、特色の透明の処理がオーバープリントで表現される。そのためRIP側で単純に疑似色化したときに出力されるイメージがまったく変わってしまう場合がある。

要は最近のアプリケーションで作られるデータは、昔ほど単純じゃないんだよ…ってことだね。RIPで出力を修正できないのだから、アプリケーション側できちんとデータをつくる必要があるわけだ。

では逆に「正しく特色で作られたデータを、4Cで出したいときはどうするか」
どういう場面を想定しているかというと、特色を含む印刷物をオフセットで印刷した。その後、小ロットの追加発注分はオンデマンドのプリンターで出力することになった…といった場合。
これは今後十分考えられるワークフロー。

データとしては、正しく特色で作られている。でもオンデマンドのプリンタというのはだいたい4色機。
4色機で特色の合成シミュレーションを行いたい場合、出力処理側で特色の疑似色化を行えば、近い仕上がりを得る事ができる。
入力処理とちがって出力処理では、ラスタライズの行程がはいるので、オブジェクトの重なりやオーバープリントを考慮しながらラスタライズすることで正しくシミュレーションできるらしい。


「白ノセトラブル」

白のオブジェクトにオーバープリントをかけて出力すると、そのオブジェクトは出力されない。よくある白ノセの事故ですが、これをRIP側で救うことはできるか?という話。
/OPMを0に設定すればいいんじゃん…なんていうマニアなネタはともかく(/OPM 0ならたしかに白のオーバープリントは救える…がそれ以外にいろいろと問題がでるだろう)白オブジェクトにオーバープリントが乗っているものをRIP上で一括置換することはできないのか?

実はTrueflowには「白色のオーバープリントを取り込むかどうか」という設定がある。この設定を「取り込まない」にしておけば白のノセオブジェクトは破棄される…のだけど、話はそう簡単ではない。

例えばIllustratorに白のオブジェクトにオーバープリントを設定したものをEPS保存したとき、データの最適化処理がおこなわれ、白のオーバープリントオブジェクト=出力されないオブジェクトとして"カラースペース:分離(Separatin) 色名:None"のオブジェクトに変換されてしまう場合があるのだそうな。
オブジェクト自体が白のノセオブジェクトではなくなってしまっているので、RIP側の設定でチェックしようとしてもひっかからない。
ここでも「データを正しく作る」が大事という事です。
っていうか、もうRIPでデータを救済するっていう考え方が無理なんだよね…アプリケーションが救済できるようなデータを作ってくれないんだもの。

と、いうことでTrueflow技術セミナーは今回もマニア向けでした。満足。