[dvipdfmx] TrueType フォント使用時に一部の漢字が出力されない

[h20y6m]

dvipdfmx で TrueType 利用時に一部の漢字が出力できなくなりました。

%ptex
\special{pdf:mapline rml H ipaexm.ttf}
逢う
\bye

dvipdfmx:warning: Unable to map CID to code: CID=1133

%uptex
\special{pdf:mapline uprml-h UniJIS-UTF16-H ipaexm.ttf}
神% U+FA19
\bye

dvipdfmx:warning: CID=8580 mapped to non-single Unicode characters...
dvipdfmx:warning: Unable to map CID to code: CID=8580

2023年1月中頃に Adobe-Japan1-UCS2 が更新され一部の漢字等に異体字セレクタ付きのものになった影響のようです。
https://www.tug.org/svn/texlive/trunk/Master/texmf-dist/fonts/cmap/adobemapping/mapping-resources-pdf/pdf2unicode/Adobe-Japan1-UCS2?r1=50714&r2=65589
（t-tk さんの指摘も反映されているようです。）

異体字セレクタ付きになったのは

1. JIS90字形（162文字）
2. CJK互換漢字（89文字）
3. CJK部首補助？（4文字）
4. \CIDな異体字（1000文字くらい？）

あたりのようです。
参考： https://gist.github.com/h20y6m/093e9085d0c10b6e7e69abd4502a9568

1 は kanji-config-updmap コマンドや pxchfon パッケージで jis2004 オプションなし（デフォルト）で TrueType フォントに切り替えしている場合に JIS2004 で字形が変わる文字が豆腐になります。jis2004 オプションを指定することで回避できますがデフォルトが90字形なので引っかかる人でそうです。

2 は Unicode 正規化で化けることで有名な奴です。Unicode 6.3 で追加されたCJK互換漢字を選択する異体字セレクタを使うように変更されたようです。CJK互換漢字がどの程度使われているのかは分かりませんが、upTeX でしか使えない文字なのでフォントマップを Unicode 直接指定にすれば（1 も含めて）回避できます。ただし Unicode 直接指定による問題もあるのでこの回避策が使えないこともあるかもしれません。

3 は使う人いるのかなぁ……

4 はもともと TrueType フォントでは CID 指定は使えないので影響はないとは思いますが、いままで異体字は規定？の字形で出力されていたのが豆腐になります。

---

対応策としては

• Adobe-Japan1-UCS2 を古いものに戻してもらう
  • せっかくの修正も戻ってしまう
  • どちらのほうが影響が大きいか？
• dvipdfmx を修正する
  • TeX Live 2023 はすでに code freeze されていて、最終ビルドもコミットされていきてるので望み薄
  • 1年間このまま？

どうすべきでしょうか？

---

TeX Live 2023 には間に合いそうにありませんが、一応突貫で dvipdfmx のパッチを書いてみました。

h20y6m/tex-jp-build@master...dvipdfmx_uvs

[t-tk]

ありがとうございます。
思わぬ不具合ですが

Adobe-Japan1-UCS2 を古いものに戻してもらう

は無いと思います。しかし一年我慢もちょっと、と思います。
一昨日　"the final updates for TL23 on Friday" とKarlさんからメールが出ていましたが、ねじ込めないかなあ。

[aminophen]

dvipdfmx の変更は第一に平田さんの意向を聞いた方が良いと思います。とりあえず shirat74/dvipdfm-x#8 には書き込みましたが，メールの方が良かったかもしれません。

[aminophen]

Adobe-Japan1-UCS2 を古いものに戻してもらう

これは「Adobe に戻してもらう」と「CTAN/TeX Live で古いものに戻す」の2パターンがあって，後者ならば Karl さんの裁量次第です。（また，安定志向の人が年度末の TL2022 frozen を好んで使うケースがあります。もしも TL2023 initial だけでなく TL2022 frozen も是正を狙うなら，CTAN/TeX Live で戻す手しかありません。）

[t-tk]

なるほど。「Adobe に戻してもらう」は無いと思いますが、
「CTAN/TeX Live で古いもの」と現状の dvipdfmx の組み合わせにしてもらい、
dvipdfmx の update とともに CTAN/TeX Liveも新しくしてもらう、
なら大丈夫のような気がしてきました。

[aminophen]

とりあえず「CTAN/TeX Live で古いもの」にすべく

https://github.com/aminophen/ctan-adobemapping/tree/tlfreeze-20190730

のようにしました。Karl さんには別途メールを入れました。

[aminophen]

