PDF元年を取り巻く状況 ④

表現のポータビリティ

原稿をテキストのみのファイルで出版社に入稿するときも、見出しとリード、本文、脚注などの区別が必要です。そこで、原稿を渡す人と受け取る人の間で取り決めをして、注釈のようなものをテキストに入れることもあります。

［見出し］
○×○×○×○×○×○×

［リード］
○×○×○×○×○、×○×○×。○×○×○×、○×○×○×○×○×？

［本文］
○×○×、○×○○×、○×○×。○×○×○×○、×○×○×○×……

［脚注］
○×○×○×○、×○×○×○×。○×○○×○×、○×○×○×○×………

実は、これと同じような考え方に立脚している文書記述の標準があります。それが、SGML（Standard Generalized Markup Language）です。SGMLは、国際規格（ISO 8879）と日本工業規格（JIS X 4151）に採用されている汎用マークアップ言語で、文書の構造を保ちながら電子的に論文や技術マニュアルなどをやり取りするために利用されています。

SGMLは、「タグ」をテキストに埋め込むことによってタイトルや著者名、章、節などを区別し、文書の構造を示しています。SGMLのタグは、出版社への入稿に際して著者がテキストの中に入れる注釈と同じようなものと考えることができます。SGMLのタグの定義はDTD（Document Type Definition＝文書型定義）と呼ばれる形式で柔軟に決めることができます。DTDの内容は、別のファイルで提供されることもありますが、前書き（prolog）の部分に置かれることが多いようです。これは、出版社への入稿にたとえれば、著者が注釈の意味を書いたメモを原稿に添付したり、原稿の冒頭に直接書いておくようなものと考えるとわかりやすいかもしれません。

つまり、SGMLとは、出版社と著者の間の取り決めのように、作成者が意図した文書構造を相手が理解するための約束ごとであり、ある意味で作成者の“表現”でもあるオリジナルの文章構造を、その約束ごとにしたがって再現できる仕組みなわけです。

このことから、内容のポータビリティしか保てないテキストのみの情報伝達と異なり、SGMLは文章の“構造”という表現のポータビリティも実現しているようにも思えます。しかし、そう結論づけるのは早計です。SGMLには馴染みがないという人が多いかもしれないので、もっと身近な題材で表現のポータビリティを考えてみましょう。次に取り上げるのは、WWWページを記述する言語であるHTMLです。

HTMLのポータビリティ

実は、HTML（HyperText Markup Language）はSGMLから派生したひとつの応用例で、やはり文書構造を示すマークアップ言語です。インターネット上で目にするグラフィックやアニメーションを駆使した格好いいWWWページも、HTMLの決まりに従ったタグを本文に埋め込んだテキストファイルに過ぎません。SGMLと同様に、HTMLでも見出しや本文などの文書構造をタグで指定します。JPEGやGIFファイル形式の画像、さらに音声や動画などは、別ファイルとして外部に置かれています。単なるテキストファイルであるHTMLファイル自体は、タグによってこうした外部ファイルの保存場所を指定しているだけです。そのタグの指定をブラウザと呼ばれる閲覧ソフトウェアが解釈して、画像や動画が表示・再生されるわけです。

HTMLファイルを作成するのに特別なアプリケーションは不要です。テキスト形式のファイルで文書を保存できる簡単なエディタさえあれば十分。極端な話、ワープロ専用機でも携帯端末であってもかまいません。つまり、WWWページの作成はプラットフォームにもアプリケーションにも依存していないことになります。実際、MacintoshのSimpleTextや Windowsのメモ帳のように、コンピュータを買うと初めから付属してくるエディタを使ってWWWページを作っている人もいます。同じように、WWWページを見る側の環境も、プラットフォームやアプリケーションには依存していません。必要なのは何らかの方法でインターネットに接続できることと、ブラウザが使えること、それだけです。ブラウザとして一般的なのはNetscape NavigatorとInternet Explorerですが、両方ともOSにバンドルされるなど、ほとんど無料で配布されている状態です。したがって、実質的に誰でも持っていると考えて差し支えないでしょう。また、帯域の狭い（容量が小さく、伝送速度が遅い）電話回線にモデムを繋いでアクセスしても大丈夫なことからわかるように、画像を含めたWWWページ全体のデータサイズも小さく収まっています。

