HTML, PDF


Table of Contents

1. HTML, PDF
原稿を印刷する
活版印刷
ワードプロセッサ
マークアップ
TeX, LaTeX
HTML
プリンタ用ページ記述言語
PDF
CSS, XSL-FO, SVG
HTML
スタイルシート
クライアント・サイド・スクリプティング
サーバ・サイド・スクリプティング
PDF
PostScript

Chapter 1. HTML, PDF

原稿を印刷する

活版印刷

メモやノート、手紙などのメッセージとして利用することを考えた文書は手書 きで書くのが今でも一般的ではあるが、書籍や雑誌、新聞等の配布を目的とし た文書は、歴史上でもかなり早くから印刷という方式が導入された。

ヨハネス・グーテンベルグ (johannes Gutenberg, 1398? - 1468?)が活版印刷 機を開発したのは、500年以上も昔である。活版印刷という技術自体はグー テンベルグ以前にも極東地域に存在したらしいが、単に技術を開発するだけで なく、実際に印刷装置を開発しかつ出版事業まで行い出版というビジネスモデ ルを一気に完成させてしまった功績は単なる学者には真似できないものである。

活版印刷という技術とビジネスの出現は、コンピュータやネットワークの出現 など線香花火にしか見えないくらい、情報というものを大きく爆発させたと考 えられる。少なくとも、それまでは、情報というのは口頭で伝えられるものだっ た。文字による文書として記録される政治上重要な命令(法律とか政令)ぐらい だった。

印刷は大きな印鑑を押すようなものです。とはいえ1ページ分の巨大な印を一 枚の板として作る(削る?鋳込む?)のは大変です。なので、印自体は文字単位 にあります。これを並べて組み締めることで1ページ分の印を作っています。

1文字分の印を「活字」と呼びます。印鑑と違うのは四角だということです。この 活字を横に並べる事で行が印刷されます。行は行ごとに印字をならべるガイド 枠に納められます。このガイド枠を立てに積むことで複数の行がならんだペー ジが組み上げられます。レイアウトすることを組版とも言います。

活字は沢山使いますので、サイズについては規格があります。その単位が「ポ イント」で完全に電子的なプリンタにおいてもポイントという単位は使われて います。1ポイントはおおよそ1/72インチです。

東洋では、漢字の大きさは一定であり、更には、正確に等間隔に並べて書くこ とが美しい文書であると考えられていますが、西洋では、文字は幅が一定でな いし、単語毎の区切りの空白があるし、更には、連字などもあるため、美しい 組版をするのは非常に複雑な作業になります。西洋でもタイプライターを使う と文字の幅と間隔が一定になってしまうので、タイプライターによって打たれ た文書は醜いものと認識され、手書きの代用としてしか見なされません。

昔ながらの出版においては、手書きやタイプライターで打たれた原稿が著者か ら出版社に渡されると、出版社の組版デザイナーは、1行の区切りかた、文字 のスタイル、余白、脚注のつきかたなどを原稿に赤ペンなどで書き込み、それ を植字工に渡す。植字工は原稿にかかれている、著者が書いた中身と組版デザ イナーが書いたスタイル指定をみながら、活字を並べてページを組版して原版 を作成しました。ですから、センスの良い組版デザイナーや技術の高い植字工 のいる出版社の本は美しくかつ読みやすいものとなりました。

ワードプロセッサ

ワードプロセッサは英語圏ではタイプライターの延長として普及しました。な ので、かなり早い時期からコンピュータとプリンタの組合せになりました。タ イプライターの代わりですから、文字飾りとか必要ではないですから、今でい う所のテキストエディタにプリント機能がついているという位のものです。と にかく、タイプライターと違って打ち間違えても紙を捨てなくて良いというの が一番のメリットというレベルです。

一方、日本語圏では活版印刷システムの簡易版として専用の機械をつかうもの として普及し始めました。昔はワープロが使えると言うのは専門技能のような ものとして考えられました。実際、資格がありますし、ワープロ打ち専任のOL さんがオフィスにはいました。それはそのはずです。組版デザイナーと植字 工がやるような仕事をしているわけですから。美しい文書を大変な時間をかけ て仕上げるというのが目的でした。