CTAN/TeX Live で adobemapping が無事(?)戻りました。dvipdfmx が更新するまで adobemapping の新版を取り入れないようにします。

[h20y6m]

動きがないまま半年経ちましたがどうしましょう？

とりあえず突貫で作ったパッチを見直しました。

1. 390675c
   • マップ先が基底文字＋異体字セレクタ（U+FE00--U+FE0F or U+E0100--U+E01EF）だったら異体字セレクタを無視する。
   • 逢のJIS90字形（CID+1133; U+9022 U+E0100）は U+9022 にマップされる。
2. a7dae3a
   • マップ先がCJK互換漢字に対応するCJK統合漢字と異体字セレクタの組合せだったらCJK互換漢字に変換する。
   • 神（CID+8580; U+795E U+FE00）は U+FA19 にマップされる。
3. cd1d1e0
   • フォントに 2 で変換した互換漢字がなかったときは変換前の異体字セレクタを無視した統合漢字でグリフを検索する。
   • 神（CID+8580; U+795E U+FE00）の変換先 U+FA19 がフォントになければ U+795E を検索する。
   • これは余計だったかも

1 と 2 は互換性のために必要だと思います。3 ちょっと余計な変更だった気もしてきました。

より理想的にはフォントがサポートしていれば Format 14 テーブルを読んで異体字を出力できればよいのでしょうが……
（Format 14 テーブルは #46 でも必要になりそうなので考えてみようかな？）

[t-tk]

異体字セレクタに SVS (互換漢字など)と IVS (字形の差異) の違いもあるのですね。
あるべき姿はどうなのか、もまだ考えがまとまっていません。たたき台です。

---

SVS対象 (例: CID+13393 → U+9686 U+FE00 (隆︀) → U+F9DC (隆) というマップ)
(1) U+F9DC (隆) に対し U+F9DC を出力する
(2) U+9686 U+FE00 (隆︀) (→ U+F9DC) に対し U+F9DC を出力する (U+9686 U+FE00 → U+F9DC の変換は dvipdfmxで行う)
(3a) U+9686 U+FE00 に対し、フォントに U+9686 U+FE00 があれば U+9686 U+FE00 を出力する。
(3b) フォントに U+9686 U+FE00 がなく、フォントに U+F9DC があれば U+F9DC を出力する (U+9686 U+FE00 → U+F9DC の変換は dvipdfmxで行う)
(3c) フォントに U+9686 U+FE00, U+F9DC がなく、フォントに U+9686 があれば SVSを無視して U+9686 を出力する

IVS対象 (例: CID+8686 → U+9686 U+E0102 (隆󠄂) というマップ)
(4) IVSを無視してフォントに U+9686 があれば U+9686 を出力する。
(5a) フォントに U+9686 U+E0102 があれば U+9686 U+E0102 を出力する。
(5b) フォントに U+9686 U+E0102 がなく、フォントに U+9686 があれば U+9686 を出力する

---

SVS対象では
(1)は現状のもの。
(2)は Adobe-Japan1-UCS2 の異体字セレクタ付き新版に対応したもの。 a7dae3a 相当?
(3a)(3b) は、将来あるべき姿でしょうか。
(3c) は、過剰かもしれません。

IVS対象では
(4)は、異体字セレクタを無視してほしくない人にとってはかえってありがたくない機能かもしれませんが、過去の互換性のために要りますか? 390675c 相当?
(5a)は、将来あるべき姿でしょうか。
(5b)は、(4)よりも異体字セレクタの考え方からすれば正しい動作に思えますが、それでも異体字セレクタを無視してほしくない人にとってはかえってありがたくない機能かもしれません。

IVSの場合、互換性維持に(4)は必要なのでしょうか? とりあえず(4)を実装して将来(5a)(5b)に移行するとか?

390675c は IVS のみ対象にして SVS は対象外にした方がよいかもしれません。

[t-tk]

https://www.unicode.org/ivd/data/2022-09-13/IVD_Sequences.txt
によると

9022 E0100; Adobe-Japan1; CID+1133   一点しんにょう
9022 E0101; Adobe-Japan1; CID+8266  二点しんにょう
9022 E0102; Adobe-Japan1; CID+13408  一点しんにょう

5078.Adobe-Japan1-6.pdfを見てもCID+1133 と CID+13408 の違いがよく分かりません。そっくりです。

texmf-dist/fonts/cmap/adobemapping/mapping-resources-pdf/pdf2unicode/Adobe-Japan1-UCS2
によると
Version: 9.002 では
CID+1133 → U+9022
CID+13408 → U+9022

