ちくちく日記

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

大日本スクリーン　トレンドセミナー2010

セミナー Trueflow 出力 PDF 電子書籍


スクリーンのトレンドセミナー2010。
スクリーンのセッション

インクジェットデジタル印刷の現状と今後

まず、インクジェットデジタル印刷についての紹介ということで、スクリーンの開発しているインクジェットプリプレスシステムの紹介。

印刷ビジネスの現状、広告費減で広告媒体が印刷からWebなどに移行しているといった現状の話から、今年は電子書籍元年でますます紙が減る事が予想される、先頃開催されたCEATEC JAPANでも目に見えて紙カタログが少なかったという話など。

8月に東京でおこなわれたスクリーンのプライベートショーでは、インクジェットプリプレスシステムを中心に近未来の印刷（バリアブル＆オンデマンド）を展示。会場の映像を交えながら説明。

TruePress J-SXはフルカラーで高品質な全面バリアブル印刷が可能な印刷システム。UVインキとかでパッケージ印刷もできます。後加工機と連動して、バリアブ＆オンデマンドで製本など…という映像紹介。

スクリーンさんはインクジェット印刷機を売りたくて仕方ないようでしたが、個人的にはインクジェット印刷機のバリアブル印刷というのをどんな仕事に活かせるのか、いまいち使い道がわからない。
バリアブルで大量の印刷物ができるということで、すぐに思いつくのは新聞のような報道系なんだけど、あそこは既に従来の印刷で同じ事ができる仕組みをもってるだろうしな…。金券などのバリアブルもすでに、既存の設備で実現できてるし…。

いっそ紙への印刷にはこだわらず、もっと違うものに印刷したりした方が何か面白い使い道があるかもしれない。例えば食品に印刷するとか。食べられるインクつかって、食べられる印刷とかで。インクジェットなんだから、通常の印刷とちがって、インクを変えたら色々できそうなんだけど。





「今そこにある未来」は本当にやってくる？-PDFワークフローからバリアブル印刷、電子書籍の実情-

次にスクリーンの技術セミナー。
トレンドセミナーでは出力の手引きの中の人が、技術解説をしてくれるのがお約束。
ただ、今回のセミナーでは、新しい技術の解説というより、いままでのセミナーの総まとめ＋電子書籍に関するスクリーンの立場の説明といった内容だった。
以前のセミナーで聞いた話も多かったので、そのときの説明も引用してレポートする。

全てのAdobe PDF Print Engineで

まずはTrueflowの話から。
2010年12月末でTrueflowのサポートが一部変更される。
従来演算処理（APPEではない、従来の演算部分）について一部サポート終了。
終了する部分はAdobeとの共同開発の部分のみ、主に入力処理に関わる部分。

サポート終了とは、今後この部分のついては新たなパッチは作成しませんの意味。従来演算ルートも使えないわけではない、ただ、この部分に不具合が生じても今後修正されない。ただしこの部分は技術的には枯れた部分なので、あまり問題にはならないだろうとの事。


スクリーンとしては、今後従来の演算処理部分のサポートについては力を押さえて、これに変わる最新演算のサポートに注力していく。

2010年7月にTrueflow3ver4がサポート終了。
これで現在有効なTrueflowはAPPE搭載のTrueflowSE以降の機種のみとなる。

スクリーンとしては、すべての（今従来演算処理で行っているものも含めた）業務をAPPEでの（最新演算）処理に移行して欲しいと思っているが、それで大丈夫なのか？

１）同じ事ができるのか？

最新、及び従来のDTPアプリケーションのサポートについては、スクリーンは出力検証用の評価キットを用いて評価を行っている。（これはいままで起きたトラブルなどのデータをまとめてテストできるようにしてるもの）

さらにGenius Kitとして、以前Adobe CS3の新機能の評価で評価漏れ（効果の処理についてのトラブルチェック漏れ）があった反省から、Adobe の協力の元、新機能を使ったデータをテストキットに入れる様にしている。

なので、過去のデータとともに、新しい機能のデータについても出力には問題ない。安心してAPPEを使って欲しい。

気になるPSの処理について、従来演算処理から新しい演算処理に移行するということは、PSファイルの処理もAPPEでかけるということになる、その点は大丈夫か？
まず、PS処理のサポートについて、Trueflow7.1以降、APPEでもPSを処理できるようになった。従来演算と同じレベルで最新演算処理でPSを処理できるようにするため、かなりの検証をおこなった。なのでPSを最新演算処理にかけても大丈夫だと保証できる。

ただ、やはりおすすめはPDFワークフローへの移行。PDF/X4を使う方がおすすめ。

2）出力結果は（従来演算と）同じになるのか？

従来演算処理と、最新演算処理で、出力結果は一致するのか？これについては残念ながら、一部違う部分がある。

それはオーバープリントの処理の違い。
オーバープリントの処理というのはPS時代は厳密に規定されていない部分があり、それがPDFでは厳密化された。
そのため、CS以降のアプリケーションと、それ（InDesign2、Illustrator10）以前では、オーバープリントの挙動が違っている。

具体的には、DeviceCMYKのグラデーション、パターン、画像のオブジェクトにオーバープリントをかけた場合。

これらのオブジェクトに対するオーバープリントは、PDFの規格では処理してはいけない＝ノセにならない
が、PostScriptの規格では、これは厳密に規定されていなかったので、RIPによって（ノセになったりならなかったり）結果が違うものがあった。
が、PSを最新演算処理（APPE）で処理するようになると、PSもPDFの（厳密な）規格にそって処理されるので、この部分はノセにならないという処理になる。

くわしくはこの辺読むとわかる。
http://www.screen.co.jp/ga_dtp/dtp/guideline13/20100113appe_op1.html

正直、この問題で実際のトラブルとなる事はほぼないと思われる。こんな重箱のスミ的な「結果が違う事がある」なんて、わざわざ説明しなくても、問題にならないレベル。
ただ、「こういう問題がある可能性がある」から説明するのだそうだ。真面目だな…スクリーン…。


OutlinePDFとOutlinePDF-Advについて


TrueFlow7.0ではAPPEでOutllinePDFも処理可能
すべての処理を APPEで行うことが可能。

さらに、TrueflowのOutlinePDFといえば、ものすっごいこまかい互換表というのが、Trueflowユーザーにはおなじみだった。
これ、つまりTrueflowのバージョンが違うことで、処理結果に違いがでてしまう場合があるので、OutlinePDFデータをやり取りするときには、この互換表と首っ引きで「そのTrueflowで出力して大丈夫かどうか」を調べてたわけだ。

その互換表、Outline-Advでは必要ないらしい。
Trueflow7.2以降では、互換表ですべて二重丸（互換性OK）になるように開発しているので、互換表は必要ありませんとの事。


Adobe PDF Print Engineについて


TrueflowSEでは、演算エンジンにAdobe PDF Print Engineを採用している。
同じAdobe PDF Print Engineを採用しているなら、どのRIPも出力結果は同じになるか？
もちろん、おなじPDFをおなじJDFでおなじAdobe PDF Print Engineに食わせれば、出力結果は同じになる。
ただし、RIPは総合力である。つまり、Adobe PDF Print Engineが同じでも、その周辺、Adobe PDF Print Engineに渡す前の最適化、ここに違いがでる。
TrueflowはAPPEに渡す前の入力処理において、問題のあるPDFの最適化を行っている。

さらに、スクリーンは「出力の手引き」「出力の手引きWeb」で出力についての情報を提供し、「Trueflow印刷ユーティリティー」という、出力用プリセットファイルなども提供している。このことで、データ制作者がより正しいデータを作る手助けとなり、より正しいPDFが入稿されることになる。

Adobe PDF Print Engineへの関わりについても、スクリーンからAdobeへのレポート件数は世界のベンダーの中でトップレベル
単にレポートが多いという話ではなく、レポートをしているということは、それだけ多くの（不具合について、その修正について）情報を得ているという事。つまり修正された箇所がどのように使われているかがわかるという事。

さらに最新ビルドについて、スクリーンはAdobe PDF Print Engineの新バージョンについてもちろん検証しているが、それをすぐに実機に搭載するわけではない。
ベンダーによっては「最新ビルド搭載！」とそれを謳うメーカーもあるが、最新だからいいというわけではない。
スクリーンは検証したのち、常にベストなバージョンを提供するようにしている。

このようにAdobe PDF Print Engine採用といってもスクリーンでは、他ベンダーより最適のRIPを提供している。
どこでも同じというわけではない。

3）今ままでの不具合はどうなるのか？

過去にDTPアプリケーションで発生した不具合について、Trueflowではアプリケーションの不具合もRIP側で対応するようにしてきた。
その辺の情報はこの辺http://www.screen.co.jp/ga_dtp/dtp/guideline14/20100727_7problems.html　にのってる。



インクジェット　バリアブル印刷システム
EQUIOUについて


EQUIOUではAdobe PDF Print Engine 2を採用
インクジェット印刷機に最適化
PDF/VTをサポート予定

PDF/VTってのは、バリアブル印刷用のPDFの規格
VT = Variable Transactionalで、可変印刷を効率よく行うためのフォーマットである。

PDF/VTについては2009年のセミナーでも説明されてた。
さすがに同じ説明を書くのはきついので、2009年のセミナーレポートから引用

