PDF vs SGML の第２段階

AdobeのAcrobatのPDFへの関心が高い。しかしPostScriptがあらゆる用途の印刷物に使われるように、PostScriptを簡素化したPDFも特定目的のためにあるものではないので、いろいろ事例が出てくるとともに、議論が発散していくと思われる。CGもDTPも抽象的な技術の話をしているのは最初の段階だけである。PostScriptであってもPDFであっても、それ自身を問題にするのはもう終わってもよいと思う。

PDFはAdobeのさまざまな製品と密接に結びついており、2年強前に発表されたSupra（現Extreme）、1年前に発表されたPostScript3が、市場に根つくとともに、アプリケーション側もPDFに対応するようになるというのがAdobeのシナリオであったと思う。それにはまだ1年は猶予期間がある。

しかし昨年のAcrobat3.0以来、AcrobatよりもPDFへの取り組みが過熱しはじめ、PDFの中にあるRGB画像データをCMYK分解して網掛け出力するツールなどは、かなりヒットしたと思う。従来のDTPワークフローでは、QuarkXPressなどでPostScriptファイルとして吐き出してから、AcrobatのDistillerを使ってPDFにするという手順を踏まなければならなかった。ところがPageMakerなどAdobeのアプリケーションは直接PDFを吐き出すというのは、けしからんとか不公平だという意見が出てきた。

AdobeはPDFの仕様は公開しているが、Acrobatで読み書きするPDFがどのような処理をしているかについては、アプリケーション内部のことなので公開していない。要するに互換性の高いPDFを欲しがっている利用者は、Adobeとその競合相手のQuarkなどが協力して欲しいといった。Adobeはそれにのる方向にあるが、そうするとAcrobat製品群のようなアプリケーションはどこでも作れてしまうことになる。では、今までAdobeがAcrobatReaderをタダで配ってプロモーションしてきたことは何だったんだろうか。PDFによるAdobeのビジネスチャンスはどこにあるのだろうか？

実はAdobeは先の展開も用意していると思う。それはAcrobatCaptureというすばらしいアプリケーションがあるからだ。これは既存の紙のドキュメントをOCRで読み取ると同時に、レイアウトも再現してPDFファイルにしてしまうものである。膨大な過去の紙のドキュメントの電子化に役立つ道具であるが、PDFというのは1ページ単位のものなので、長文の文書はそのままでは扱えない。

ところがAdobeはFrameMakerというSGMLツールももっていて、長文の加工分野もこれから進出しようとしている。かつてPDFとSGMLは対極にあるかのようにいわれたが、SGML化で最初にぶつかる壁である紙の文書の問題にはAcrobatCaptureが使えると、お互いが補完しあうものに変わりつつある。DTPでIllustratorやPhotoshopをコアにしてさまざまなプラグインが開発されたように、FrameMakerをコアのアプリケーションとして、第3者が文書を扱うツールを多く出すようになるのかもしれない。

(テキスト&グラフィックス研究会会報69号より）

(C)Japan Association of Graphic Arts Technology