TrueflowSE - ちくちく日記

大日本スクリーンの「トレンドセミナー2007」に参加してきました。遅ればせながらレポートを。
メインテーマは「PDFブレイク元年」だそうで。「トレンド」といい「ブレイク」といい、こちらのセミナーはどことなく時代を感じるタイトルが多い（笑）

タイトルは時代を感じさせますが、内容はピカピカの最新技術。特に今回はAdobe PDF Print Engineを搭載した初めてのRIP「Trueflow SE」がもうすぐ発売ということもあって、APPEに絡んだ情報をいろいろと聞くことができた。

その「TrueflowSE」
いままでTrueflowはずっと（CPSI系ではない）独自のエンジンを搭載していたわけだけど、ここにきてついにAdobe純正のエンジンであるAdobe PDF Print Engineを搭載！
一体どういうことになるのだろう（APPEに完全切り替え…はないとしても、別のRIPとして発売とか…？）と思っていたら、なんと従来のTrueflowエンジンとAPPEのデュアルエンジン構成になっていた。

内部に二つの処理エンジンがあり、処理するファイルによって、APPEで処理するか従来のTrueflowエンジンで処理するかを選択できる。エンジンの切り替えはホットフォルダに設定。APPEで処理したいファイルはAPPEのホットフォルダになげ、従来のTrueflowエンジンで処理したいファイルは従来のホットフォルダに投げる。

APPE搭載といっても、現時点ではAPPEのメリットを活かせるデータはそれほど多くないわけで、実際の業務はいままで通りの処理が求められる場合が多い。従来の処理ラインはちゃんと残しつつ、新しい処理にも対応できる。まことに現実的な構成だと思う。

実際の業務ではまだ使用しない…とはいうものの、やはり今回の目玉はAPPE。
いままでは、次世代のRIPとして概要の説明だけにとどまっていた物が実機として登場。ユーザーとして気になるのは、従来のTrueflowエンジンとの違いはどういう点か。そして、他社製のAPPE RIPとの違いはどこにあるのか。

APPEというのは、完全にブラックボックスになっていて、Adobeから提供されたエンジンをそのまま使うしかない（と聞いている）と、いうことは、各社のRIPの違いはなくなるのか？独自フォーマットの中間ファイル（OutlinePDF）はどうなるのか？

答え。
確かにAPPEはブラックボックスで、そこの部分の処理はどこのメーカーでも同じになる。
APPEの処理はPDF+JDF（データ本体であるPDFとそのデータをどのように処理するかの指示ファイルであるJDF）で行うので、同じPDF+JDFを処理すればAPPEでの結果は同一である。
ただし、だからといってTrueflowと他のメーカーのRIPが同じであるということではない、APPEでの処理は一緒であるが、実際はファイルに対する入力処理（事前処理）、出力処理の部分はメーカーのノウハウが活かされる。

実はAPPEがでるずっとまえから、Trueflowってのは、PDFネイティブRIPだった。他のCPSI系RIPは入力されたPDFを一旦PSに変換してからでないと処理できなかったのに比べて、PDFをそのままゴリゴリと処理できる唯一のRIPだった。（ただPDFネイティブとはいっても、透明効果については処理できなくて、PDF1.3までの処理）

当然、PDFを処理するノウハウというのはもっているわけで、そのノウハウをAPPEに渡す前のPDFの処理(事前処理）に活かしているらしい。具体的には、問題のあるPDFを事前処理で書き換えちゃったりとかする。この問題を書き換える…という部分、聞き方によっては誤解されそうだけど、データのオブジェクトを修正するというようなものではなく、PDFの内部記述でトラブルになりやすい記述を、APPEに最適化した記述に置き換えるという事らしい。
他にもAPPEの組み込み方（スクリーニングや透過性向上のチューニング）で演算速度が変わってくるらしい。つまりうちはAPPEに渡す前と渡した後にバリバリにチューニングして最適化してまっせと。そこが他所さんとの違いでっせということでした。

あと、中間フォーマットについて。現状のTrueflowは処理後のファイルをOutlinePDFという独自フォーマットとして保存する。このOutlinePDFについて、他メーカー（ハイデル）のセミナーで「これからのAPPEでの処理では、独自フォーマットではだめです！」としきりに攻撃されていたのだけど、そのOutlinePDFについては「独自フォーマットといっても、内容は普通のPDF1.3準拠のPDFなんで、APPEでもちゃんと出力できます」とあっさり。

じゃ、気になるのはTrueflowのAPPEで処理したファイルはどうなるのか…？やっぱりOutlinePDFという中間ファイルに変換されるのか…？
この点について、セミナーでははっきりとは表明してなかったのだけど、APPE自体の処理はブラックボックスであるという事を考えると、OutlinePDFという独自フォーマットに変換されるとは考えにくい。そもそもOutlinePDFというものは、フォントがアウトラインされた（そのアウトライン処理をRIPでやっている）PDFというぐらいのもので、独自フォーマットといっても、それほど特殊なファイルではない。APPEではPDFがすべてフォント埋め込みされたものだという前提なので、OutlinePDFに変換する意味もあまりないかもしれない。

APPEそのものはPDF+JDFを処理(レンダリング)するだけの物だと考え、そこには手を入れる余地がないのだから、手を入れる余地のある（メーカーのノウハウや技を使う余地がある）部分は、PDF+JDFの部分になる。
事前処理（最適化）されたPDFと、そのPDFにつける（APPEに最適化された）JDFがいままでのOutlinePDFに代わるものになる…らしい。

今回のTrueflowSEでは、APPE対応ってとこばかりに目がいくけれども、実はもう一つ面白い機能がついている。
従来のエンジン部分についた、レンダリング切り替え機能。

TrueflowSEは従来のTrueflowエンジンとAPPEのデュアルエンジンだと書いたけど、実は、その従来のTrueflowエンジンの部分は1つではなく、複数のエンジンがのったらしい。
つまり、APPE（1）：従来のTrueflowエンジン（2）…って感じ。
なんで従来のエンジンが2つものっているのかというと…「互換性向上のため」

ここでいう「互換性」とは、APPEとはまったく関係なく、従来のTrueflowエンジンの互換性の事。

Trueflowを使っている人だとわかってもらえるのだけど、複数のTrueflow間でデータをやり取りするとき、その「互換性」がものすごく重要になる。
Trueflowには、細かいバージョンがたくさんあって、そこが違うと出力結果に違いがでてしまう。たとえば、バージョンアップでバグフィックスがあったとして、そのバージョンアップをする前のRIPとした後のRIPでは出力結果に「違い」がでる。バグフィックスなのだから、それまで間違っていた部分が正しくでるのはいいんじゃないの？と思われがちだけど、そうじゃない。
出力において、大事なのは初校、再校、下版、印刷と一貫して同じ結果が保てる事。初校の段階で間違っているものなら、印刷の時も間違った結果を再現しなければいけない。
なので、製版時と印刷時に別のTrueflowで処理をするような時はそれぞれのバージョンを合わせ、違いがでないように細心の注意を払う（そのためのTrueflowバージョン互換一覧表なんてのもある）

で、この複数のエンジンだけど、つまりその「バージョンの違うTrueflowで処理されたデータが来たときに、そのバージョンに合わせてレンダリング処理しましょう」って機能なのだ。
ただ、どんなバージョンでもいいという訳ではなく、処理できるのは現行バージョンと、一つ前のもの。でもそれだけでも、実際の業務上はかなり広い範囲がカパーできる。

APPEの方は、その性能を活かせるデータ出力はまだまだそうないけれども、こちらの互換性機能の方はすぐにでも現場で活躍しそう。