SUBMENU

はじめに

少なくとも通常にComputerModernフォントを用いているとき、たとえば数字部分には古いスタイルの数字（cmmi10に含まれている。$\mit 1998$と入力しても得られる）を用い、小文字部分にはSmallCaps（cmcsc10に含まれる）を用いるような文書を作成することは、極めて厄介な問題です。また、市販の商用フォントを用いること、あるいはComputer Modernがもつアクセント付けの限界を除去することもまた厄介な問題です。

これらはすべて、根源的には同じ問題から生じています。

まず、これらの問題についてほんの少しばかりの考察を行ってみましょう。まず第一の問題、すなわち複数のフォントを組み合わせて一つのフォントを生成する問題についてです。これについては、METAFONTを用いて新しいフォントを生成しなおすことがまずもっとも単純な解決策です。この方法の大きな問題点はまず、世の中には数多くのMETAFONT以外で生成されたフォントが存在するということです。すなわち、第二の問題点についていきなり解決不可能ということです。

次に第二の問題について考えてみましょう。一般にTeXがもつフォントのエンコードは、その他のシステムが持っているフォントのエンコードとは大きく異なります。DVIファイルはこのフォントのエンコードに依存してしまいます。他のフォントを用いることは極めて困難ですが、大きな問題点は、エンコードの違いによって生じます。

第三の問題点であるフォント作成機構の限界は、アクセント付きの字形を含むフォントを用意していた場合には特に合字を用いることによって解決されるべき問題でしょう。しかしながら、それを無闇矢鱈とtfmファイルを細工することによって実現することもまた現実的ではないでしょう。

さて、これらを踏まえたうえで、解決策がいろいろと考え出されました。

中でも、1983年、Stanford大学のDavid FuchsによってDVI-to-APSの変換ソフトウェアのために実装された方法は、優れた方法でした。しかしながら、これは一般的なソフトウェアではありませんでしたから、KnuthはFuchsのアイディアをTeXに組み込むべく検討をはじめました。その結果、上記の問題点を解決するうえでなすべきことは、実は、フォントに含まれる文字に関して、TeXの記法を他の出力機器の能力に合わせて変換するための方法を提供するだけであることがわかりました。このための方法は、1989年8月のTUG会合において、AMSの講演者により、「仮想フォント（Virtual Font）」と呼ばれました。

KnuthはFuchsの方法を検討し、

を実現しました。このファイルフォーマットは、VFと呼ばれています。

Virtual Font概説

Virtual Fontは、一言で言ってしまえば、「エンコードの異なるフォントを用いるときに生じる問題を解決する」ための方法です。ここでいう「エンコード」とは、文字コードを実際の字形に対応させる方法のことをいいます。より正確に言えば、Virtual Fontはフォントエンコードを交換する方法を提供するのであって、フォントそのものをエンコードしなおすのではありません。これに関しては注意が必要です。Virtual Fontはあくまでもそれぞれのフォントにおいて、数値化された文字コードを扱うのであって、文字名を参照するのではありません。したがって、基本エンコードに存在しない文字が、エンコード変換によってアクセス可能になることは決してありません。具体的に言えば、アクセント付きの文字を持たないフォントのエンコードをVirtual Fontを用いて変換しても、アクセント付きでデザインされたフォントを使用することは決してできません。

Virtual Fontを用いると、複数のフォントを合成したり、文字を合成したりすることができます。さらに、DVIファイルに記述できる命令であれば、罫線であれ、\specialであれ、何であっても変換することができます。Virtual Fontとはある意味で、DVIファイルに埋めこまれたDVIファイルのようなものであると言ってしまってもよいでしょう。この機構を用いることによって、本来利用不可能であったグリフを他の利用可能なグリフで置き換えることが可能となります。

ここで、TeXの話に少し戻りましょう。どんな話でもそうですが、複雑なことがあって理解不能に陥ったなら、それは自分が難しく考えすぎていることが原因です。話をできる限り単純に捉えれば、遠からず理解できるでしょう。ただし、簡単に、単純に考えるということは、おおざっぱな説明で自分自身をごまかしてむりやり納得するということではありません。しかしながら、微に入り細を穿つ議論までを追う必要もありません。単純に順序良く考えれば良いだけです。まず、TeXが組み版時に参照するのは、tfmファイルのみです。それ以外のファイルが読み込まれることは、TeXのマクロファイルや原稿ファイルを除いてはありません。したがって、Virtual Fontを用いるときであっても、tfmファイルを参照することには変わりありません。組み版時に調整を行わせることは、単純にソフトウェアを複雑化するだけです。さて、当然ながら、その結果出来上がるDVIファイルはVirtual Fontが使われているのかどうかという情報を一切持っていません。ここで、TeXの仕事は終わりです。さて、ここから後はDVIドライバの仕事です。DVIドライバはDVIファイルの中に並んでいるDVI命令に従って実際の表示を行います。DVIファイルの中にはcmr10のような名前で、フォントの名前が記述されていることでしょう。この名前は、TeXが組み版時に利用したtfmファイルの名前です。DVIドライバは、そのDVIドライバに対して適切に設定された順序に従って実際のグリフファイルを探すことになります。通常、Virtual Fontをサポートするドライバでは、VFファイルを検索できるようにしておきます。今仮に、DVIファイルの中にptmr8rというフォント名が記述されていたとしましょう。DVIドライバはその時点で、設定に従ってフォントを探します。その結果、たとえばptmr8r.300pkが実際に見つかったなら、そのフォントをPKフォントだと認識してそれを探すでしょう。また、DVIOUTの場合であれば、ptmr8r.tfmファイルを見つければ、［WinJFont］の設定を読み取り、TrueTypeフォントで表示を行おうとするでしょう。そしてもしも今、ptmr8r.vfファイルが見つかったなら---それこそがVirtual Fontです。DVIドライバはptmr8r.vfの内容を読み取り、Virtual Font命令を解釈しなければなりません。前節の最後でKnuthが達成しようとした実装の理由はもはや明らかです。