Version: 10.002 では
CID+1133 → U+9022 U+E0100
CID+13408 → U+9022 U+E0102

なので、IVSであっても互換性のためには 上記「(4) IVSを無視してフォントに U+9022 があれば U+9022 を出力する。」が当面必要と理解しました。
「(5a) U+9022 U+E0100, U+9022 U+E0102 があればそちらを出力する。さもなければ(5b) U+9022を出力する」が実現できたら移行する、という方針が妥当と思いました。

[h20y6m]

なので、IVSであっても互換性のためには 上記「(4) IVSを無視してフォントに U+9022 があれば U+9022 を出力する。」が当面必要と理解しました。

新しいAdobe-Japan1-UCS2で以前と同等の結果を得るために必要だと思っています。

異体字セレクタを無視してほしくない人にとってはかえってありがたくない機能かもしれません

そうかもしれません。無視した場合に警告を出力するとかでしょうか？

390675c は IVS のみ対象にして SVS は対象外にした方がよいかもしれません

たしかにそうですね。

---

とりあえず当面の方針はこんな感じでしょうか？

• SVSについて
  • CJK互換漢字に変換可能ならCJK互換漢字に変換する（U+9686 U+FE00 → U+F9DC に変換して出力する）
    • フォントにグリフがなかったら U+F9DC がない旨の警告で豆腐が出力される
  • CJK互換漢字に変換できなかったら今まで通り mapped to non-single Unicode characters の警告で豆腐が出力される
    • あるいはより具体的に異体字セレクタに未対応の警告を出力する・・・・・・？
• IVSについて
  • IVSを無視する（U+9686 U+E0102 → U+9686 を出力する）
    • IVSを無視した旨の警告を出力する・・・・・・？

さらに将来的に実現できそうであれば

• 先ずはフォントに U+9686 U+FE00 や U+9686 U+E0102 があればそれを出力する

という感じでしょうか？

---

5078.Adobe-Japan1-6.pdfを見てもCID+1133 と CID+13408 の違いがよく分かりません。そっくりです。

たぶん「三」の部分の上が短いか真ん中が短いかの違いですかね？

[t-tk]

新版で SVS 付きかつ互換漢字でないもので、旧版の割り当てが SVS無しになっているものもありました。
そうすると、互換漢字じゃないものも、「豆腐ではなく、SVS無しに割り当てる」のが、現在までの環境との互換性という観点では正解のようにも思えてきました。

「異体字セレクタに未対応の警告を出力しつつSVS無しに割り当てる」位がベストでしょうか。

---

旧割り当てが互換漢字への変換ではないもの。(見つけたものだけ。網羅はしていない。)

245 < <0278> <0030> CID+632 斜線付きゼロ 0
245 > <0278> <0030fe00>

7069 < <2024> CID+8228 斜線付きゼロ ０
7072 > <2024>

7584 < <22f5> <0030> CID+8949 斜線付きゼロ 90度回転
7587 > <22f5> <0030fe00>

7627 < <2379> <0030>
7627 > <2379> <0030fe00>

7829 < <25c9> <0030>
7829 > <25c9> <0030fe00>

7961 < <269a> <0030>
7961 > <269a> <0030fe00>

[h20y6m]

コメントするのを忘れていましたが、 h20y6m@060d39b で警告メッセージを入れてみました。

[t-tk]

ありがとうございます。
私は近々時間を作って試してみようと思います。

dvipdfm-x の cmap14 対応は、 tt_cmap.c を拡張していけばよくて、
cmap14 の形式はややこしいけれども
やりたいことは freetype2 の src/sfnt/ttcmap.{c,h} に実装されているのでマネすればよい、
というところまではたどり着きました。

チャレンジされる方はいらっしゃいますか?
意味不明で迷宮入りになる懸念はなさそうですが、手間が掛かりそうで。

[t-tk]

遅ればせながら
h20y6m@060d39b
を拝見しました。
二点ほど思ったことです。いかがでしょうか。

(1) 非漢字は?
変なことを言っていたようです。撤回します。

(2) バイナリーサーチの可能性は?
UC_Combine_CJK_compatibility_ideograph() の中の、ucv, usv を探してくるあたり、リニアサーチをバイナリーサーチにしないのかな、と少し思いました。
1000行ほどソート済みのテーブルで、実装の費用対効果は微妙ではありますが。

---

dvipdfm-x の cmap14 対応は気が向いたらぼちぼち手を付けてみようと思っています。