しかし、GUI パソコンとインクジェットやレーザーなどによる解像度の高いペー ジプリンタ(これに対するのがラインプリンタ)が登場するとその様相が変わり ました。英語圏でも高度な文字飾りが簡単に使えるようになり、日本語圏では 操作が簡単になった(本当に?)ので、殆んどの人が自分でワープロを打つよう になりました。

MS Word のような、画面表示上で直接レイアウトを編集できるようになった事 の功罪としては、文字にスタイル(飾り等)を与える事のパワーを人々が手に入 れたことで、その引き替えに文章自身の表現力を磨く事がなおざりになり、か つ、文書作成にかかる時間が結局は増えてしまったことでしょう。

マークアップ

ワードプロセッサをもたらした情報技術は一方で出版業界に対しても別の革新 をもたらしました。組版や植字が電子化しました。品質を重んじる出版におい ては、著者がワープロでレイアウトした原稿を作ってきても基本的には無視し、 テキストだけをとりだし、活版印刷時代と変わらない品質を得るため、専用の 組版プログラムを使っていました。組版プログラムでは、原稿のテキストと専 用の組版制御言語を混ぜたデータを作成し、組版の半自動化を行っていました。 組版制御言語とは、活版印刷時代に組版デザイナが原稿の空白等に書き込んで いたマークやコメント等を整理して計算機が理解できるようにしたものです。 このような書き込みをマークアップと呼びます(活版印刷時代からの呼びかた)。

出版物は何百ページもありますので、ワープロの様に文書を見ながらマウスで 操作していたら手間がかかって大変です。なので、組版プログラムでは原稿の テキストを論理的な構造(章立てとか)に合わせて自動的に組版します。

例えば章のタイトルは太字にしてページの先頭にくるわけですが、マークアッ プ言語では、その文が章のタイトルであることをマークします。組版プログラ ムはそれを読んでその本のスタイルに合わせて文字のサイズやページ区切りな どを調整します。改ページや文字サイズを指定するわけではありません。もち ろん、個々に指定したければ指定できますが、例えば、会社の方針でスタイル を変更するとなると、マークアップ済の原稿から修正しなければなりません。

マークアップ言語が各社のシステム毎に異なっていると、電子植字機を開発す る会社が困ってしまいます。また、組版デザイナも転職するとき別の言語を覚 えなくてはならず大変です。そこで、マークアップ言語の標準化が叫ばれまし た。IBM が使っていた GML (Generalized Markup Language) をベースに標準 化するというかたちで SGML (S は Standard)が出来ました。

TeX, LaTeX

計算機科学における偉大な先駆者のひとりであるスタンフォード大学の Donald E. Knuth (高徳納)教授は、計算機科学における最も重要な教科書の一 つである「The Art of Computer Programming」の執筆をしているとき、当時 の活版印刷の仕組みに憤りを覚えておられました。「数式が全然綺麗に組版し てもらえない。こんなことなら日本人に生まれれば良かった(Knuth先生は日本 の出版技術が世界最高であると思っておられたそうです。本当か?)」。

偉大な研究者というのはだれでもそうであるが、良い道具が手に入れられない 時には誰かに文句を言っても始まらないので、自分で作ってしまうものです。 Kunuth 先生は研究や教育の合間を縫って TeX というプログラムを一人で作っ てしまわれました。これは「テックス」と発音してはいけません。なぜなら、 これらの文字は数式で使われるギリシャ語として読むべきだからです。つまり τ・ε・χなのです。発音の曖昧な日本人には厳しいので「テック」と発音し てもよい様です。或は「テフ」とも言います。この場合の「フ」は普通に発音 するのではなく「ク」と「フ」の中間のように発音しなければなりません。