このようにして、Virtual Fontを用いるためには、tfmファイル、vfファイルの二つのファイルが必要となることが明らかとなります。したがって、これらのファイルを用意しなければなりません。一般に、tfmファイルはPL（Property List）ファイルから生成されます（METAFONTでフォントを生成する場合にはMETAFONTソースファイルから生成します）。PLファイルに馴染みのない人のために蛇足ながら説明を加えれば、PLファイルには、カーニング情報、合字情報、文字幅などTeXが組み版上必要となるフォントの情報がすべて記されています。しかしながら、Virtual Fontの場合には、PLファイルを拡張したVPL（Virtual Property List）ファイルを用意します。これは、PLファイルの上位互換のファイル形式で、テキストファイルです。ただ、PLファイルの場合と異なるのは、VPLファイルの中には、DVIドライバが実際にグリフを出力するための情報を記述しなければならないということです。通常PLファイルを用意してTFMファイルを生成するときというのは、そのフォントがMETAFONTソースファイルから生成されたものではないものの、DVIドライバがそれを理解できるというときです。たとえば日本語用のフォントであるmin10.tfmファイルなどはPLファイルから生成されます。それに対して、拡張PL形式としてのVPLファイルの中では、実際にどのフォントのどの文字コードのグリフを使って出力するものであるのか、あるいは罫線命令、\special命令などを用いるかという情報を記述することができます。この情報はVPLの中のshapeで与えます。無理に言い切ってしまえば、Virtual Fontとは、その対応が記されただけのものであるともいえます。

このメカニズムにより、あるVPLのなかで例えば数字部分のグリフにはcmmi10を用いるように記述され、小文字アルファベット部分にはcmcsc10を用いるように記述されているとすると、そのVirtual Fontは、これら二つのフォントを合成したフォントを表わしています。また、全く別のフォントを指しているかもしれず、さらに合字機能によりアクセント付きの文字が簡単に出力できるように細工されているかもしれません。この単純な階層を生めこむ手法により、TeXが抱えているとされた問題点が一気に解決されるわけです。

さて、Virtual Fontを利用したければ、VPLファイルを準備せねばならないということはわかったと思います。しかしながら、VPLファイルからTFMファイルやVFファイルを生成しなければなりません。PLファイルからTFMファイルを生成するときにはPLtoTFというプログラムを用いました。また、TFMファイルからPLファイルを生成するには（自分で既存の二つのフォントを合成して一つのフォントを生成するためにはPLファイルを得ることは重要でしょう）TFtoPLというプログラムを用いました。VPLの場合にこれらに対応するプログラムはそれぞれVPtoVFおよびVFtoVPです。VPtoVFを用いるとVPLファイルからVFファイルおよびTFMファイルが生成されます。また逆にVFtoVPを用いるとVFファイルおよびTFMファイルからVPLファイルを生成することができます。既存のVFファイルを編集して微調整を行うことも簡単です。

さて、最後にKnuthも重要と考えたVirtual Fontの利用方法について説明しておきましょう。この方法は、GhostscriptによってPKフォントを生成することもできる現在ではあまり重要度は高くなくなってきたかもしれません。しかしながら、すべてのシステムでその方法が利用可能であるわけでは決してありません。その方法とはつまり、たとえば、あなたがいま原稿を準備しているとします。また、その最後のフィルムはPostScriptのフォトタイプセッターによって出力することがわかっており、編集部の伝統により、Adobeのフォントを利用することが伝えられているとします。すなわち、RomanフォントとしてはComputer Modern Romanではなく、Times Romanフォントを、Sans SerifフォントとしてはComputer Modern Sans SerifではなくHelveticaフォントを利用するというのが約束でTeXで原稿を用意することを許可されたとします。あなたは、最後にdvipsで変換して、それらを利用できることを知っていたとします。しかしながら、自宅でHelveticaを利用することができなかったら、困ってしまいます。

