Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
h20y6m opened this issue Mar 11, 2023 · 25 comments

Comments

@h20y6m
Copy link
Collaborator

h20y6m commented Mar 11, 2023

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
Copy link
Collaborator

t-tk commented Mar 11, 2023

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

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

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

@aminophen
Copy link
Member

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

@aminophen
Copy link
Member

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

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

@t-tk
Copy link
Collaborator

t-tk commented Mar 11, 2023

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

@aminophen
Copy link
Member

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

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

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

adobemapping-230311

@aminophen
Copy link
Member

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

@h20y6m
Copy link
Collaborator Author

h20y6m commented Sep 10, 2023

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

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

  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
Copy link
Collaborator

t-tk commented Sep 18, 2023

異体字セレクタに 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
Copy link
Collaborator

t-tk commented Sep 18, 2023

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
Copy link
Collaborator Author

h20y6m commented Sep 20, 2023

なので、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
Copy link
Collaborator

t-tk commented Sep 20, 2023

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

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


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

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

7069 < <2024> CID+8228 斜線付きゼロ 0
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
Copy link
Collaborator Author

h20y6m commented Oct 1, 2023

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

@t-tk
Copy link
Collaborator

t-tk commented Oct 1, 2023

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

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

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

@t-tk
Copy link
Collaborator

t-tk commented Oct 29, 2023

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

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

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


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

@h20y6m
Copy link
Collaborator Author

h20y6m commented Oct 31, 2023

(2) バイナリーサーチの可能性は?

h20y6m@ca5e228 でやってみました。
……が、ほとんど効果はないようです。
UC_Combine_CJK_compatibility_ideograph() は手元の環境で 2 倍程度高速になりますが、
全体に占める時間が 1% にも満たないようで誤差以上の差が出ませんでした。

@t-tk
Copy link
Collaborator

t-tk commented Nov 15, 2023

update ありがとうございます。動作確認しました。

誤差以上の差が出ません

そうでしたか。
私の好みでは、 h20y6m@ca5e228 を TeX Live svn に入れてよいと思います。
警告メッセージも、今のように、あった方がよいと思います。
あとは ChangeLog を書いてコミットするだけですが、どうされますか?
@h20y6m さんがアカウントを取得されたとのことなので、ご自身でなさってもよいですし、私が代理コミットしてもよいです。

h20y6m added a commit to h20y6m/tex-jp-build that referenced this issue Nov 18, 2023
@h20y6m
Copy link
Collaborator Author

h20y6m commented Nov 18, 2023

せっかくなので自分でコミットしてみようかと思います。(SVN使うのは10年ぶりくらいかな……)

h20y6m@eedea05
で過去のログを参考にChangeLogを書いてバージョンも上げてみました。

@h20y6m
Copy link
Collaborator Author

h20y6m commented Nov 18, 2023

TeX Live svn にコミットしました。
https://tug.org/svn/texlive?revision=68889&view=revision

@norbusan
Copy link
Member

@h20y6m svnにコミットをありがとうございます。githubのtexlive-sourceのgit mirrorの更新のため、svnユーザからメールアドに書き換えないといけません。使用してほしいメールアドをお伝えください。よろしくお願いいたします。

@h20y6m
Copy link
Collaborator Author

h20y6m commented Dec 16, 2023

format 14 サブテーブルを読んで Variation Sequences を変換するに手を付けてみました。 https://github.com/h20y6m/tex-jp-build/tree/dvipdfmx_cmap14
とりあえずは動いているような感じです。

format 14 サブテーブルは他のサブテーブルとだいぶ性質が違う感じがするので、実装を他の tt_cmap とは分けたほうがいいのかなぁ……と迷っています。

@h20y6m
Copy link
Collaborator Author

h20y6m commented Jan 6, 2024

h20y6m@b557cb9 で想定通りに動いていそうです。

Adobe-Japan1-UCS2 で UVS 付きにマップされていた場合以下の順でグリフを検索します。

  1. フォントが format 14 cmap サブテーブルを持っていたら、format 14 cmap サブテーブルから検索する。
  2. CJK互換漢字に変換可能なら、CJK互換漢字に変換して検索する(SVS)。
  3. UVSを無視して検索する。

それと、以下のように動作を変更しています。

  • CJK互換漢字に変換してグリフが見つからなかった場合はUVSを無視した検索もする。
  • UVSを無視してもグリフが見つからなかった場合は Ignored Variation Selector ... の警告は出さない。

前者はIVSや互換漢字以外のSVSと挙動をそろえたい、
後者は望まない字形で出力されたかもしれないという警告なのでそもそもグリフが見つからない場合は意味がない
という考えからです。


いちおう、UniJIS2004-UTF16-H (1.022) で出力できる文字について、古い Adobe-Japan1-UCS2 (9.002) と IPAex 明朝フォントで、TeX Live 2023 の dvipdfmx (20220710) と同じ結果が得られることを確認しています。
万一の時は Adobe-Japan1-UCS2 を古いものに差し替えることで以前の動作に戻せるはずです。

あと、新しい Adobe-Japan1-UCS2 (10.002) と IPAex 明朝フォントで、VS付になった文字以外にも出力できなくなったもじがそれなりにあるようですが、これは仕方ないですよねぇ……。(ざっと見た感じ UniJIS2004-UTF16-H → Adobe-Japan1-UCS2 で元の Unicode に戻るようになった文字がほとんどのようなので、本来 IPAex 明朝フォントで出力できない文字なんだと思います。)

@t-tk
Copy link
Collaborator

t-tk commented Feb 10, 2024

ご検討ありがとうございます。
こちらの手元でご提案の仕様をチェックするのは、私がたどり着けない感じがするので、以下感想だけですみません。

前者はIVSや互換漢字以外のSVSと挙動をそろえたい、
後者は望まない字形で出力されたかもしれないという警告なのでそもそもグリフが見つからない場合は意味がない

そうですね。賛成します。
念のためですが、
「UVSを無視して検索してグリフが見つかった場合は警告メッセージを出す」
で合っていますか?

もう大丈夫そうなので TeX Live svnにコミットしてよいと感じます。
#46 は、今年はまだだと思っています。

@h20y6m
Copy link
Collaborator Author

h20y6m commented Feb 10, 2024

TeX Live svn にコミットしました。 r69764

念のためですが、
「UVSを無視して検索してグリフが見つかった場合は警告メッセージを出す」
で合っていますか?

はい、その通りです。

#46 は、今年はまだだと思っています。

あちらはまだまだ考えないといけないことが山積みですね。


あとは、(TL2023 frozen 後に) adobemapping を更新すればこちらは完了ですかね。
(それと texjporg/ptex-fontmaps#32 も)

@t-tk
Copy link
Collaborator

t-tk commented Mar 20, 2024

あとは、(TL2023 frozen 後に) adobemapping を更新すればこちらは完了ですかね。

TL2024がリリースされたようです。
状況が分からないのですが、これ(adobemappingの更新依頼)って実施していましたか?

@aminophen
Copy link
Member

adobemapping ごめんなさい,私の管轄です。時間がなくて出来ていませんでした。更新依頼というか,私が CTAN に上げれば自動で入ります。もうしばらくお待ちください。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants