(前回の続き)
各 TFM 生成ツールにおける SFD ファイルの扱い
これまでの説明は ttf2tfm を用いる場合についてのものであり、次のようにコマンドを起動するのであった。
ttf2tfm mplus-1p-regular.ttf mplus1ps-r-@Samp0TeXStd@
Type1 フォント(afm2tfm 等)は Unicode のエンコーディングを持たないのでそもそも SFD ファイルの対象にならない。従って、残りは otftotfm ということになる。実は otftotfm は SFD ファイルを利用した TFM 生成には対応しておらず、必ず .enc ファイルを用いる必要がある。なので、結局この節では何も書くことがないということになる。
OpenType/CFF で SFD ファイルをどう扱うか
ところがそれで終わっては困ることがある。ttf2tfm は TrueType フォントにしか対応していない。だから OpenType/CFF フォントに対して SFD ファイルでエンコーディングを指定して TFM を生成する手段がないことになる。
しかしこれはそれほど大きな問題ではない。既に何度か触れたように、SFD ファイルは「手段の一つ」でしかない。だから、「本来の」サブフォントを扱う場合であっても、多少面倒ではあるが、.enc ファイルを用意してそれで対応すれば大概の場合は対応できる。
ただし、それでは済まない場合がある。SFD ファイルの話を始めたそもそもの動機は、「日本語 OpenType フォント + dvipdfmx + .enc ファイル」で不具合が起こることであった。だから「前 2 つ + 欧文 TFM」の組み合わせが望まれる場合はどうしても SFD ファイルを用いる必要がある。ところが、ここでも「TFM 生成ツールと DVI ウェアは互いに依存しない」という性質を用いれば解決できる。すなわち、TFM 生成の時には .enc ファイル + otftotfm を用いた上で、dvipdfmx の設定は SFD ファイルを用いるのである。ただし、otftotfm は与えられたエンコーディングを「変換」する機能があるので、よく気をつけないと .enc ファイルと SFD ファイルの内容が一致しないことになる。
・ .enc を SFD の方に合わせる方法
例えば、Unicode.sfd 中の
u4e 0x4E00_0x4EFF
の行に対応する TFM を生成したいとする。この場合、以前に触れたように、
/gen-u4e [ /uni4E00 /uni4E01 /uni4E02 …… /uni4EFF ] def
というファイル gen-u4e.enc を作成する。そして以下のように、--no-virtual
を付して otftotfm を実行する。
otftotfm --no-type1 --no-dotlessj --no-virtual -e gen-u4e.enc -n mplus1ps-r-u4e mplus-1p-regular.ttf
注意すべきこととして、この時に liga 等のリガチャを有効化させてはいけない(つまり -f liga
を付けない)。*1((なお、ここで --literal-encoding
を使うと、グリフ名が本当に /uni????
である場合にしか対応できないので不適切である。))これで生成される mplus1ps-r-u4e.tfm をフォント「mplus1ps-r-u@Unicode@」の一員として用いればよい。
・ SFD を .enc の方に合わせる方法
普通に .enc でエンコーディングを定義するという手順をとり、dvipdfmx のマップ設定のときだけ、(otftotfm による)修正済の .enc と同等な SFD ファイルを後で作るという方法である。この方法は、かなり面倒であり、かつ SFD がフォントに依存してしまうことになるが、前の方法よりもトラブルが起こりにくい。
SFD ファイル SomeEnc.sfd とフォント mplus-1p-regular.ttf から「修正済の SFD」である mplus1pSomeEnc.sfd を作成して dvipdfmx でサブフォント mplus1ps-r-@mplus1pSomeEnc@(これは本来作りたい mplus1ps-r-@SomeEnc@ と同等)を設定する手順を示すことにする。
- SomeEnc.sfd の各行に対して、以下の手順を行う。以下の説明では、その行の識別子を xyz であるとする。(その行に対応する TFM は mplus1ps-r-xyz となる。)
- xyz の行に対応する .enc ファイル SomeEnc-xyz.enc を作成する。.enc の代替として SFD を使おうとしていた場合は、元の .enc を使えばよい。
- その .enc を指定して otftotfm を起動する。
otftotfm --no-type1 --no-dotlessj -f kern -f liga -e SomeEnc-xyz.enc -n mplus1ps-r-xyz.tfm mplus-1p-regular.ttf
これで修正済みのエンコーディング a_??????.enc と TFM ファイル mplus1ps-r-xyz.tfm が出力される。この mplus1ps-r-xyz が VF になった場合は、mplus1ps-r-xyz.vf と mplus1ps-r-xyz--base.tfm も出力される。以下、VF である場合を仮定して説明するが、そうでない場合は説明の「mplus1ps-r-xyz--base」を「mplus1ps-r-xyz」で置き換える。 - エンコーディング a_??????.enc の中に記されたグリフ名を対応する Unicode 符号位置に変換して、SFD の行の記述「
xyz 〈符号位置範囲〉
」を作成する。 - その行を mplus1pSomeEnc.sfd に追記する。
- その上で、dvipdfmx で次のマップ設定を行う。
mplus1p-r-@mplus1pSomeEnc@ unicode mplus-1p-regular.ttf
ここで甚だ厄介なのは「グリフ名を Unicode 符号位置に変換する」ところである。otftotfm 自身は glyphlist.txt や texglyphlist.txt を参照してこの処理を行っているので、恐らくこれらを参照すれば見つかると思われる。最大の問題は「Unicode のマップを持たないグリフ」である。リガチャを有効にしていると、こういうグリフが自動挿入されることがある。*2これは SFD では実現できないし、かといって未定義にしてしまうと、実際にそのリガチャが生じた時に文字が抜けてしまう。これを回避するには、そもそもリガチャを有効(-f liga
)にするのを止める*3、あるいは --ligkern
オプションで当該のリガチャだけを抑止する(詳細は otftotfm のマニュアル*4を参照)等の対策が必要になる。