マクロツイーター

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

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

前回の続き)

前回、TeX Live の updmap の kanjiVariant オプションは「異体字切替」ではなく「フォントの版の指定」を意味することを説明した。それでは「異体字切替」はサポートすべきか、もしそうならどういう設定方法にすべきか、というのが今回の話。(CID 対応フォントを使用の場合に限る。)

論点
  • 私が一番気になっている点は、kanjiVariant という「異体字を切り替える」設定を連想させる名前のオプションが、実際にはかなり異なる設定のためのものである、ということ。
  • 私は、もし kanjiVariant という名前のオプションがあるなら、それは「異体字切替の設定」であるべきだと思う。
  • もちろん、既存の仕様を変更するのにはリスクがある。
  • 後述のように、OTF パッケージ*1を利用すれば 2004JIS 字形に切り替えることはできる。
  • ただし現況では 2004JIS 字形の方が適切である場面が増えているので、2004JIS 字形が「既定で」使える設定が欲しいかも知れない。
  • pTeX での 2004JIS 字形の選択を実現しようとすると、JISX0213-2004-H/V の「CMap(のような何か)」が必要になる。*2
  • 「フォントの版(Pro とか Pr6N とか)」を選択する機能は不可欠である。
  • フォントの版の区別は kanjiEmbed の値に含ませればよいと思う。例えば hiragino-pro や kozuka-pr6n のように。
  • 「rml や uprml-h が定める特質は何か」という規定策定上の問題もある。つまり rml は単に「JIS X 0208 の横組の明朝体」なのか、それとも「2000JIS(90JIS)字形である」という性質まで表しているのか。もし後者であれば、単純に rml の CMap 指定を取り換えるのは「理屈が合わない」ことになる。もっともこの考えに従うと、そもそも 2000JIS と 2004JIS で(和文エンコーディングを区別すべきだという議論になり、(実際に私は区別した方がよいと考えているのであるが、)今の pLaTeX に大掛かりな機能追加が必要になりえる。現実論としてはそこまで複雑なことをするメリットがないように感じるので、この「厳格な規定」の立場は取らない方が得策がも知れない。
OTF パッケージの字形切替機能

OTF パッケージ(の「ベータ版」)では 2000JIS と 2004JIS の字形の切替をサポートしている。既定は 2000JIS となるが、パッケージ読込時に jis2004 オプションを指定すると直接入力と \UTF和文が 2004JIS になる。もちろん \CID 入力の字形は変わらない。

% pLaTeX 文書
\documentclass[a6paper,papersize]{jsarticle}
\usepackage{otf} % 2000JIS字形
\begin{document}
辻辿迂迄迦逗這逢逼遁遜遡
\end{document}
% pLaTeX 文書
\documentclass[a6paper,papersize]{jsarticle}
\usepackage[jis2004]{otf} % 2004JIS字形
\begin{document}
辻辿迂迄迦逗這逢逼遁遜遡
\end{document}

なお、この jis2004 オプションは upTeX での動作ではサポートされないようである。

以下は TeX Live で提供されている OTF パッケージ用のマップファイルについての考察。

  • 直接入力用(JIS コード)のフォントの 2004JIS 対応には、JISX0213-2004-H の CMap(のような何か)を利用しているのではなく、VF で Identity CMap のフォントに振り替えるという処理をしている。
  • これに対して \UTF 入力用(Unicode)のフォントの 2004JIS 版では、CMap を UniJIS2004-UTF16-H/V にした別のフォント(TFM)を用意するという方法が採られている。
  • もちろん、OTF パッケージでは、フォントマップ設定(kanjiEmbed/kanjiVariant)を切り替えなくても字形の切り替えが可能になっている。だからそのフォント(TFM)の集合には 2000JIS 用のもの(otf-ujmr-h 等)と 2004JIS 用のもの(otf-ujmrn-h 等)の両方が含まれている。
  • 従って、OTF パッケージ用のマップファイルでは「異体字切替」の設定は存在しないことになる。
  • 一方で、「フォントの版の指定」は OTF パッケージでも明らかに意味をもつ。現状の TeX Live ではこれに対応していない*3ようであるが、対応することが望ましい。
  • ここで注意すべきは、Pro 版等の「2004JIS に完全対応できない」フォントの版に対応するマップファイルにおける otf-ujmrn-h 等の設定である。この箇所だけ Pr6/Pr6N 版等の「完全対応できる」フォントを指定するのは意味がない。何故かというと、その設定では、Pro 版しか持っていない人は結局 otf-ujmrn-h は「全く使えない」ことになるし、また Pr6/Pr6N 版を持っている人はそちらのフォントを全面的に使う設定が使えるので Pro 版のマップファイルを使う必要がないからである。
私の考え
  • kanjiVariant は「異体字切替」のオプションとする。(仕様変更)
  • 「フォントの版の選択」は kanjiEmbed の値に含める: hiragino-pro、kozuka-pr6n 等。
  • 互換性のため、単純な hiragino、kozuka 等の kanjiEmbed の値のフォントマップは従来と同じとする。
  • kanjiVariant が -04 のフォントマップは CMap の設定を JISX0213-2004-H/V、UniJIS2004-UTF16-H/V に変える。
  • だから noEmbed の -04 版もある。
  • kanjiEmbed が Pro 版フォントの場合の -04 版は不要。
  • OTF パッケージのフォントマップの -04「フォントの版の異なる」版も用意する。
  • Pro 版フォント用のマップでは全ての使用フォントを Pro 版にする。

この考えに従うと、updmap の改修は不要で、いくつかのフォントマップのファイルを追加すればよいことになる。

*1:「ベータ版」の系列が必要だが TeX Live に収録されているのはそれである。

*2:ちなみに、現状の TeX Live には既に「オリジナルの CMap(のような何か)」を含んでいて、それは UTF8-UTF16 である。(正確には「ToUnicode CMap のような何か」。)

*3:つまり、「フォントの版の指定」であるはずの kanjiVariant 指定は OTF パッケージ用のマップファイルには適用されない。