現在、出力トラブルの原因の多くが、フォントの問題に起因している ように思います。また、フォントの体系はひじょうに複雑を極めており、 かなり専門知識を持った人でないと適切な設定をするのが難しいように思 います。
そこで、まず基礎知識として、特に印刷に関わるフォント体系の概要 について書いてみます。
われわれ研究者が普段論文や書類を書くとき、主に TrueType フォン ト、PostScript フォント、ビットマップフォントの三種類を使っていま す。
TrueType フォントは Windows や MacOS で主に使われているもので、 文字の外形の曲線情報を持っており(このようなフォントをアウトラ インフォントと呼びます)、このため、文字の品質を落とすことなく 任意の大きさに拡大・縮小することが可能(この特徴を持つフォントを スケーラブルフォントと言うことがあります)です。Windows で 標準で用意されている「MS明朝」「MSゴシック」、あるいは MacOS の 「細明朝体」「ゴシックBBB」がこれに該当します。最近の MacOS では、 システムフォントの「Osaka」もそうです。また、PC-UNIX でも、VFlib や freetype といった TrueType レンダリングライブラリが普及し、X window system 上でも TrueType フォントが使えるようになっていますね。
PostScript フォントも、TrueType フォントと同じくアウトラインフォ ントであり、任意の大きさに拡大・縮小することが可能です。PostScript フォントにはいくつかの種類がありますが、そのうちの一つにType1 フォントと呼ばれるものがあります(ほかにどんな種類があるのか、 どういう違いがあるのかは調べてません。いずれ調べて書きます)。 PostScript プリンタに標準的に搭載されている Times, Courier, Helvetica, Symbol といったフォントが Type1 フォントの例になります。 あるいは、UNIX や Windows で .pfa や .pfb などといった拡張子のつい たフォントがこれに相当します(.pfa はテキスト形式、.pfb はバイナリ 形式)。
この2つの規格が生まれた背景には歴史的事情もあるらしい(Adobe が PostScript フォントを発表したのに対抗して Apple が開発・提唱したの が TrueType だったような。嘘かもしれません)のですが、現状のユーザ の立場から言えば、次のような違いがあります。
むかし、私の周りで、「Mac からある文書を PostScript プリンタに 出力しようとすると、死ぬほど時間がかかる」なんてことがよくあった (やったのは私ではありません)のですが、原因は「文書内に Osaka フォ ント(TrueType)が使われている」であったことが多かったです。これは上 記の3つ目が原因ですね。
ビットマップフォントは、アウトラインフォントとは異なり、 外形情報を持っていません。イメージとしては、長方形を細かくメッシュ (升目)に区切り、一つ一つの升目を黒か白で塗り潰して文字を表現してい る、と思えばよいでしょう。
さて、LaTeX を使っている場合、ビットマップフォントを使っている ことがよくあります。LaTeX の母体である TeX では、ビットマップフォ ント、TeX font metric (TFM)という文字の外接長方形の情報、 メタフォントと呼ばれる文字の外形(アウトライン) 情報を使っ て、高度なフォント処理を行っているのです。
TeX のソースファイルをコンパイルすると dvi(Device Independent) 形式のファイルが生成されますが、ここには、TFM フォントをもとに文字 が配置されています。つまり、文字の外接長方形が並べられているだけで す。そして、xdvi や dvi2ps といったツール(dviwareと呼ばれ ます)が、TFM フォントを適切な(出力デバイスに最適な)ビットマップフォ ントに置き換えて、出力イメージを生成するわけです。
いま「出力デバイスに最適な」ビットマップフォント、と書きました が、これはどうやって生成するのでしょうか。そこにメタフォントが使わ れます。メタフォント処理ツール(mf など)は、プリンタエンジンの解像 度、最適な線の太さなどのデータベースファイルを持っており、これとメ タフォントから、出力デバイスごとにチューンアップしたビットマップフォ ントを生成することができる仕組みになっているのです。さすが、Knuth 先生が考えただけあって、緻密なシステム構成になっています。
ところで、日本語の場合漢字がありますので、扱う文字数が英語圏の 比ではありません。ですので、英語圏では大した大きさでないビットマッ プフォントも、日本語用のものはひじょうに大きなものになります。上記 のような枠組みを日本語にそのまま適用すると、dvi2ps などで吐き出さ れたファイルサイズは馬鹿でかくなります。昔はそうしていた(大日本印 刷が TeX 用ビットマップフォントを販売していた)のですが、データ量の 問題に加え、解像度ごとにフォント一式を購入しないといけないというよ うな事情から、多くの方の努力によって、日本語処理に関しては別の枠組 みが普及するようになりました。X のフォントや日本語 PostScript フォ ントを用いた「フォントの代用」です。
たとえば、VFlibを組み込んだ xdvi で TrueType フォントを用いて dvi ファイルをプレビューする場合を考えましょう。TrueType フォント に埋め込まれているフォントメトリック情報(外接長方形情報)を読み出し、 これと TFM を見比べてサイズの微調整を行います。そして、その微調整 情報を基に、TrueType フォントをレンダリングし、画面に紙面イメージ を表示するわけです。
dvi2ps などで PostScript ファイルに変換する場合も、流れは基本的 に同じです。今度は、プリンタに内蔵されている日本語 PostScript フォ ントのフォントメトリック情報(.afm という拡張子のついたファイルを使っ たりする)と TFM を見比べてサイズの微調整を行い、ビットマップフォン トを埋め込む代わりに、内蔵 PostScript フォントを使用するという命令 を埋め込んだ PostScript ファイルを生成します。これを PostScript プ リンタに送ってやると、内蔵フォントが使用されて、出力されるわけです。
ただし、この点は注意しておかねばならないのですが、「フォントの 代用」処理は通常日本語フォントについてのみ行われます。つまり、英語 フォントに関しては、(特にチューンアップをしていない限り)もともとの 「ビットマップフォントを埋め込む」という処理を行っているはずです。