pxchfon使用時のコードポイント

pxchfon使用時のコードポイント

- parallax の投稿
返信数: 4
次のようなファイルを(u)pLaTeX+dvipdfmxで処理したとき、pxchfonのオプションにより「長」という文字のコードポイントが変化します。
こちらの環境はWindows 10、TeX Live 2018と最新版のパッケージ、最新のNoto CJKフォントです。

\documentclass[uplatex,dvipdfmx]{jsarticle}
\usepackage[noto-otc]{pxchfon}
\begin{document}
長い
\end{document}

具体的にはpxchfonを使わない場合やipaexのときにはU+9577が、noto-otcのときにはU+2ED1が利用されます。
この挙動は仕様でしょうか？
（pxchfonのマニュアルには一応目を通しましたが、フォント周りのことが理解できていないので記載済みであれば申し訳ないです。）
parallax への返信

Re: pxchfon使用時のコードポイント

- aminophen の投稿
（まだよくわかっていませんが一応，回答をつけておきます…。）

難しい話ですが，端的には TeX Wiki の「XeTeX」のページにある

> XeTeX 0.99998 以前のバージョンで \setmainfont{ipaexm.ttf} や \setmainfont{SourceHanSansJP-Normal.otf} で
> 見(U+898B) を処理すると ⾒(U+2F92) で出力される場合がある

と同根です。TeX Live 2018 では対処済みとされていますが，これはあくまで
KANGXI RADICAL (U+2F00 〜 U+2FD5)
と一致する字形のみに“回避策”が施されたにすぎず，
CJK Radical Supplement (U+2E80～2EFF)
には対処が入っていないため今回の件が起きています。
（同じ“回避策”を使うと副作用もありうるので悩ましい。）

なので，pxchfon とは直接関係なく，dvipdfmx 側の制約と考えたほうが良いと思います。
aminophen への返信

Re: pxchfon使用時のコードポイント

- aminophen の投稿
r50124 で，CJK Radicals Supplement (U+2E80～2EFF) も対処しました。
先のコメントでは

> 副作用もありうる

と書いたのですが，具体的には

「Radical（部首）としてしかコードされていない文字」の ToUnicode 情報が消えてしまうのでは？

という懸念でした。しかし，特にこのような問題は起きなかったので，大丈夫と判断しました。

# これとは無関係に「数字0〜9の ToUnicode が入らない」という問題が
# 昨日報告されているので，それは別途考えます…。
aminophen への返信

Re: pxchfon使用時のコードポイント

- aminophen の投稿
本題からはそれますが

> 「数字0〜9の ToUnicode が入らない」という問題

について，調べようと思ったのですがよくわかりません。
https://github.com/texjporg/tex-jp-build/issues/75
に情報を載せておくので，SourceHanSerif / NotoSerifCJK を使う場合はご注意ください。

# 原因がわかる方，ここ (forum) でもあちら (GitHub) でもいいのでご一報ください。
aminophen への返信

Re: pxchfon使用時のコードポイント

- parallax の投稿
対処して頂いたようでありがとうございます。
バイナリはTeX Live 2019での配布になるものと理解しているので、それまで気長に待つとします。

またせっかくなので数字周りの挙動について手元のNoto CJKフォントで確認したところ、
Noto Serif CJKとNoto Sans CJKで問題が起き、Noto Sans Mono CJKでは発生しないようです。