TeXは数式の記述や行組版等には高度な能力を持っていましたが、大規模な文 書を書くにはコマンドが基本的過ぎました。TeX にはマクロという機能があり、 そこでは関数定義や条件分岐等のプログラミング言語的な要素もありました。 Knuth先生は TeX 自体はシンプルにしておいて、ユーザがマクロを使って高度 な組版をすれば良いと考えたのだと思います。計算機学者らしい判断です。し かし、一般ユーザにとってマクロをプログラミングするのは容易ではありませ ん。

Leslie Lamport は整備されたTeX用のマクロ集を開発してLaTeXと名付けて配 布した。LaTeX が提供するマークアップコマンドは文書の構造を記述するよう になっており、例えば chapter, section, subsection, subsubsection のよ うなコマンドが用意されている。

HTML

CERN (European Organization for Nuclear Research、日本で言えば筑波の高 エネルギー研究所) の情報システム開発スタッフの一人であった Tim Bernards Lee は、研究者たちの為の新たな論文検索システムの必要性を痛感 していました。当時研究機関の間ではインターネットは整備されており電子メー ル(SMTP)やファイル転送(FTP)や簡単な情報検索(Gopher, WAIS)等が運用され ていました。しかし、電子メールやGopherで論文やデータの在処を問い合わせ、 FTP でダウンロードするというのは何とも手間がかかり面倒なものであるため、 なんとかならないかと考えていました。また、長い論文を画面で調べる時、目 次があっても、目的の節にたどり着くのは容易ではなかった。

この二つの問題を解決する方法としてハイパー・テキスト/ハイパー・メディ アという技術が注目されていた。Lee は既存の論文やデータをハイパー・テキ ストとしてリンクすることができないかと考えた。しかし、当時あったハイパー テキストシステムは専用のプログラムがなければ編集はおろか見ることすらで きず、当然、OS ごとに全く違ったプログラムが販売されており、ファイルの 形式にもなんら互換性が無かった。

そこで、Lee は Knuth 教授や Lamport 先生と同じく、新たなシステムの開発 に着手した。ポイントは、インターネットに対応し遠隔地の文書をダウンロー ドできること、既存の論文(少なくともプレーンなテキストファイル)をテキス トエディタで編集することでハイパーテキストの機能を付け加えられること。 この条件を満たすため、新たな通信プロトコルとして HTTP を開発し、一方、 SGML を基盤にした新しいマークアップ言語である HTML を開発した。これに 合わせて、サーバ(CERN httpd)とクライアントを開発した。実際には簡単なサー バと簡単なクライアントを作りながらプロトコルや言語を決めていったのだと 思うが。

HTML は既にあるプレーンテキストの論文に最小限の加工でハイパーテキスト の機能をつけることを目的としているので、文書の構造等の高度な概念は導入 していない。想像だが、本当は TeX/LaTeX をハイパーテキスト化したかった のではないかと思う。そうすれば既存の TeX/LaTeX で書かれた論文はすぐに ハイパーテキストになるし、組版も同時に自動で行われる。しかし、既に十分 に複雑になった TeX を改造するのは困難であるし、そもそも TeX のバージョ ンアップは Kunuth 教授しかやってはいけないことだった。だから、TeX を改 造してハイパーテキスト TeX を作るという方向には行けず、簡単なマークアッ プ言語をゼロからつくることにせざるを得なかったのではないだろうか。

HTML/HTTP の組合せである WWW はまたたく間に普及し、色々な人達が、ソフ トウェアを開発したり、HTTPやHTMLの仕様の改善をして、現在のような姿になっ た。

HTML の仕様決定の初期段階で、文字や文のスタイルを中途半端に指定するよ うなマークアップ言語にしてしまった事には相当な後悔があるらしく、WWW コ ンソーシアムは SemanticWeb,RDF による意味記述、XSL-FO, CSS によるスタ イル記述など、文書を、中身、意味、表現に分離して記述する方向に向かって いる。

プリンタ用ページ記述言語