PDF/VTとは、バリアブル印刷用の国際規格

VTは「Variable Transactional」の略

バリアブル印刷とは、印刷物の一部が変更されつつ印刷する印刷のこと。

バリアブル印刷に利用するデータには、再利用される（繰り返し印刷される）オブジェクトと可変（差し替えられる）のオブジェクトが存在する。オブジェクトを差し替えつつ印刷する、ということは、通常より高速なRIP処理が求められるという事。

つまり、1万パターンの差し替え印刷があったとして、それを1万パターン全部1からRIPしてたら時間がかかってしょうがないから、いかに高速にRIPできるか、再利用するオブジェクトと、1回きりのオブジェクトとをうまく処理する為の規格です。



PDF/VTはISO 16612-1 (PPML/VDX)を元に制定されている。

ISO 16612-1 はPDFを基本として作られた規格なのだけど、ツール対応がいまいちで、あまり普及しなかったし、透明にも対応してなかった。

その反省を基に、新たに制定されたのがISO 16612-2のPDF/VT。


さて、そのPDF/VTの特徴。

まず、どのようにして効率の良いバリアブル印刷に対応しているのか。

PDFにはXObjectという概念がある。

XObjectとは外部オブジェクトという考え方。

PDF内で使われる部品を分割して記述してある。

PDF/VTではそのXObjectを有効につかって高速化に役立てようとしている。


XObjectには3種類ある

・Image XObject　画像専用のXObject

・Form XObject　画像以外の通常のオブジェクトの記述

・PostScript XObject　これはもう使われていないオブジェクトなので気にしなくていい。

んで、XObject=外部オブジェクト概念なのだけど、つまり、いままでのPDFだとPDFの中のオブジェクトを表示するのに、普通はコンテンツをひとつひとつ全部なめて表示していた。んで、これをXObjectでやると、オブジェクトは画像と画像以外に分けられて、それぞれXObjectとして記述し、それにたいしてDo~って感じで「これを表示しなさい」って命令するだけで表示することができる。

つまり繰り返しでてくるオブジェクトを何回も何回もなめ直さなくていいってことかな。だから効率がいい。

さらにPDF/VTでは外部オブジェクトの参照が許可されている。

参照XObject（Reference XObject）っていって、これはPDF/X-5から許可されている。

（PDFの構造としてはPDF/X-5以前からあったものだけど、PDF/X-4までの規格では許可されてなかった）

外部オブジェクトの参照は、印刷関係の人ならOPIみたいなものだと思えば理解しやすい。つまり、フォームの中から、外部のPDFファイルをファイル名によって参照して読み込むことができる。

外部オブジェクトの参照はAcrobatでは9からサポートされている。

ファイル名による参照のみ、つまりパスではないので、参照させる場所を設定する必要がある。Acrobat9では環境設定→ページ表示→参照XObject表示モードというのがその設定になる。

XObjectは、PDF/VTのみではなく、既存のPDF内でも普通につかわれているらしく、トラブル事例紹介で紹介された、合成フォントの例の文字の透明効果の処理においても、1文字ずつで背景画像をクリップする部分の背景画像の繰り返し処理などに利用されてるそう


PDF/VTの特徴、もう一つ。

階層構造のDPartによる、ページ選択、順序変更。

従来のPDFではページ順による印刷しかなかったがPDF/VTでは、属性順（たとえば、郵便番号、氏名、住所などのキーによるソート）での印刷指定が可能。

これは、DPartという階層構造の属性データベースをPDF内部に持たせる事で、ソートが可能になっている。

引用ここまで

で、なぜそこまで高速演算が必要なのかというと、バリアブルでは、複数ページを毎ページ毎ページ演算しなければならないので、高速でないと処理できない。

APPEではキャッシュをサポートしていて、一度演算したらキャッシュにためてそれを読んでくれるんだけど、スクリーンのシステムではさらにプリンタ側で、キャッシュを持つ、だから早い。

つまり、PDF/VTの演算時に、データが解析され、データ内のオブジェクトの、どれが大きいか？どのオブジェクトが繰り返し使われているか？を優先順位をつけて演算し、キャッシュに蓄積する。
2P目以降の出力では、キャッシュにないものだけを演算する、という処理になる。だから早い。
さらに、繰り返し使われていないもの、それほど大きいサイズでないものといったキャッシュにためないものもそれはそれで、別の工夫をして出力しているのだそうな



電子書籍について



昨今の電子書籍ブームで、各社いろんな取り組みを発表してるけど、さてスクリーンはどうするのか…？

→詳しくは言えません。

なにそれっ。でも詳しくは言えないといいつつ、最後にちょろっとそれっぽい話もあった。


