今回は、OpenType フォント（TrueType フォントを含む*1）を LaTeX + dvipdfmx で使えるようにする手順を、その原理の説明を含めて解説することにする。インストール対象のフォントとして、「M+ P Type-1 ファミリ」を用いる。
- 例によって、「欧文フォントのインストールについて」の資料（以後「例の資料」と呼ぶ）を参考にする。
- dvipdfmx を使う場合は最終的な目標物が PDF 文書である*2ことがかなり多いと思われる。この場合、dviout を用いる場合と異なり、ビットマップへのレンダリングが行われると、PDF 文書に埋め込まれたフォントがビットマップになってしまい甚だ都合が悪い。上手くいったように見える場合、PDF 表示を拡大してアウトラインが埋め込まれているかを確認することを勧める。
- 以前に説明した通り、実フォントが OpenType フォントである場合には updmap を使った「一括設定」ができない。だから各ソフトウェア毎に個別に設定する必要がある。（今回は dvipdfmx のみを扱う。）
- ここで説明するものとは全く別の方法として、「OpenType フォントを一旦 Type1 フォントに変換して、あとは Type1 用の設定方法を用いる」というものがある。この方法の利点は「updmap を使うことができる」ということである。欠点は、「ライセンス上の制約で実行できない場合がある」ということである。
手順の概略
今回述べる「dvipdfmx に対する設定」を dviout や updmap に対するそれと比べると、対象のソフトウェアが異なるので色々な作業の手順に違いが出る。しかし重要なことは、作業の全体的な流れは変わることがないということである。
- TFM ファイル（.tfm）とその付随ファイル（.enc/.vf）の生成。
- 各ソフトウェア用のマップファイルの作成。
- 各ファイルの配置。
- LaTeX レベルの支援ファイルの作成・配置。
例の資料での事例と比較して、特に注意すべき点を挙げる。
- 1. について： 実ファイルが OpenType だから、otftotfm を使うことになる。（「M+ P Type-1」は「TrueType フォント」なので、ttf2tfm も使用可能であるが、otftotfm の方が高機能である。）
- 2. について： この場合、「レンダラ」に相当するのは dvipdfmx 自身である。*3従って、dvipdfmx 用のマップファイルを作成する必要がある。
- 3. について： dvipdfmx の設定ファイルとマップファイルの場所について知る必要がある。
- 4. は「TeX 以上のレベル」の話なので、実フォントや「レンダラ」の種類には全く依存しない。
- 今回は LY1 エンコーディングを用いることにする。TFM の命名は「ZR 命名規則（謎）」に従う。NFSS や TFM 名でのファミリの名前は mplus1p とする。
今回の作業対象となるフォントの情報を以下にまとめる。*4
| フォント名 | ファイル名 | TFM 名 | NFSS 指定 |
|---|---|---|---|
| M+ 1p thin | mplus-1p-thin.ttf | mplus1p-a-ly1 | LY1/mplus1p/el/n |
| M+ 1p light | mplus-1p-light.ttf | mplus1p-l-ly1 | LY1/mplus1p/l/n |
| M+ 1p regular | mplus-1p-regular.ttf | mplus1p-r-ly1 | LY1/mplus1p/m/n |
| M+ 1p medium | mplus-1p-medium.ttf | mplus1p-m-ly1 | LY1/mplus1p/sb/n |
| M+ 1p bold | mplus-1p-bold.ttf | mplus1p-b-ly1 | LY1/mplus1p/b/n |
| M+ 1p heavy | mplus-1p-heavy.ttf | mplus1p-h-ly1 | LY1/mplus1p/eb/n |
| M+ 1p black | mplus-1p-black.ttf | mplus1p-c-ly1 | LY1/mplus1p/ub/n |
以下の作業はかなり多くのファイルを扱うので、専用の作業ディレクトリを作ってそこで行うことを推奨する。
TFM（+ 付随）ファイルを生成する
M+ フォントのダウンロードページからアーカイブを入手し、上掲の表に載っているファイルを作業ディレクトリに配置する。*5全部で 7 個のフォントについて作業することになるが、作業内容はほとんど同じなので、以下では「M+ 1p regular」についてのみ手順を示す。他のフォントについては、上の表を参照して必要な部分を読み替えるだけである。*6
それでは、実際に otftotfm で TFM ファイルを生成することにする。以下のコマンドを実行する。
otftotfm --no-type1 --no-dotlessj -f kern -f liga -e texnansi.enc -n mplus1p-r-ly1 mplus-1p-regular.ttf
各オプションと引数の意味は以下の通り。
--no-type1 --no-dotlessj： これは「Type1 フォントへの変換を行わない」ということ。((現状の otftotfm は TrueType グリフのフォントについては Type1 フォントへの変換はサポートされていないから、実際にはこのオプションは指定不要ではある。--no-dotlessjについてもう少し詳しく話すと：otftotfm には文字 dotlessj (U+0237) のグリフを文字 j のグリフを改変して（Type1 形式で）生成する機能を有している（やはり TyueType グリフのフォントには未対応）が、このオプションはその機能を抑止する。要するに、グリフデータの変換は不用意にやってほしくないのである。))-f kern -f liga： OpenType 特性の kern と liga を有効にする。つまりカーニングとリガチャの情報を TFM に含める。*7-e texnansi.enc： エンコーディングファイルの指定。厳密にいうと「基底の」エンコーディングの指定である。-n mplus1p-r-ly1： TFM 名の指定。mplus-1p-regular.ttf： フォントファイルの指定。
これを実行すると、次のファイルが生成される。
- mplus-1p-ly1.tfm： 目的の TFM ファイル。
- mplus-1p-ly1.vf： 生成された mplus-1p-ly1 は仮想フォント（VF）として実現されているので、.tfm とともに .vf ファイルが存在する。
- mplus-1p-ly1--base.tfm： 仮想の mplus-1p-ly1 が参照している TFM。レンダラ／DVI ウェアでマップを設定する対象はこちらの TFM になる。((「
vftovp mplus-1p-ly1 mplus-1p-ly1 mplus-1p-ly1」で mplus-1p-ly1.vpl を出力し、その中の MAPFONT 要素を見れば、実際に mplus-1p-ly1--base が参照されていることが確認できる。)) - a_6si6az.enc： 「既定の」エンコーディングをカスタムして生成されたエンコーディングファイル。*8
ちなみに、例の資料にあるように「--mapfile=foo.map」のオプションを付けて実行すると、以下の内容の foo.map が生成されるはずである。*9
mplus1p-r-ly1--base mplus-1p-regular "AutoEnc_6si6azkxsy3cpk3ogugnfii5wf ReEncodeFont" <[a_6si6az.encこれは pdfTeX 用のマップファイルである((Type1 への変換が有効な場合は、dvips／updmap でも使える内容になる。))から、このままでは dvipdfmx では使えないが、これを見ると以下のことが判る：DVI ウェアのマップファイルで設定すべき内容は、「mplus1p-r-ly1--base」という TFM を「a_6si6az.enc」のエンコーディングで実のフォントファイル（mplus-1p-regular.ttf）にマップすることである。((
AutoEnc_...が気になる人は a_6si6az.enc の中を眺めてみよう。この文字列はこのファイルで定義された「エンコーディングデータ」の識別子である。ファイル名を指定しているのに何故わざわざ識別子が要るのかを理解するには Postscript の知識が必要である。後で見るように dvipdfmx ではこの識別子をマップファイルに書く必要がない。))*1:規格の定義上は「TrueType フォントは全て OpenType フォントである」が成立すると考えている。現在では多くの場合、「TrueType フォント」は「TrueType グリフ（glyf テーブル）をもつ OpenType フォント」のことを指す。ただし「TrueType フォント」と「OpenType フォント」が区別して扱われている場合に、どういう基準で区別するかは人によって異なることがあり、これが混乱を招くことがある。
*2:つまり、「印刷された紙」でないということ。紙に印刷するのなら、ビットマップフォントが埋め込まれてもあまり問題はない。
*3:ただし、dvipdfmx はフォントファイルに含まれるアウトライン（輪郭曲線）データをそのまま PDF 文書に含ませていて、ビットマップイメージを生成するという意味の「レンダリング」は行っていない。
*4:TFM 名の「シェープ」部分については、ウェイトを表す「thin」「light」…の語を Berry 規則に従って変換したものである。NFSS のシリーズの決定については後述する。
*5:別の場所にこのフォントがあるならシンボリックリンクでも構わない。
*6:取り敢えず 1 つのフォントについて作業して成功したことを確認してから他のフォントの作業をするといいかも知れない。
*7:これは実用ではほぼ必須になる。ちなみに、clig、sups、ss01 等の他の特性を有効化することもできる。
*8:ファイル名は自動生成なので、環境によりこれと異なるかも知れない。
*9:foo,map が既に存在する場合は末尾に追記される。オプションを付けない場合はこの内容が画面に出力されているはずである。