ワードプロセッサが普及し、オフィスで作成される文書を出版所に出さずに高 性能なプリンタで済ますようになると、プリンタへの要求が高まることになり ました。特に沢山の種類のフォントやサイズの文字、図形、写真などが同じペー ジに複雑に配置される、というような複雑な印刷を行うためには、プリンタの ハードウェアとワープロやドライバのソフトウェアでどのように処理を分担す れば良いかというが重要な問題となります。ソフトウェアでドットまで計算す ると時間がかかりすぎ、かと言って、組版までプリンタのハードでやるとプリ ンタの中に LaTeX が走るようなコンピュータをいれなければならなくなる。

ちょうど良いバランスとして考えられたのが、1ページを画面と見立てて描画 コマンドをコンピュータからプリンタに送り込むというものです。ページの区 切りやページの中のレイアウトはソフトウェアで行い、描画コマンド列として 1ページ分のデータをつくる。これを画面に送ればプレビューができるし、プ リンタに出せば印刷できる、というわけです。これをページ記述言語(PDL)と 言います。

という事で各プリンタメーカはそれぞれ独自の PDL を決めました。日本では エプソンの ESC/P、キャノンの LIPS 等が知られています。しかし、なぜか、 プリンタメーカではないアドビ社が独自のページ記述言語とその言語のインタ プリタを発表しました。PostScript です。

プリンタのハードウェアは描画命令から微細なドットの濃度値を計算しなけれ ばなりません。これには高度なノウハウが要ります。単純なアルゴリズムでは 人間の目には不自然に見えてしまうからです。そのようなノウハウはプリンタ メーカは十分には持っていませんでした。ドットを小さくさえすれば綺麗に見 えるとしか考えていなかったからだと思います。アドビ社は DTP 用のソフト ウェアを作っていましたので、ドット密度の低いディスプレイに綺麗に表示す るためのノウハウを十分に蓄積していましたので、これを高解像度のプリンタ に適用すれば素晴らしい品質の印刷が可能になるわけです。アドビ社は特許や 知的財産権を駆使してノウハウを守りつつ、その技術をプリンタメーカにライ センスしました。今でも高級なプリンタはみな PostScript で動いていますし、 PostScript を解釈するインタプリタはアドビ社のライセンスのものです。

PDF

PostScript は非常に高機能なページ記述言語なのでパソコンにとっても処理 は軽くなく、そのインタプリタも巨大なソフトウェアになってしまいます。 HTML の普及は文書を画面で見ることを一般的なものとしましたが、HTML が中 途半端な仕様であるため、実際の見た目が環境により一定しないということに 皆不満を持っていました。そこで、Adobe 社は PostScript を簡易化した PDF (Portable Document Format)というデータ形式とそれを扱う Adobe Acrobat という製品をいうものを発表しました。PDF には、描画の制御に関するコマン ドを減らした分、ハイパーリンクとか署名とか HTML 的な機能が盛り込まれま した。

CSS, XSL-FO, SVG

初期の PDF に対する人々の期待と幻想はすさまじく、PDF は HTML を駆逐し てしまうのではないかとすら思われました。しかし、PDF の仕様は PostScript よりは軽いのですがそれでも十分に複雑なので、PDF を作るため にはアドビ社の製品を買わなければならない状態でした。そのため、PDF を見 ることは普及しましたが、PDF を作るのは一般にはそれほど普及しませんでし た。

PDF のような営利企業による規格は企業の判断によりどうにでもなってしまう ので、情報社会のインフラとしては不適切です。そのことを最もにがにがしく 思っていたのは WWW コンソーシアムの人たちで、そこで、対抗する規格とし て、HTML に対するスタイルの強化として CSS (Cascading Style Sheet)、XML については XSL-FO (Extensible Stylesheet Language - Formatting Objects)、また、強力なベクターグラフィックス言語として SVG を開発しま した。

HTML

HTML とその表示プログラムである Web ブラウザは短期間で爆発的な進歩をと げ、当初の用途/目的からは考えられないような所まできてしまいました。今 では、殆んどのアプリケーションを Web ブラウザの中で動かす事ができます。

もちろん、それには HTML だけでは無理で、JavaScript によるブラウザ上で のスクリプトの実行(クライアントサイドスクリプティング)、サーバ上での動 的なコンテンツの生成(ダイナミックコンテンツ、サーバーサイドスクリプティ ング)との組合せによって実現されています。

