PXchfon の新しいやつ（v1.1a） - マクロツイーター

W32TeX や TeX Live では既に更新されている。

Package PXchfon(CTAN) 1.1a 版。

Unicode 直接指定に関するアレコレ

アドホックに拡張を続けていて複雑になっているので、一回整理してみた。ただ、何か機能を削ったわけではないので依然として複雑であり、一般のユーザが知る必要性も乏しいので詳細はブログでは扱わない。マニュアル((TeX Live や W32TeX では「texdoc pxchfon」で開く。))の「Unicode 直接指定」の節（7 節）を参照してほしい。

要するに

dvipdfmx の ~~20170627 版~~ 20170918 版以降であれば、pxchfon で unicode オプションを付けることで、「AJ1 でない OpenType フォント」が使用できるようになる。また、任意の OpenType フォント（TrueType グリフのものも含む）について、OpenType の機能を利用した機能（異体字の区別など）が使えるようになる。
dvipdfmx の 20170318 版（TeX Live 2017）の場合、残念ながら unicode は使えないが、代わりに“劣化版”である unicode* が使える。劣化版なので、一部の機能が異常になる。
Source Han 系のプリセット（sourcehan(-otc)、noto(-otc)）は自動的に unicode を有効化する。
- ただし、unicode は TeX Live 2017 で使えないため、「unicode* 状態に対してアレな細工を施して unicode 状態を模倣した」プリセットである sourcehan(-otc)+、noto-(otc)+ を用意している。これらは unicode* が使える環境なら使える。
- そして、TeX Live 2017 の期間の暫定措置として、Source Han 系のプリセット（sourcehan など）は“+ 版”（sourcehan+ など）として扱われる。((TeX Live 2018 のリリースの時点で本来の「unicode 版」に切り替わる予定である。TeX Live 2017 のユーザの便宜のため、“+ 版”も当面の間サポートされる。))
- 「yu-win10 に unicode を付けた状態」を（アレな細工をして）模倣したプリセットである yu-win10+ も存在する。（yu-win10 は従来通り非 unicode である。）((TeX Live 2018 でどうするかは未定。yu-win10 を自動的に unicode 付きにすると、「古い dvipdfmx で yu-win10 を使っていた人が pxchfon をアップデートすると異常になる」という不具合を生じてしまうし、また同名の ptex-fontmap の設定とも食い違う。「yu-win10* を別に作る」という案もあるが、そもそも任意のプリセットに unicode を付けることができるのだから、yu-win10 を特別扱いする必要もないようにも思える。))
前項以外の場合、unicode も unicode* も付けなければ「従来通り」（CMap 指定）になる。
“試験的”であるため、まだマニュアルにも書いてないこと：
- unicode(*) が有効である場合、自動的に pxufont パッケージが読み込まれる。((正確ににいうと、「pxufont を読み込む」ことを指定する replace-legacycode というオプションが存在し、unicode(*) はこのオプションを既定で有効にする。apply-legacycode というオプションを指定するとこの指定は打ち消される。))
- これにより、pLaTeX でも unicode(*) 指定が機能するようになる。
- また、japanese-otf の \CID 命令も正常になる。

要するに要するに

プリセット指定で、Source Han 系のフォントが使える。pLaTeX でも使える。
yu-win10 で欧文クオートがアレで困った場合は、代わりに yu-win10+ を使おう。
“AJ1 でない OpenType フォント”を使いたい場合は、unicode* オプション（~~20170627 版~~ 20170918 版以降の dvipdfmx の場合は unicode オプション）を指定しよう。

CSI 指定を正しくする

※上級者向けの話題である。

旧版の pxchfon において japanese-otf 併用で kozuka-pr6n プリセットを指定した場合、Identity-H の CMap を指定したマップ行（例えば otf-cjmr-h）は次のようになっていた。

otf-cjmr-h Identity-H KozMinPr6N-Regular.otf/AJ16

ところが、この中の /AJ16 のような指定（CSI 指定）は、本来は TrueType グリフのフォントを指定する場合にのみ付加すべきものであり、KozMinPr6N-Regular.otf のような CFF グリフのフォントの時に付加するのは正しくない。ただし、これまでのところ、不正に付けていても特に問題は起こらないようである。

「フォントのグリフ種別を TeX で判別する」のは面倒であり((例えば「拡張子が .otf である TrueType グリフのフォント」もあるので、ファイル名の拡張子では判別できない。))、かつ実害もないため、これまで対策は敢えてしていなかった。しかし、フォントマップのダンプ機能が使われた場合、外から見えるファイルに書いてあるマップ行に問題がある、というのは許容し難いであろう。

そういうわけで、CSI 指定の付加を適切に行う機能を実装した。ただし、この機能は kpsewhich の呼出を伴うため時間がかかる。そのため、strictcsi オプションを付けたときにのみ働くようにした。そして、フォントマップダンプ機能（dumpmap(tl) オプション）が有効な場合は自動的に既定で有効になる。

以上より、新版でフォントマップダンプを行った場合、マップファイルには以下のような適切な（CSI 無しの）マップ行が出力される。

otf-cjmr-h Identity-H KozMinPr6N-Regular.otf

“strictcsi”オプション

strictcsi： Identity-H/V に対する CSI 指定を（仕様に厳密に従って）フォントが TrueType グリフの場合にのみ出力する。
nostrictcsi（既定）： strictcsi の否定。Identity-H/V に対する CSI 指定は常に出力される。
- dumpmap(tl) が指定された場合は strictcsi が既定になる。

もっと“アレな細工”する話

Source Han 系のプリセット（の“+版”*1）では「一部を中国語用のフォントに飛ばす」という“アレな細工”を行っているため、通常（unicode* 状態）では不正になる欧文クオートの出力が正常になる。

% upLaTeX文書
\documentclass[uplatex,a4paper]{jsarticle}
\usepackage[sourcehan-otc]{pxchfon}
\begin{document}
{\TeX}は“アレ”。
\end{document}

ところが、ここでもし「自分はもっと細い明朝体がよい」ということで、\setminchofont で Source Han Serif Light を設定したとする。この場合、“細工”が必要なクオートはどうなるか。

% upLaTeX文書
\documentclass[uplatex,a4paper]{jsarticle}
\usepackage[sourcehan-otc]{pxchfon}
\setminchofont[0]{SourceHanSerif-Light.ttc}% 明朝体はLightにしたい
\begin{document}
{\TeX}は“アレ”。
\end{document}

旧版では、“細工”はプリセット指定で選択されたフォントにしか効果がなかった。だから、先の場合、クオートの出力は異常になる。

新版では、Source Han 系のプリセットが指定されている場合、\set...font 命令で自分で指定した Source Han 系のフォントにも“細工”が適用される。従って、クオートは正常に出力されるようになる。((これは「中国語版の Source Han Serif Light」が使われているということなので、当該のフォントがインストールされている必要がある。なお、noswitchfont というオプションを指定すると、この類の「別のフォントに振り替える」という“細工”を全て抑止することができる。もちろん、それにより出力が不正になるかも知れない。))