AdobeInDesignが誕生した背景には、PostScriptベースのDTPワークフローにおける整合性の悪さのへの解決があっただろう。PostScriptは高品質のイメージを最も柔軟に記述できる方法としての評価はあったものの、その再現はRIPやフォントなど出力環境に依存するので、DTPが標榜した「オープンシステム」とは矛盾をきたしていた。
典型的にはイメージセッタに指定のフォントがないなどの日常的なトラブルがあった。これに対しては、PDFなど必要なデータを完全に内包して、どこでも再現できるようなフォーマットが第一の解決で、それはもうあまり問題ではなくなった。
次に出力の段階に不適切なデータが来てしまう点については、事前にプレフライトチェックのようなデータの検証をするということで防ごうとしているが、もっと根本的にはPostScript／PDFの出力が保証できるような、ノーマライズされたデータを最初から作る仕組みが必要になる。
AdobeはillustratorやPhotoshopにおいては出力可能なファイルを作るように努力できるが、他社開発のページレイアウトソフトに関してはなかなかコントロールできないので、正しいPostScript／PDF生成のエンジンとして見本を提供しようとしたのがInDesignではなかったのだろうか。
これはちょうどAppleLaserWriter以来ずっとRIPのコアを提供してきたことと同じようなことだし、PDFの再生もAdobeがほぼ一元的に提供していることと符合する。InDesign発表当時はPageMakerもFrameMakerも将来はなくしてしまって、後者はInDesignにSGMX/XMLの処理の別ソフトを組み合わせれて代替できるような話があった。
InDesignの最初は、組版やプレフライトなどコアな機能は高度なものをもっていたものの、DTPの編集に関するスペックは索引機能もなく、InDesign単体だけで使うことは想定していないようでもあった。ところが後にPageMakerもFrameMakerも新バージョンが発表されるなど、AdobeがInDesign一点に集中してDTPマーケットに攻勢をかけるという印象は薄れてしまった。
これはInDesignを正しいPostScript／PDF生成のエンジンとして使おうとするアプリケーション開発者が想定したより少なかったからである。InDesignのまわりにいろいろな目的指向のソフトが揃ってなければ、DTPユーザに採用されないのは自明である。
ではなぜこのような誤算が起きたのだろうか。これはPostScript自身にもいえることで、かつてCMSもPostScript言語でアプリを作ればRIPで処理できるとAdobeはいったが、そのようなことをする人はいなかった。Adobe社内にはスタンフォードでオブジェクト指向を勉強した優秀なエンジニアがいるとか、世界からそういうエンジニアがAdobeに集まってくるとかしても、Adobeの外にはそういう人は少ないのである。Adobeの考えは正しい方向だろうが、その方向に進みだすには時間がかかる。
テキスト＆グラフィックス研究会会報 Text&Graphics 181号より
2002/04/23 00:00:00