Hatena::ブログ(Diary)

マクロツイーター このページをアンテナに追加 RSSフィード Twitter

2011-10-08

dvipdfmx で OpenType する件について (SFD 編-4)

前回の続き)

SFD と .enc の「エンコーディング指定」の決定的な違い

これまでの説明だと、何となく、SFD ファイルというものは、「複数の .enc ファイルでサブフォントエンコーディングを定義していたものが、1 つのファイルで済むようになる、簡便な方法」という印象をもったかも知れない。しかし、実のところ、エンコーディング(.enc)ファイルと SFD ファイルでのエンコーディングの指定には大きな概念的な差がある。それは「.enc ファイルは『グリフ名で』文字(グリフ)を指定するのに対し、SFD ファイルは Unicode 符号位置で指定する」ということである。一般に、別のフォントの中にある「同じ文字」を考えた場合、それは同じ Unicode 符号位置をもつことがほとんどである*1が、グリフ名は異なるかも知れない。従って、マップファイルの記述を考えた場合*2

mplus1p-r-u00  mplus1p-u00  mplus-1p-regular.ttf
mplus1p-r-u00  mplus1p-u01  mplus-1p-regular.ttf
…… 

という .enc ファイルを用いた指定について、フォント(と TFM)を別のものに変えて同じ .enc ファイルの群を用いた

hogehoge-r-u00  mplus1p-u00  hogehoge-regular.ttf
hogehoge-r-u00  mplus1p-u01  hogehoge-regular.ttf
……

というものは「正しい」記述にはならない。これに対して

mplus1p-r-u@Unicode@  unicode  mplus-1p-regular.ttf

という SFD ファイルを用いた指定は、そのまま他のフォント(と TFM)に変えることができる。

hogehoge-r-u@Unicode@  unicode  hogehoge-regular.ttf

すなわち、Unicode.sfd は特定のフォントに依存しないのである。*3

余談であるが、この「SFD ファイルがフォントに依存しない」という性質は、拙作の PXchfon パッケージ(使用する基本フォントLaTeX 文書中で指定できるようにする)の欧文フォントの処理で重要な役割を果たしている。この処理では、ある特定の欧文 TFM(例えば cfjar-r-l0j.tfm)について、マップ行を文書中で指定する*4ことで実フォントを「文書中で指定された」ものに変更している。例えば、

\usepackage[alphabet]{pxchfon}
\setminchofont{ipam.ttf}

という指定をすると、次のようなマップ行が有効になる。

r-cfjar-r-@PXcjk0@ unicode ipam.ttf

ここで、SFD ファイルでの指定を用いている所がポイントで、このマップ行指定は任意のフォントについて適用させることができる。さらに、ここで用いている TFM は「日本語フォントに適応させた固定幅のメトリック」をもつので、「等幅」日本語フォントが用いられる限り、正常な出力が得られるのである。

(まだ続く)

*1:特に最近は Unicode を基準にして文字の同定を行うことが多いため。無論、Unicode と別の符号化文字集合で同定基準が異なるために、「同じ文字」の Unicode 位置が異なることは実際に起こる。

*2:つまり、「正しい」TFM 群が存在していると仮定する。

*3:ある符号位置のグリフが存在しない場合が気になるかも知れないが、その場合、TFM での対応の位置が未定義になるため、TeX はそういうグリフの位置を出力することがないので、問題は起こらない。

*4:以前に説明した「pdf:mapline special」を用いる。