PDF/X-4とAdobe PDF Print Engineのワークフロー
大日本スクリーンの「最新ワークフロートレンドセミナー」に参加してきました。
自分用の備忘録もかねてセミナーレポートを書いておきます。
Trueflowユーザー向けに行われるこのセミナー、Trueflowno最新機能紹介などとともに、RIP最新技術の解説などが行われる。
特に、最新技術説明の部門については、TrueflowだけにとどまらないPDFやRIPの最新動向について、Trueflow開発者が解説してくれるという、マニア大喜びの内容（こんなことで大喜びするマニアが日本に何人いるのかはわからない。私一人かも）
前回は2006年7月に行われ、そのときのセミナーレポートはこちら↓
http://
かなり私感を交えたレポートだけど、ポイントとしては「なかなか広まらないPDFワークフローだけど、今後はもっともっと広まっていくべきだと思うよー。特にAdobe PDF Print Engineがでたら、透明の処理もできるようになるしさ。でもPDFだと正しく作ったデータじゃないとちゃんと出力できない。だからデータは正しく作ろう（そして正しく出力しよう）よ」って感じ。
今回のセミナーでも、方向性は同じだった（まぁ半年程度でころころ方向性が変わっちゃたまらないが）
ただ、前回のセミナーと違うところは、前回は発表されたばかりで、概要説明にとどまっていたAdobe PDF Print Engine（以降APPEと勝手に略す）について、より具体的な説明とメリットの解説があった事。
APPEはいままでのCPSI系のRIPと違って「Adobeソフトの透明効果」を処理できる。これは前回のセミナーでも説明があった通り。
ではRIPが「透明効果」を処理できると、具体的にどういうメリットがあるのか？
「透明効果」の出力は難しい。
現在出力に使われているPostScriptという仕組みには「透明効果」という概念がないから、PostScript処理の為のエンジンであるCPSI系のRIPで「透明効果」を処理する為には、処理するデータを事前に「透明効果ではない形」に分割してやる必要がある。
アプリケーションの操作としては簡単だ。いくつかのパラメータを正しく設定して保存するだけでいい。（この辺の操作の簡単さ、Adobeのソフトは良くやっていると思う）これだけでCPSI系のRIPでも処理できるデータが出来上がる。
では何が難しいのかというと、この処理によって出来上がるデータを予測する事が難しいのだ。
透明効果の分割統合処理で行われているのは、結局、本来ならRIP側で行われるはずの分版処理に近い。
RIP側で透明を処理できないので、出力できる形にデータの形式を変更する。例えば透明の効いた部分のオブジェクトをオーバープリント処理したり、ラスタライズ→ビットマップ化で画像にしてしまったりといった処理をアプリケーション側で行ってしまう。その処理がどこからどこまでどんな風に行われるかはアプリケーション任せだ。
よく言われるトラブルに、透明効果の影響をうけたたテキスト部分が太って出力されてしまうというのがある。
透明のオブジェクトにテキストの一部がかかっている。これを出力すると、テキストの部分がほかのテキストより太って見えるというもの。
低解像度の出力機であるほど、その差が顕著に現れるけど、高解像度の出力機であってもよく見ると他の部分より荒く出力されているのがわかる。
これは本来ならRIP側でデバイスに合わせた解像度に展開されるべきところを、事前に処理しなきゃいけないのでアプリケーション側の設定値に合わせて展開してしまっているのが原因。
通常アプリケーション側での画像解像度は360ppi程度に設定してあるがテキスト部分はその解像度では低すぎる。最適な結果を求める場合は1200ppiぐらいの解像度が望ましい。だからといって、設定を1200ppiにしてしまっては、そこまで解像度の必要がない部分まで1200ppiで処理されてしまう。
さらにRIPの設定によっては、画像に対して一律にjpeg圧縮をかけている場合がある。文字部分にjpegをかけられると、場合によってはブロックノイズが目立ち品質が落ちる。
でもこういうのって、結局出力してみなければわからない。だから出力機をもたないデザイナーさんやデータ作成者にとっては、仕上がりを予想するのは難しかったはず。
そもそも出力時にどのぐらいの解像度にすべきかというのは、出力しようとするデバイスによって変わってくる。
つまりデバイスに依存する部分であるわけで、この部分は本来RIPがやるべき処理である。そこを事前に処理してしまっているので、最適の出力結果が得られない場合があった。
前置きが長くなったけど、つまりAPPEではこういった「透明効果というデバイスに依存する部分」をデバイス側に任せてしまえる。
デバイスに任せる事ができれば、それぞれをデバイスに最適な形で処理できる。それがAPPEでのメリット。アプリケーションでの事前処理が絡まない分、出力結果も予測しやすい。
もちろん、そうやってデバイス側で処理するためには、デバイス側で処理できるデータで渡してやる必要が有る。つまりいままで事前に処理していた部分を「処理せずに渡す」必要がある。
従来の出力で使われてきたPSやEPSというファイル形式では、透明効果はどうしても分割されてしまう。現在PDFの主流フォーマットになりつつあるPDF/X-1aも同じく、透明効果を事前処理してしまう。
「新しい酒は新しい皮袋に盛れ」というように新しい出力であるAPPEには新しい出力フォーマットが必要。と、いうわけで透明効果を維持できる、新しい規格がPDF/X-4。
PDF/X-4はPDF/X-1aのように「印刷向けのPDF」として制定された規格。ただしPDF/X-1aとは大きく違う点に
・透明効果を保持できる
・レイヤー構造を保持できる
というところ。
APPEを中心にした新しいワークフローでは、アプリケーションから透明を含んだままのPDFとしてPDF/X-4で書き出し、それをAPPEのRIPで処理する形になるだろう。
もちろん、データの作成段階でも、透明効果を常に保持する必要があるので、レイアウトで使用するファイルはつねにPDF（またはアプリケーションネイティブ形式のPDF）で作業し続ける必要がある。現在主流のEPS形式は廃止の方向で。（と、いいつつ、うちでもいまだ、ばりばりEPSが主流だ…CS等の新しいソフトでの作業時も、ネイティブ形式のファイル運用には不安があるんだよね…）
PDF/X-4には透明効果以外にもRGBなどCMYK/特色以外の色空間を含めるというメリットもあるけど…こちらを活かすRGBワークフローについてはAPPEとはちょっと別のところにあると思うので、省略。
APPEのメリットについてはもう一つセミナーで見た事を書こうとおもったのだけど、あまりにも長くなりすぎたので、この日記はここまで続きはまた。