そのようなとき、たとえば自宅ではプレビューもせず、原稿ファイルだけを用意してすべて編集部の責任であとは任せるのも一計。たとえば筆者自身はあの長大なシリーズを書いている最中は原稿を一度も自分で処理しないし、プレビューもしたことがありません（しかも記述された命令はかなりいいかげんで、書いてある部分にしても山のようなエラーが出るそうです。）。しかしながらこれは単なる筆者のサボりです。残念ながら、一般にTeXを使って原稿を準備する人が、完全にTeXについて信用し、TeXに関して100%任せても大丈夫といえる編集者に出会える確率は極めて低いといわざるをえません。そこで、そういう解決策はほとんどの場合採用することができないでしょう。また、一般論としてそのような編集者に出会っても、編集者を泣かせることになるので推奨しません。一般には筆者たるあなたが、編集者の指示に従ってすべてのマークアップを行い、出力の確認もしなければならないのです。つまり、あなたは、自分では画面表示もプリントアウトもできないフォントを用いて、正しく組んでしまわなければならないのです。

話を単純にするために、Helveticaフォントの利用を指示されたとしましょう。あなたは、字形が似ているからという理由で、cmss10を用いることはできません。なぜなら、cmss10はHelveticaとは異なるフォント配置を持つので、cmss10でうまく組まれた文書をHelveticaに（何らかの手段で）無理矢理変換しらとしたら、出てきた出力は見るも無残なものとなるでしょう。しかしながらあなたは、TeXで使えるフォントとしてHelveticaに似ているものはcmss10しか持っていないので、プレビューにはcmss10を用いたいのです。（プレビューがやや汚いのと、最終出力が見るも無残なのとどちらかの選択は、事実上選択肢が一つしかありません。）

さて、これを実現する手法について、解決策を考えましょう。あなたはHelveticaのTFMファイルやVFファイルを持っています。持っていなければCTANから取ってきます。このフォントを用いてDVIファイルを生成し、dvipsで変換すれば、あなたは目的のPSファイルを得ることができます。しかしながら、プレビューのとき、DVIドライバはHelvetica用のフォント名（phvr8rなど）を探し、プレビューできないのです。ここが問題。これを解決するもっとも単純な技がVirtual Fontなのです。Helveticaフォント用のVFファイルとTFMファイルから、VPLファイルを生成します。名前は何だってよいので、helvtrue.vplとでもしておきましょう。さて、このファイルをエディタで開きます。そうしたら、このファイルには実際に使うフォント名が書かれているので（たとえばphvr8r）、そこをcmss10に書き換えます。そうして、たとえばhelvdummy.vplという名前で保存します。VPtoVFを使ってtfmファイルとvfファイルを生成します。注意してください。helvdummyのフォントメトリックはHelveticaのままです。ただ表示に使われるフォント名が置き換わっただけです。（本当はマッピングも変えたほうがいいかもしれませんが。）このhelvdummy.tfmファイルを利用して文書を作成し、プレビューを行って内容を確認します。最後にhelvdummyをhelvtrueに置き換えてコンパイルします。フォントのメトリックは不変なので、出来上がったDVIファイルで文字の場所がずれたりすることはありません。ところが不思議なことに、表示に使うべきフォントだけがcmss10からHelveticaに置き換わっているのです。

最後に蛇足。Helveticaはphvr8rだと述べましたが、これはあるフォント命名規則にしたがって名づけれられたものです。dvipsはこのようなフォントを見つけると、psfonts.mapファイル（あるいはその他の指定されたファイル）を読み取ります。そうすると、

phvr8r   Helvetica   "TeXBase1Encoding ReEncodeFont"    < 8r.enc
という行が見つかります。ここで、「Helvetica」という名前に変換しているのです。Helveticaの場合にはエンコード変換があるので、ごちゃごちゃしていますが、和文フォントのような場合だと
rml Ryumin-Light-H
のように単純になっています。なお、rml.tfmはPSフォント用のTFMファイルです。min10などのフォントは、Virtual Font（min10.vf）を通ってrmlにマップされ、dvipsはrmlというフォントを探します。そしてpsfonts.mapファイルでRyumin-Light-Hという名前を埋めこむだけでよいということが記述されています（従って、dvipsでmin10.pkを作成しようとしたら、間違いなく、Virtual Fontの設定ミスです）。このRyumin-Light-HがPSファイルの中に実際に記されるフォント名です。リュウミンやHelveticaのようなAdobe標準フォントの場合は名前を埋めこむだけで良いのですが、
rsfs10 rsfs10 < rsfs10.pfb
のようにすると、rsfs10.pfbというType1フォントが実際にPSファイルの中に埋めこまれます。この例はrsfs10というフォント名を見つけた場合のdvipsの動作です。なお、このリストにフォント名がなかった場合、dvipsはPKフォントをPSファイルに埋めこみます。

以上に説明してきたことから、Virtual Fontの概要がつかめたと思います。これ以上の詳細はVPtoVF.webやVFtoVP.webファイルを参照されることを推奨します。また、明らかになったように、「Virtual Fontとはアウトライン形式のフォントを用いるための方策である」という理解は誤りです。しかしながらそのような用途が主であることもまた事実です。