マクロツイーター

はてダから移行した記事の表示が崩れてますが、そのうちに直せればいいのに(えっ)

dvipdfmxのフォントマップのunicodeの話(1)

この記事では「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
(標準和文を2004JIS字形にしたい場合は最初の2行を差し替える)
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の結果)が“変な文字”にならない。(“部首文字問題”が起こらない。)
  • 欠点

ある意味、標準和文と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にない文字なので使えない。

昔は「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 は無理
(縦組用TFMについては以下のようにする)
uprml-v     unicode             HogeraMincho-Regular.otf -w 1

CMap指定をunicodeにした場合、TFMの符号値をUnicode値とするグリフを出力する。物理フォントの種類は問わない。

uprml-hの0x2603   ―→   U+2603のグリフ
  • 利点
    • AJ1でないOpenTypeフォントにも適用できる。
    • 必ず入力したUnicodeの文字が出力される。
    • 古いdvipdfmxでもサポートしている。
  • 欠点
    • UnicodeのTFMにしか通用しない。
      • つまり、pTeXでは使えないし、japanese-otfの\CIDも全く使えなくなる。
    • Unicode文字に対する既定のグリフしか使えない。
    • このため、標準和文フォントにおいてJIS X 0208の範囲の一部の文字が使えない可能性が生じる。
      • ②と同じ。
    • フォントの中で異なるUnicode文字が同じグリフを共有する場合、文字情報(ToUnicodeの結果)が“変な文字”になる可能性がある。(“部首文字問題”が発生しうる。)

古い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 は無理
(標準和文を2004JIS字形にしたい場合は以下のようにする)
uprml-h     unicode             HogeraMincho-Regular.otf -l jp04

③の拡張版で、Unicode値によりグリフを選ぶ際にOpenTypeフィーチャを有効にする。最近(20170918版以降)のdvipdfmxでのみサポートされる。

uprml-hの0x2603   ―→   U+2603のjp90指定のグリフ
  • 利点
    • AJ1でないOpenTypeフォントにも適用できる。
    • 必ず入力したUnicodeの文字が出力される。
    • Unicode文字に対するグリフをある程度制御できる。
      • クオートは全角幅で出力される。
  • 欠点
    • 新しいdvipdfmxでしかサポートしていない。
    • UnicodeのTFMにしか通用しない。
    • フォントの中で異なるUnicode文字が同じグリフを共有する場合、文字情報(ToUnicodeの結果)が“変な文字”になる可能性がある。(“部首文字問題”が発生しうる。)

ひとまずまとめ

だめだ dvipdfmxのフォントマップ なにもわからない

(つづけ)

  1. (u)pLaTeXでパッケージを何も用いられない場合の和文フォントとして使われる和文TFMのこと。以下では「標準和文」と呼ぶ。

  2. AJ1のOpenTypeフォントについては①が最適である。TrueTypeフォントについては、昔は④は使えなかったし、③はほとんどの場合に②に劣るのでわざわざ選択する必要がない。