HTMLは、文章の構造化だけでなく、その名前の示す通り「ハイパーテキスト」も実現しています。ハイパーテキスト（hypertext）とは、1960 年代にテッド・ネルソン氏が電子メディアの利点を活かした新しい情報の記述方式として提唱した概念です。ハイパーテキストは情報を直線的に構造化する代わりに、関連した情報をリンクして思考の流れの赴くままに情報の道筋を辿れるような構造を作り上げます。上手に作成された WWWページを見れば、ハイパーテキストを実際に体験することができます。ひとつの単語やフレーズがそれと関連した情報、より詳しい説明、図版やアニメーションなどにリンクされていて、必要に応じて参照できるようになっていますよね？　これがハイパーテキストです。

HTMLはプラットフォームにもアプリケーションにも依存しないうえ、データサイズも小さい。また、SGMLよりもはるかに一般的であり、またハイパーテキスト機能を含むより豊かな表現を可能にしている。そうなると、HTMLは、電子メディアにおけるポータブルドキュメントに必要な条件をすべて満たしているようにも思えます。では、HTMLこそ電子メディアのための真のポータブルドキュメントということになるのでしょうか？

情報の発信者の意図

HTMLとSGMLの他にも、さまざまなマークアップ言語があります（たとえば、写植の書式を制御しているのも一種のマークアップ言語です）。マークアップ言語としてのSGMLとHTMLの特徴は“記述型”だということです。これに対して、他の多くのマークアップ言語は“手続き型”であるといわれています。記述型のマークアップ言語のタグが指示するのは「ここから見出しが始まる」だとか「脚注はここで終わり」という程度です。それをどう処理するのかはアプリケーションまかせ。その結果、柔軟性が飛躍的に高まることになります。一方、手続き型のマークアップ言語では、その見出しや脚注をどのように表示・印字するのか（たとえば使うフォントや文字サイズ、行の長さ、行送りなど）といった処理の詳細までが明確に指示されます。これは、特定の出力装置などへの依存度を高めかねない反面、オリジナルの表現がより忠実に伝達されることを意味しています。

具体的な処理をアプリケーションにまかせることによって柔軟性を高めるというのがSGMLとHTMLの特長であること。それを、情報の発信者と受信者の関係という切り口から捉えてみると、ひとつの重要な問題が浮彫りになってきます。それは、情報の発信者の意図がどこまで反映されるのかという問題です。

HTMLでWWWページを作成するとき、デザイナーは特に大きな戸惑いを憶えることが多いようです。それは、どれだけきっちりとデザインしても、それをそのままの形で情報の受信者に届けることが難しいという、これまでなかった経験を強いられるからです。

テキストに関して、記述型のマークアップ言語であるHTMLのタグで制御できるのは相対的な見出しのレベルや文字のサイズなど、非常に曖昧な指定でしかありません。フォントやベースとなる文字の大きさなどはブラウザ（つまり情報の受信者）まかせになります。ページを表示するウインドウの縦横の大きさも相手次第。ひとつの行に何文字入って表示されるのかも特定できません。また、MacintoshなのかWindowsなのか、さらにブラウザがNetscape NavigatorなのかInternet Explorerなのか、といった環境の違いにもある程度左右されます。したがって、完璧なデザインクオリティのWWWページに仕上げたつもりでも、情報の受信者の画面上に表示されたとき、一挙にそれが破綻してしまうことも有り得るわけです。せっかくの自信作も、見る人によってはロクでもないページだと評価されてしまうのではないかという恐怖で、ついには不眠症になってしまうデザイナーが急増しているとか、いないとか。