Java Applet や ActiveX、Plug-in 等を使った Web アプリケーションもあり ますが、これれは単にブラウザの窓の中で他のアプリケーションを走らせてい るだけです。Java Applet は別にして、実際には別のプロセスが動いているも のが大半です(Acrobat Reader 等)。そういうのは本質的には Web アプリケー ションとは言えません。HTML とクライアントサイドスクリプティング、サー バサイドスクリプティングの能力を引き出せば、よほど特殊なものでも無い限 りはそういう妙なやりかた不要です。むしろ素直にアプリケーションとした方 が妙な制約を受けなくてよいです。

今の Web サイトでは、スタイルシート、クライアント・サイド・スクリプティ ング、サーバ・サイドスクリプティングのどれも使っていない昔ながらの HTML のみのサイトはありません。これらの技術は Web サイト構築の必須とみ なされています。

スタイルシート

文書としての構造上、同じクラス(章タイトルとか項目の列挙とか)の文には同 じスタイルを与えたいものです。それに失敗して同じクラスの文なのに場所に よって違ったスタイルが与えられてしまうと、文章の構造を読む人に誤って伝 えてしまいます。スタイルと文書の構造の間の一貫性を維持したいわけです。

一方では、同じ文書でも印刷する場合と画面に表示する場合で、全く同じとい うのはよくありません。発光しドットピッチの荒いモニタと反射しドットピッ チが細かい(事実上連続している)紙面で同じようにレイアウトしたら読みにく くてかないません。かと言って、わざわざ別のファイルを作っていたら、内容 をちょっと変更するだけでも面倒です。

そこで、エレメント単位でスタイルを設定する方法が考えられました。重要な ポイントはスタイル指定の集合に名前をつけて、名前でスタイルを呼び出せる ようにしたことです。これで複数のエレメントに同じスタイルを確実に適用で きます。これが CSS (Cascading Style Sheets) です。

クライアント・サイド・スクリプティング

HTML には何か動作を指定する仕組みは殆んどありません。動作とは、何らか のイベントがあったらそれに従いエレメントに対して何らかの作用をするもの です。強いて言えば、ハイパーリンクをクリックしたらそのリンクのページに 移動することだけです。このハイパーリンクのジャンプだけでアプリケーショ ンを作ることもできなくはありません。特に最近は、クライアント・サイド・ スクリプティングを悪用した攻撃が増えて来たため、ブラウザでスクリプトを 動かさなくする人が出てきています。しかし、クライアント・サイド・スクリ プティング無しではページの動きはかなり制約されていまいます。

クライアント・サイド・スクリプティングでできるのは、

  • ページが開く時

  • イベントが起こった時

  • エレメントを作る(作り直す、壊す)

  • エレメントのスタイルを変える

  • エレメントのテキストを変える

ことです。本当にこれだけなら良かったのですが、実際には、これ以外に

  • 別のサーバに通信する

  • ローカルのファイルを読んだり書いたり消したりする

  • ローカルでプログラムを起動する

ことまでできてしまうのでセキュリティホールになっていまうわけです。

サーバ・サイド・スクリプティング

クライアント・サイド・スクリプティングよりサーバ・サイド・スクリプティ ングが先に生まれました。要するに CGI のことです。CGI を C 言語ではなく Perl を使って書くのが一般的になったのはかなり早く、Perl の文字列処理の 能力を見ればうなずけます。しかし、CGI の Perl スクリプトを書いている頃 は、それをサーバ・サイド・スクリプティングとは言われませんでした。

CGI 等では HTML は Perl スクリプトの中の文字列リテラルやデータベースの データで、それを print して作っていました。CGI を作るのはプログラマの 仕事でした。

これを大きく変えたのが Microsoft の ASP (Active Server Pages) です。 ASP では、HTML の中に特殊なエレメントを埋め込むと、そのエレメントの中 はクライアントには送られず、サーバ上で VBScript や JScript のスクリプ トとして解釈されるというものでした。ですから、取り合えず HTML を書いて、 データによって変動する所だけスクリプトを書けば良かったのです。或は、取 り合えず HTML エディタでダミーデータを乗せてデザインをして、後から、デー タの部分をスクリプトで変動させるようにすれば済みました。

