マクロツイーター

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

updmap の kanjiVariant はソレじゃない (1)

なんか某 Q & A が 2004JIS 字形の話で盛り上がってたようなので、それに余り関連しない話を一つ。

TeX Live では updmap の「kanjiEmbed オプション」というものを利用して、「どのフォントを埋め込むか(或いは埋め込まないか)」の設定を簡単に行えることを以前の記事で紹介した。ところで、updmap の和文フォント埋込に関する設定(オプション)には kanjiEmbed の他に kanjiVariant というものがある。これは何のためのものだろうか。

The related options supported in updmap and their respective allowed values are:

  • kanjiEmbed: selects the general font family or no embedding. Any string allowed, but see below.
  • kanjiVariant: selects the variant/style; currently only the styles for JIS1990 (value is the empty string) and JIS2004 (value is the string -04) are supported.

Let's suppose we want to use the Kozuka family of fonts in JIS2004 style. We thus set the respective options:

updmap-sys --setoption kanjiEmbed kozuka
updmap-sys --setoption kanjiVariant -04

「小塚フォント」や「ヒラギノフォント」等の CID 対応の OpenType フォントでは設定により 2000JIS 字形(= 90JIS 字形)と 2004JIS 字形を切り替えられるという話を何となく知っている人なら、この説明を読んで次のように推測するであろう。

(u)pTeX和文フォントとして CID 対応フォントを使用している場合、kanjivariant の値を「-04」に設定すると出力が 2004JIS 字形に切り替わる。

しかし、ソレじゃない、というのが今回の話。

前提知識: dvipdfmx のマップ行における 2000JIS/2004JIS 字形の指定

dvipdfmx では、DVI 中の和文符号位置に対応するフォント中の文字(グリフ)を決めるのに CID を利用する(だから JIS コードや Unicode では区別できない異体字を区別できる)。DVI の符号位置と CID の対応を記述するのに Adobe の CMap 形式を利用していて、マップ行の 2 番目の項目で CMap の名前(ファイル名でもある)を指定する。*1例えば以下に示すマップ行(upTeX の標準和文フォントに対する)を考えてみる。

uprml-h   UniJIS-UTF16-H      HogeraMinPr6N-Regular.otf     %(1)
uprml-h   UniJIS2004-UTF16-H  HogeraMinPr6N-Regular.otf     %(2)
uprml-h   UniJIS-UTF16-H      HogeraMinPr6-Regular.otf      %(3)
uprml-h   UniJIS2004-UTF16-H  HogeraMinPr6-Regular.otf      %(4)

ここで HogeraMinPr6N-Regular.otf および HogeraMinPr6-Regular.otf というのは「ほげら明朝」という(非実在の)CID 対応フォントの Pr6N 版と Pr6 版のファイル名であるとする。ここに現れる 2 つの CMap、UniJIS-UTF16-H と UniJIS2004-UTF16-H はどちらも「Unicode 符号位置から Adobe-Japan1 の CID」への対応を定めるが、各 Unicode 文字について、前者は「その文字の 2000JIS 字形の CID」、後者は「その文字の 2004JIS 字形の CID」に対応させるという違いがある。従って、dvipdfmx の出力における字形は、(1)(3) では 2000JIS 字形、(2)(4) では 2004JIS 字形となる。

ここで注意したいのは、「Pr6N と Pr6 の違いは影響しない」ということである。「N」付きと無しの違いは、フォントの「既定の」字形の違いであるが、これは「そのフォントで定めている Unicode から CID への対応」が違うことを意味している。ところが、上述の dvipdfmx の処理ではフォント内の対応は使わずに、外部の CMap に従って得た CID を使ってアクセスしている。Pr6N と Pr6 のどちらも AJ1 の規定に従っている以上、同じ CID に対する字形が異なることはあり得ない。