HTMLでの情報伝達においては、情報の発信者と受信者の関係が曖昧なこと。それが原因で、情報の発信者の側が苦労する状況になっていると考えることができます。つまり、従来なら情報の発信者が行っていたことの一部が受信者側に移ってしまった、ということです。電子メディアにおける情報交換が、表現を含めた一切合財のやり取りになるべきだとすれば、情報の発信者の意図が受信者へそのまま届くかどうかということも、電子メディアにおけるポータブルドキュメントに必要なひとつの条件ということになるでしょう。

表現の多様性と自由

新聞や雑誌などの紙メディアの代表のような出版物であっても、最終的に情報が紙に転写（印刷）されるまでの制作工程を電子メディアが担うようになってきています。この章の冒頭で、読売新聞の速報がPDF化されてWWWページに掲載されたという話を紹介しました。これも出版物の制作工程が電子化されているということを示す具体的な例です。

電子的でない配信を前提にして作成されている出版物から電子的な配信が可能な出版物を派生させる。そうした需要が、今後増え続けることは間違いないでしょう。この傾向に呼応するかのように、PageMakerや QuarkXPressなどのページレイアウトソフトウェアにもHTMLの書き出し機能が付加されてきています。

こうした機能を使えば、印刷物として完成しているDTPの文書からでも簡単にHTMLファイルを作成できるように錯覚してしまいがちです。しかし、実際に使ってみると、ほとんど役に立たないケースが多いというのが現状です。たとえば、印刷物にすることを前提にして作成されているPageMakerの書類をそのままHTMLファイルに書き出してみると、悲惨な結果になります。それを手直ししてWWWページを作成するよりも、テキストやグラフィックの素材だけを流用して初めからHTMLで作り直した方が簡単で時間も短く、ストレスも少ない仕事になります。

これは、HTMLが文書の構造化を基本的な概念にしていることを考えれば当然のことなのかもしれません。初めから印刷物とHTMLの両方で配信することを前提に、学術論文や技術マニュアルなどの本質的にきっちりとした構造を持つドキュメントを作成する。そうすれば、ページレイアウトソフトウェアからのHTMLファイルの書き出しもある程度スムーズに運ぶでしょう。現に、HTMLの書き出し機能について最も高い評価を得ているページレイアウトソフトウェアは、論文や技術マニュアルの作成に広く利用されているAdobe FrameMakerです。その理由は、FrameMakerがそもそも、文書を構造化して処理するというアプローチで開発されているからでしょう。

FrameMakerのHTMLの書き出しは“構造化文書→構造化文書”という変換だと考えることができます。しかし、そのようなドキュメントは出版物全体から見れば小さな割合でしかありません。大多数のドキュメントは自由自在に表現（デザイン）されている“非構造化文書”です。どう考えても“非構造化文書→構造化（しかし表面的には非構造化に見える）文書”というような変換がうまくいくようになるとは思えません。

確かに、同じ内容のドキュメントをHTMLで作成し直すことは可能です。手間と時間をかける気になれば。しかし、新聞や雑誌などの縦組みの記事は、すべて画像にしてしまわないかぎり、紙面のイメージをそのままHTMLで再現することは不可能です。これはつまり、HTMLには許容される表現という厳然たる枠組みが存在しており、HTMLでの情報交換はその枠組みからは逸脱できないということを意味しています。

やはり、この表現のしかたでなければ駄目というような足枷をはめることなく、多種多様な表現方法をすべて許容するような情報伝達の仕組みが必要でしょう。そして、印刷物などの既存のメディアから電子的な配信が可能な派生物を自由に、そして簡単に作成することができるかどうか。それが、電子メディアにおけるポータブルドキュメントに必要なもうひとつの条件ではないでしょうか。