で、なんの話をしたかというと、いま、騒がれている電子書籍について、出版印刷（書籍、雑誌）のジャンルと、商業印刷（カタログ、チラシ）のジャンルにわけて、今騒がれている電子書籍は、出版印刷部門であり、多くの（特に地方の）印刷会社で扱っている商業印刷ではないという話。

チラシ、カタログといった商業印刷の分野はすでにWebという形で電子化されており、もうとっくに電子化の脅威にさらされている。いまさら騒ぐものではない。

電子書籍ビジネスはまだまだ成功例を模索中である。

話題になっている電子書籍についても、京極夏彦「死ねばいいのに」岩崎夏海「もしどら」といった、ほんの数冊のベストセラーをのぞけばまったく売れていない。売れた2冊についても、純粋に電子書籍としての売り上げというより、電子書籍というものの調査目的で売れた部分も大きい。

あまり電子書籍だと大騒ぎせず、おちついて対応したほうがよい。

電子メディアはプル型のメディアであり、デバイスを必要とする。すべての人がデバイスをもっているわけではない。
対して、従来の紙メディアはプッシュ型であり、電子メディアにはないメリットもある。

どこまでが電子書籍にふくまれるか？

現在「電子書籍」として販売されているもの、今後「電子書籍」として販売されるもの、どこまでを「電子書籍」と考えるか…？
たとえば、App Storeで販売されている、天体観測アプリ「Star Walk」http://itunes.apple.com/jp/app/id295430577?mt=8　これなんかも広義では「電子書籍」といえる。
単に「雑誌」「書籍」の電子化というだけでなく、こういったコンテンツ開発まで考えていくべきではないか？


とはいいつつ、やっぱり、それでも今求められる「電子書籍」への対応が必要な場面もあるので、
スクリーンとしてはデジタルリンクコンセプトという取り組みをしていく。

現時点では電子出版を「紙を出すときにおまけとして、電子書籍をつける」という需要もかなりあり、さらにそれはサービス的に扱われる事が多いので、そこにあまり金も寝間もかけられない。

なので、印刷用データを電子書籍データに流用できるように、
RIPに出せば印刷物と電子メディアの両方ができる、紙コンテンツと電子コンテンツ両者の垣根を取り除く取り組みをしていく。
さらに新しい電子メディアの模索、プロトタイプの試作なども行っている。ご期待ください。


と、いうことで、スクリーンのトレンドセミナー、技術セッションはこんな感じだったのでした。

印刷、出力についての内容はいままでのセミナーのまとめですね。
1時間のセッションだったので、内容はかなり駆け足。私は以前に聞いた事ある内容だからなんとかついていけたけど、初めて聞く人にとってはちょっと厳しかったのでは。

電子書籍の部分に関しては、スクリーンも電子書籍にどう取り組んでいくべきか、対応に苦慮しているという印象をうけました。
ただ、今年、電子書籍元年と大騒ぎになっている電子書籍ですが、実際ビジネスモデルとしてはまだまだどうなるかわからない、というのはそうだなぁと。

あと、どこまでを「電子書籍」と考えるのか？という話。
電子書籍の話をすると、かならず音楽や動画をつけたり、インタラクティブなコンテンツが紹介されるのだけど、これがどんどんどんどん進化していくと、それが「電子書籍」なのだろうか？という感じてしまう。
たとえば、むかし「ゲームブック」っていうのがあった。小説なんだけど、細かい段落にわけてあって、読む人が次の行動を選択することによって、読む段落がかわって、結末が変わる。
あれを電子書籍でやったら、もっと面白いだろうなと思う。メディアの特性が活かしやすいし、音楽とか映像をつけたりして…と考えていくと、あれ？それって普通に　RPGゲームじゃね？ってなってしまう。別にゲームならゲームでそれでいいんだけど、それなら最初から電子書籍じゃなくてゲームアプリを作ってるんだよな…。

一ユーザーの立場として考えると、私が欲しい電子書籍って、とりあえず、今ある雑誌、小説などの内容がそのまま見られればそれでいいんだよね…。電子書籍だからって過剰なオプションを付ける必要はなくって、それより安くして欲しい。
今、本屋さんでうってる書籍、雑誌が安く、簡単に手元のデバイスで見れたらいいな。と、いうのが大抵の一般人の感覚じゃないだろうか。
あ、あと辞書、学術書とかそういうのが電子化して、検索機能がつくとかいうのはいいよね。そういう、必要な機能としてつくのはわかる。そういう「既存の書籍より電子書籍の方がメリットがある」ものは、多少高くなってもしょうがないよね。

なんだか最近の、電子書籍デバイス、フォマーットの乱立状態を見ていると、ほんとにこの混沌状態から、電子書籍の将来が生まれてくるのだろうかと、先の見えない感があるよなぁ…