少なくとも、CGI では、最初から Perl プログラマが書かなければなりません が、ASP なら普通の Web デザイナがページのテンプレートを作って、それか らプログラマに渡してデータが乗るようにすればすみました。結局の所、スク リプトを書く部分の手間は殆んど変わらないのですが、ちょっとした違いが素 人さんには簡単になったような気にさせることができたわけです。サーバ上で 使うスクリプトが Visual Basic Script だったというのも大きかったでしよ うし、なにより、サーバの OS が Windows なので、ターミナルでログインし て vi でスクリプトを編集する、なんてとても素人さんには想像できない世界 を味合わなくて済むことが大きかったと思います。

ASP のような HTML にスクリプトを埋め込むという手法自体は ASP 以前から Perl CGI ハッカーの間には知られていましたし、有る程度整備されたパッケー ジもありました(HTML::Template)。しかし、Perl ハッカーからみれば、それ を使うほうが面倒に見えるので普及しなかっただけでした。

しかし、何時までも CGI を Perl プログラマに書かせてはいられなくなりま した。なにより、ドット・コム(どっと込む)ビジネスというのが急に流行り出 して、猫も杓子も Web サイトをたて、ユーザ登録とか、オンライン・カタロ グとか言い出しました。とにかく、CGI プログラマが不足状態になってしまい ました。もう、プログラマをつれて来て「動く」 Web サイトを作らせている 暇がなくなってしまったわけです。

ASP の評判を聞いた人達も、だからといって Windows サーバを使う勇気はあ りませんでした。当時は Windows NT 4.0 の時代。また、大規模なサーバとし ての実績がありませんでした。なので、何とか Apache でも同じような事がで きないかということになりました。結果、沢山のシステムが作られました。言 語から新たに作ってしまったチーム(PHP) もありました。今では CGI はあま り使われなくなり、Apache でもサーバ・サイド・スクリプティングが主流に なりました。

PDF

PostScript

PostScript とはどんなものか? PostScript のマニュアルによれば、

  • 汎用のプログラミング言語に強力なグラフィックス命令が加えられたもの

  • ページ記述言語だけど、プログラミングもできる

  • ディスプレイとかプリンタ等のラスター出力装置を制御できるインタラクティブなシステム

  • データ交換形式

のいずれでもあるそうです。

実際、PostScript は Logo 系のスタック構文言語です。データ型も配列やハッ シュまでしっかりあります。制御構文として if や for もあります。関数の 定義もできます。exec によりコマンドも実行できます。ガベージコレクタも 制御できます。

a b gt {a} {b} ifelse

という PostScript のコードは、C 系の言語でいれば

if (a > b) {a} else {b} 

のような意味になります。

PostScript でのグラフィックスの基本は、Path という太さの無い線を引いて、 それに対して太さや色のあるペンでなぞる(Stroking)、或は、閉じた所を塗り つぶす(Filling)という考え方です。一番大事なことは文字もこの考えかたで 描かれるということです。

このような考え方が開発されたのは、PostScript が最初ではありませんが、 PostScript の普及により今日のグラフィックスの基本となったと言えます。 意外と大事なことだったかもしれないのは、700ページを超える詳しいリファ レンスマニュアルを$30と格安で販売したり、ポストスクリプトプリンタの マニュアルとして付属品として付けたりしたことかもしれません。とにかく、 このマニュアルはグラフィックスに関する非常に良い教科書です。

PostScript の仕様は非常に重いので、PostScript プリンタに搭載する CPU はいわゆるマイコン(8 - 16 ビット)ではだめで、ワークステーション級の CPU が必要でした。実際、1990年頃の話として、ワークステーションの CPU が CISC から RISC にやっと切り替わりつつあったころ、PostScript プリン タには 32-bit CISC CPU の最高傑作である MC68030 が搭載されていました。