pLaTeX でも源ノ明朝したい話

今もうできること

新しい dvipdfmx（20170318 版以降）では「Unicode 直接アクセス指定」の機能が強化され、それにより従来は面倒であった「AJ1 でない OpenType フォント」への対応が格段に容易になった、という話は既に何度か述べた。

• pxchfon の新しいやつ（v1.0）
• pxchfon の新しいやつ（v1.0a）
• upLaTeX文書で源ノ明朝／Noto Serif CJKを簡単に使う方法（最新のdvipdfmxとpxchfonを使用）

すなわち、最新の TeX Live 2017 では次のようにして源ノ明朝（Source Han Serif）を upLaTeX で使うことができるようになっている。

% upLaTeX文書
\documentclass[uplatex,papersize,a5paper]{jsarticle}
\usepackage[deluxe]{otf}
\usepackage[sourcehan-otc]{pxchfon}% 源ノアレ
\begin{document}
{\TeX}と{\ajSnowman}は\textbf{一切}関係ありません。
\end{document}

今まだできないこと

一方で、dvipdfmx の「Unicode 直接アクセス指定」を利用した方法には明らかな限界がある。それは「Unicode 以外の和文フォントには対応できない」ということである。このため、「pLaTeX の標準和文フォント」や「japanese-otf の \CID 入力」には対応できない。

例えば次の pLaTeX 文書があるとする。

\documentclass[papersize,a5paper]{jsarticle}% pLaTeX用
%\documentclass[uplatex,papersize,a5paper]{jsarticle}% upLaTeX用
\usepackage{otf}
\usepackage[kozuka-pr6n]{pxchfon}% 小塚フォント
%\usepackage[sourcehan-otc]{pxchfon}% 源ノアレ
\renewcommand{\theenumi}{\ajLabel\ajMaru{enumi}}
\renewcommand{\labelenumi}{\theenumi}
\begin{document}
韓国プロ野球ではシーズン最多本塁打数の記録をもち
「アジアの大砲」と呼ばれ、日本の読売巨人軍に5年間在籍した
野球選手は誰か。
\begin{enumerate}
\item 森\UTF{9DD7}外
\item \UTF{9127}小平
\item \CID{13706}澤ひとみ
\item ウィリアム・ヘンリー・ゲイツ\ajRoman{3}世
\item またそのネタですか
\end{enumerate}
\end{document}

pxchfon のプリセットを kozuka-pr6n にした状態（上掲のソースのまま）では pLaTeX でのコンパイルは正常に行われる。

しかしプリセットを sourcehan-otc にした場合（4 行目の代わりに 5 行目を有効にする）は、pLaTeX のコンパイルは無事に終わるが、dvipdfmx の実行で次のようなエラーが出て失敗する。要するに「フォントが Adone-Japan1 でないからダメ」ということである。*1

Character collection mismatched:
        Font: Adobe-Identity-0
        CMap: Adobe-Japan1-1

dvipdfmx:fatal: Inconsistent CMap specified for this font.

Output file removed.

また、同じ内容の文書を upLaTeX でコンパイルした場合（1 行目の代わりに 2 行目を有効にする）は、直接入力と \UTF 入力の文字は正常に出力されるが、\CID 入力は全て化けている。

でも何とかしてみる

これは dvipdfmx 自体がもつ制限なので、マップ設定を工夫することでは（物理フォントの種類に依存しない形では）解決できない。しかし、話を「pxchfon が扱う範囲（標準および japanese-otf の和文フォント）」に絞って考えると、突破口は存在する。

要するに、論理フォントの名目の情報（TFM 名および NFSS での位置）が全て既知であるため、「Unicode の論理フォントだけを参照する仮想フォント（VF）」として他の（非 Unicode の）論理フォントの代替物を作成し、LaTeX 側の（NFSS の）設定を代替物の方を使用するように変更すればよいのである。*2

というわけで、作ってみた。（最新の TeX Live および W32TeX には既に収録されている。）

• Package pxufont （CTAN）

この pxufont は単に \usepackage で読み込むだけでよい。（japanese-otf と併用する場合は otf パッケージの跡に読み込む。）