フォントの版の違いが関係しない以上、dvipdfmx を使う場合は、Pr6N と Pr6 のどちらか一方を持っていれば 2004JIS と 2000JIS の両方に対応できる。ただし、2004JIS に対するグリフには AJ1-6 で初めて追加されたものが含まれるので、UniJIS2004-UTF16-H の CMap を利用するためには AJ1-6 対応のフォントである必要がある。Pro や Pr5 版だと一部の文字が欠けてしまうだろう。

補足:CID 非対応フォントの場合

前述の通り、dvipdfmx では DVI の符号位置とフォント内のグリフの対応を CID で行うのが原則である。しかし、実際には多くの日本語フォントは CID に対応していない。そのようなフォントを指定する場合はどうなるか。詳細を省くが、この場合は dvipdfmx は「Unicode でのアクセス」に切り替える。つまり、フォント内の「Unicode からグリフへの対応」が用いられ、そのフォントでの「既定*2」の字形が用いられる。仮にそのフォントが GSUB 属性や IVS 等の他の手段で異体字の切替に対応していたとしても、dvipdfmx はそれらには非対応なので利用できない。

uprml-h   UniJIS-UTF16-H      honyara2004.ttf   %(1)
uprml-h   UniJIS2004-UTF16-H  honyara2004.ttf   %(2)
uprml-h   UniJIS-UTF16-H      honyara2000.ttf   %(3)
uprml-h   UniJIS2004-UTF16-H  honyara2000.ttf   %(4)

honyara2004.ttf と honyara2000.ttf は CID 非対応の「ほにゃらフォント」(非実在)の 2004JIS 版と 2000JIS 版のファイル名であるとする。CID 非対応フォントの場合は CMap の指定の違いが無関係なので、(1)(2) は 2004JIS 字形、(3)(4) は 2000JIS 字形で出力されることになる。

kanjiVariant が意味するもの

話を updmap に戻す。kanjiVariant オプションが何を意味するのかは、2012 年の「集い」の北川さんの発表スライドを見れば解る。(6ページ目)

これを見れば明らかなように、kanjiVariant 指定はフォントの版を指定するためのものである。無論、ユーザが所有しているのはどちらか一方の版であることが多いだろうから、どちらを使用するかを選ぶ指定は必須である。ではこの指定により出力字形はどうなるか。恐らく「N 付き」の方を持っている人は 2004JIS 字形が出ることを期待するだろうが、果たしてそうなっているのか。これは実際に読み込まれるマップファイルを調べると判る。例えば小塚フォント(kanjiEmbed が kozuka)の場合のマップ行は以下のようになっている。

[uptex-kozuka.map](kanjiVariant が空の時に使われる)
uprml-h   UniJIS-UTF16-H  KozMinPro-Regular.otf
[uptex-kozuka-04.map](kanjiVariant が「-04」の時に使われる)
uprml-h   UniJIS-UTF16-H  KozMinPr6N-Regular.otf

異なっているのはフォントファイル名だけであり、CMap はどちらも 2000JIS のものが指定されている。従って、出力字形はどちらも変わらず 2000JIS となる。なおこれまで(理由があって)upTeX のフォントに絞った話をしていたが、pTeX の標準フォントのマップ行でも状況は同じである。

[ptex-kozuka.map](kanjiVariant が空の時に使われる)
rml       H               KozMinPro-Regular.otf
[ptex-kozuka-04.map](kanjiVariant が「-04」の時に使われる)
rml       H               KozMinPr6N-Regular.otf

CMap はともに「H」でこれは 2000JIS(= 90JIS)字形を前提とした「JIS コード→CID」の対応である。従って、どちらの場合も 2000JIS 字形で出力されることになる。

まとめ
  • updmap の kanjiVariant オプションは出力字形ではなくフォントの版を選択するためのものである。
  • CID 対応フォントの場合、(標準和文フォントの)出力字形は常に 2000JIS 字形となる。
  • CID 非対応フォントの場合は出力字形はそのフォントの「既定」のものになる。

(続けばいいね)
↑「ソレはサポートされるべきか」という話がしたい。

*1:欧文フォントの場合は 2 番目には enc ファイルの名前を書くのであった。

*2:つまり GSUB 属性や IVS が何も指定されてない状態。