この記事では「dvipdfmxの和文用のフォントマップの書き方は何となくわかるけど、CMap指定(2カラム目)をunicode
にする書き方の意味がわからない」という人のために、従来のCMap指定とunicode
指定の違いについて、何となく説明する。
※この記事では「CFFグリフのOpenTypeフォント」のことを“OpenTypeフォント”、「TrueTypeグリフのOpenTypeフォント」のことを“TrueTypeフォント”と呼ぶ。
CMap指定の4つのパターン
pTeX・upTeXの標準和文TFM1およびjapanese-otfパッケージの和文TFMのセットに対象を限ることにする。このセットに対するフォントマップのCMap指定として、主に以下に述べる4つのパターンが使われている。
※フォントマップの例は「横組・明朝・中字」のマップ行を抜粋して示す。他のウェイトについても全く同様になる。
①OpenTypeフォント+CMap指定
rml H HogeraMincho-Regular.otf uprml-h UniJIS-UTF16-H HogeraMincho-Regular.otf uprml-hq UniJIS-UCS2-H HogeraMincho-Regular.otf hminr-h H HogeraMincho-Regular.otf hminrn-h 2004-H HogeraMincho-Regular.otf otf-ujmr-h UniJIS-UTF16-H HogeraMincho-Regular.otf otf-ujmrn-h UniJIS2004-UTF16-H HogeraMincho-Regular.otf otf-cjmr-h Identity-H HogeraMincho-Regular.otf
rml 2004-H HogeraMincho-Regular.otf uprml-h UniJIS2004-UTF16-H HogeraMincho-Regular.otf
指定したCMapの変換先のCIDのグリフが出力される。
uprml-hの0x2603 ―(UniJIS-UTF16-H)→ CID+8218のグリフ
- 利点
- 標準和文フォントにおいてJIS X 0208の範囲の文字が全て全角幅で使える。
- 標準和文TFMは全角幅なので、物理フォント側のグリフが全角幅でないならそれは使えない。
- japanese-otfの機能が全て使える。
- つまり、
\CID
命令により、固定幅のグリフが全て使える。
- つまり、
- 文字情報(ToUnicodeの結果)が“変な文字”にならない。(“部首文字問題”が起こらない。)
- 標準和文フォントにおいてJIS X 0208の範囲の文字が全て全角幅で使える。
- 欠点
- AJ1のグリフ集合をもつOpenTypeフォントにしか適用できない。
- AI0のOpenTypeフォントに適用しようとするとエラーになる。(古いdvipdfmxの場合は文字化けになる。)
- TrueTypeフォントの場合は②に該当する。
- AJ1のグリフ集合をもつOpenTypeフォントにしか適用できない。
ある意味、標準和文とjapanese-otfにとって最も理想的な状態といえる。従って、AJ1のOpenTypeフォントの場合はこれを適用すべきである。次節以降の利点欠点比較はAJ1のOpenType以外のフォントを前提とする。
②TrueTypeフォント+CMap指定(フォールバック)
rml H HogeraMincho-Regular.ttf uprml-h UniJIS-UTF16-H HogeraMincho-Regular.ttf uprml-hq UniJIS-UCS2-H HogeraMincho-Regular.ttf hminr-h H HogeraMincho-Regular.ttf hminrn-h 2004-H HogeraMincho-Regular.ttf otf-ujmr-h UniJIS-UTF16-H HogeraMincho-Regular.ttf otf-ujmrn-h UniJIS2004-UTF16-H HogeraMincho-Regular.ttf otf-cjmr-h Identity-H HogeraMincho-Regular.ttf
CMapの指定は①と全く同じで、ただマップ先の物理フォントがTrueTypeフォントであることが違う。
TrueTypeフォントはAJ1のCIDでアクセスできないので、CMapの変換先のCIDにさらにToUnicodeを適用して結果のUnicode値の(既定の)グリフが出力される。(この場合、2004JIS字形用のCMapを指定しても結果は変わらない。)
uprml-hの0x2603 ―(UniJIS-UTF16-H)→ CID+8218 ―(ToUnicode)→ U+2603のグリフ
- 利点
- Unicode以外のTFM(rmlなど)でも対応できる。
- 古いdvipdfmxでもサポートしている。
- 文字情報(ToUnicodeの結果)が“変な文字”にならない。
- 内部的にはAJ1のフォントと同じ扱いになるため、らしい。
- 欠点
- 各Unicode文字に対する既定のグリフしか使えない。
- 例えば、90JIS字形と2004JIS字形の区別は(物理フォントの側が対応していたとしても)無効になる。
- このため、標準和文フォントにおいてJIS X 0208の範囲の一部の文字が使えない可能性が生じる。
- 例えば、最近のフォントではクオートの既定のグリフがプロポーショナル幅になっているので、標準和文としては使えない。たとえそのフォントが全角幅のクオートのグリフを別にもっていたとしても、それは使えない。
- UnicodeのTFMについて、一度CIDの変換を挟むため、一部のUnicode文字が利用できない、あるいは、入力した文字とは別の文字が出力される場合がある。
- 例えば、U+22EF は、U+22EF→CID+668→U+2026 と変換される。
- U+263A(☺)はAJ1にない文字なので使えない。
- 各Unicode文字に対する既定のグリフしか使えない。
昔は「AJ1のOpenTypeフォント」と「TrueTypeフォント」しかなかったので、①②のパターンだけ(つまり常に「CMap指定」を行う)で全て済んでいた2。この場合、前者の場合は①、後者の場合は②と解釈されることになる。
③Unicode直接指定
%rml は無理 uprml-h unicode HogeraMincho-Regular.otf uprml-hq unicode HogeraMincho-Regular.otf %hminr-h は無理 %hminrn-h は無理 otf-ujmr-h unicode HogeraMincho-Regular.otf otf-ujmrn-h unicode HogeraMincho-Regular.otf %otf-cjmr-h は無理
uprml-v unicode HogeraMincho-Regular.otf -w 1
CMap指定をunicode
にした場合、TFMの符号値をUnicode値とするグリフを出力する。物理フォントの種類は問わない。
uprml-hの0x2603 ―→ U+2603のグリフ
- 利点
- AJ1でないOpenTypeフォントにも適用できる。
- 必ず入力したUnicodeの文字が出力される。
- 古いdvipdfmxでもサポートしている。
- 欠点
古いdvipdfmxの場合、AJ1でないOpenTypeフォントではこの③しか使えない。
④Unicode直接指定+フィーチャ指定
%rml は無理 uprml-h unicode HogeraMincho-Regular.otf -l jp90 uprml-hq unicode HogeraMincho-Regular.otf -l fwid %hminr-h は無理 %hminrn-h は無理 otf-ujmr-h unicode HogeraMincho-Regular.otf -l jp90 otf-ujmrn-h unicode HogeraMincho-Regular.otf -l jp04 %otf-cjmr-h は無理
uprml-h unicode HogeraMincho-Regular.otf -l jp04
③の拡張版で、Unicode値によりグリフを選ぶ際にOpenTypeフィーチャを有効にする。最近(20170918版以降)のdvipdfmxでのみサポートされる。
uprml-hの0x2603 ―→ U+2603のjp90指定のグリフ
- 利点
- AJ1でないOpenTypeフォントにも適用できる。
- 必ず入力したUnicodeの文字が出力される。
- 各Unicode文字に対するグリフをある程度制御できる。
- クオートは全角幅で出力される。
- 欠点
ひとまずまとめ
だめだ dvipdfmxのフォントマップ なにもわからない
-
(u)pLaTeXでパッケージを何も用いられない場合の和文フォントとして使われる和文TFMのこと。以下では「標準和文」と呼ぶ。↩
-
AJ1のOpenTypeフォントについては①が最適である。TrueTypeフォントについては、昔は④は使えなかったし、③はほとんどの場合に②に劣るのでわざわざ選択する必要がない。↩