\documentclass[papersize,a5paper]{jsarticle}% pLaTeX用
%\documentclass[uplatex,papersize,a5paper]{jsarticle}% upLaTeX用
\usepackage{otf}
\usepackage{pxufont}% これでOK!
\usepackage[sourcehan-otc]{pxchfon}% 源ノアレ
\renewcommand{\theenumi}{\ajLabel\ajMaru{enumi}}
\renewcommand{\labelenumi}{\theenumi}
\begin{document}
韓国プロ野球ではシーズン最多本塁打数の記録をもち
「アジアの大砲」と呼ばれ、日本の読売巨人軍に5年間在籍した
野球選手は誰か。
\begin{enumerate}
\item 森\UTF{9DD7}外
\item \UTF{9127}小平
\item \CID{13706}澤ひとみ
\item ウィリアム・ヘンリー・ゲイツ\ajRoman{3}世
\item またそのネタですか
\end{enumerate}
\end{document}

今まで正常に扱えなかった非 Unicode のフォントが全て正常に出力されている。

もちろん、Unicode の論理フォントを参照している以上、Unicode にない文字には対応できない。（これは CID-keyed でない TrueType フォントを dvipdfmx で指定して普通に japanese-otf を用いた時と同様の制限である。）

% pLaTeX文書
\documentclass{jsarticle}
\usepackage{otf}
\usepackage[sourcehan-otc]{pxchfon}
\usepackage{pxufont}
\begin{document}
\begin{itemize}
\item \ajMaru{10}\ajMaru{20}\ajMaru{30}\ajMaru{40}%
      \ajMaru{50}\ajMaru{60}\ajMaru{70}\ajMaru{80}
\item \○A\○a\（A）\（a）\□A\□a\●A\●a
\item \ajLig{ドル}\ajLig{ポンド}\ajLig{ユーロ}\ajLig{ルーブル}%
      \ajLig{リラ}\ajLig{ルピー}\ajLig{バーツ}\ajLig{ドラクマ}
\item \○上\○下\○印\○秘\○正\○副\○問\○答
\item \ajSnowman\ajUmbrella\ajPostal\ajBall
      \ajUpHand\ajDownHand\ajRightScissors\ajLeftScissors
\end{itemize}
\end{document}

これの出力結果は以下の左の図のようになる。右の図は同じ内容の文書を小塚フォントで出力したものであり、これと比較すると一部の文字が正常に出力されないことが判る。((実を言うと、\ajSnowman、\ajUmbrella、\ajPostal の 3 つの記号は japanese-otf において最初から Unicode のフォントで扱われているのであるが。))

 

将来できるようになること

現状では、japanese-otf の機能を用いた異体字の区別はうまく働かない。

%\documentclass{jsarticle}% pLaTeX用
\documentclass[uplatex]{jsarticle}% upLaTeX用
% 2004JIS字形を指定する
\usepackage[jis2004]{otf}
\usepackage[sourcehan-otc,prefer2004jis]{pxchfon}
\usepackage{pxufont}
\begin{document}
\begin{itemize}
\item 葛餅で蓬餅で、かつ煎餅！
\item \CID{1481}城市から\CID{7652}飾区まで。% 字形の使い分け
\end{itemize}
\end{document}

pLaTeX でコンパイルした場合は、ほぼ確実に 90JIS 字形が選択される。

upLaTeX でコンパイルした場合は、japanese-otf の jis2004 の有無は正常に考慮されるが、それでも \CID で「両方の字形を使い分ける」ことはできない。

しかし実はこれは 20170318 版の dvipdfmx に存在するチョットしたバグのせいである。最新の 20170627 版（W32TeX では既に利用可能である）ではこのバグは既に修正されているため、完全に意図通りの出力が得られる。

この新しい dvipdfmx が TeX Live で使えるようになるのは来年の TeX Live 2018 からということになる。この新しい dvipdfmx が普及すれば、「Unicode 直接アクセス指定」の活用の幅はもっと拡がることになるだろう。

*1:この「グリフ集合の整合性の検査」も新版の dvipdfmx で導入された。それまでは不整合であっても“適当に”処理が続けられたが、当該フォントの出力は完全に文字化けになっていた。

*2:pLaTeX の japanese-otf の中字・明朝体フォントを例にすると： NFSS から実の TFM へのマップは JY1/hmc/m/n → nmlminr-h → hminr-h である。しかし“Unicode 直接”前提の dvipdfmx のマップでは JIS コードの hminr-h は使えず Unicode の otf-ujmr-h しか使えない。従って、nmlminr-h と等価（つまり JIS コード）でマップ先を otf-ujmr-h とした新たな VF の zu-nmlminr-h を用意した上で、NFSS 側で JY1/hmc/m/n → zu-nmlminr-h → otf-ujmr-h というマップに置き換えるのである。