セミナーの感想
大日本スクリーンのトレンドセミナー2006に参加してきました。（え？いつかって…？せ、先週の水曜日です。すんません…いまごろ…）
以下、セミナーレポート…というか、セミナーを聞いて考えた事をいろいろと。
セミナーで聞いた内容に私の私感を交えておりますので、内容の正確性は保証いたしません。と、前置きしつつ…。
このセミナーはAdobeによる最新アプリケーションでPDFワークフローの説明とか、新しいTrueflowの機能紹介といった内容のセミナーなのだけど、その中でスクリーンのRIP開発担当の方がRIP運用上のトラブルポイントや技術などを説明してくれるというコーナー（コーナーか？）がある。
私のお目当てはこれ。
去年もこのセミナーを受け、そこで得た情報を元にデータ出力の方向性とか方針を変更した。
それまでうちのRIPの運営方針は「だめなデータもできる限り救って（修正して）出力する」だったのだけど、前回のセミナーを聞いて「今後はデータをデータ通りだそう（だすしかない）」という方向に転換した。
（そのへんの経過はこの日記のあたりに）
http://
「データ通りにだすしかない」と決めたのは「データ作成の責任は作成者にあるべきなのだ！印刷会社がその尻拭いをするべきではない！」とかそういった高尚な理想を掲げたわけではまったくなく、単純に「最近のアプリケーションから吐き出されるPSはデータ通りに処理しなければ、まともに出力できない」という事実を知って「間違ったデータを救うために、正しいデータもおかしく出力されてしまうリスクをとるか、まともなデータはまともなデータとしてちゃんと出力するけど、間違ったデータは間違ったまま出すか」という二者択一を迫られた結果、後者をとったわけである。
今回のセミナーでもその「データ通りに出す」という方向性を再確認できた。
トレンドセミナーというだけあって、セミナー全体で今の出力のトレンド（しかしトレンドって言葉も古いね、なんとなく…）を中心にした話をする。今のトレンド（古い）はなんと言っても、PDFのワークフローである。
PDFのワークフロー、世間一般では「入稿データとしてPDFをつかいましょう」というPDFワークフローの方が話題になる事が多く、そしてこの「入稿にPDF」というのは、話題になるわりには普及してない。（普及していない理由はいろいろあると思うけど、結局、一般の人はPDFで入稿することのメリットをあまり感じられないということなのだと思う）
でももうひとつ「出力にPDFを使いましょう」というPDFワークフローもあって、実はこっちの方はかなり進んでいる（と、私は思う）
だいぶ以前から出力ではPDFが利用されている。それは、RIP内での「中間ファイル」という形式で。
PSをRIPに投げて処理をすると、処理されたPSファイルがそのRIP用の専用フォーマットとして保存される。これが「中間ファイル」。
そしてこの「中間ファイル」はファイル形式としてPDFが利用されている事が多い。
PDFといっても、あくまでRIPの独自フォーマットにPDFの皮をかぶせたようなものであるらしい（だから「天ぷらPDF」なんて呼ばれる。私は1オペレータにすぎないので、詳しくはわからない）が、それでもPDFである事には違いない。
だから出力の現場では「出力にPDFを使う」という事にはかなり抵抗が少なくなっている。
そこにAdobe PDF Print Engine（APPE）の登場。
先日発表されたばかりのこのエンジン、まだ実際にこのエンジンを搭載されたプリンタやRIPがないため、今回のセミナーでも概要紹介という形で大雑把な説明しかなかったが、簡単に言うとこのエンジンは「PDFをネイティブで処理できるエンジン」という事になる。
PDFを処理できるエンジンとは何か？いままでのエンジンとどう違うのか？
いままでにも「PDFを処理できる」RIPはあった。各社様々なRIPで「PDFを処理できます」としている。だけど実はこれらのRIPは受付たPDFを「内部でいったんPSに変換して」処理していたらしい。つまり従来のCPSI系RIPはあくまでPostscriptとしてしかファイルを処理できなかったと言う事だ。
では、これが、PDFをネイティブに処理できるAPPEにかわるとどうなるのか。
単純に考えて「PDFにあってPostscriptにない物が処理できるようになる」はず。「PDFにあってPostscriptにない物」……透明効果だっ！
現状のCPSI系RIPは「透明を含むPDF」を処理する事ができない。
Postscriptには「透明」という概念がないので、どうしても「透明部分を分割する」必要があった。透明効果の分割はアプリケーション側で事前に行われるので、アプリケーション側の設定によっては、適切な分割が行われず、最適な出力結果が得られない場合もあった。
それがAPPEになれば「透明を含むPDF」をダイレクトに処理できるようになる。
つまり、デバイスに合わせた最適な分割をデバイス側で行えるという事。
こうなってくると、透明効果の処理については、RIP側で行う方がいいという事になる。ってことは、いかにして「透明の情報を保ったまま」出力まで持って行くかが大事になってくるってことで…現状の「Postscriptファイルを書き出して処理」というワークフローでは、透明をそのまま持って行く事ができないので、これからは「アプリケーションからダイレクトに透明を含んだPDFを書き出す」というのが正しいワークフローになっていくのだろう。（もちろん何のアプリケーションでもいいという訳ではない。透明を含んだ正しいPDFを書き出せるアプリケーションからという事で）
さらにいうと、今、PDFの入稿フォーマットとして主流になりつつあるPDF/X-1aも、透明効果を事前に分割することを前提としたフォーマットなので、APPEでのワークフローにはそぐわない。
今後は透明を含む事のできるPDFの規格（PDF/X-4）が取って代わって行くことになるのだろうと思う。
こうなってくると、うちが「きたデータをデータ通りに出力する」という方向転換をしたのは、間違ってなかったなー。
「PDFでの書き出し→そのまま出力」のワークフローには「RIPでデータを修正する」というやり方はそぐわない。
