[upTeX+dvipdfmx] 異体字セレクタ、Unicode合成文字 #46
Comments
簡単なコメントだけですが，検討なさっている通り，どこまでやるかで実装方法が変わりそうですね。 まず，絵文字，というのがどこまでなのかよくわかっていません。カラー絵文字を PDF に埋め込めるようにしたいという話なのでしょうか？ 補足：カラー絵文字をサポートした既存エンジンとして pTeX-ng があり，これは upTeX に極めて似ているため，一定の参考にはなりそうです。 ＃ 私の理解では，pTeX-ng は「upTeX + e-TeX の改変版で作った特殊な DVI」を「ライブラリ様式に再構成された dvipdfmx ＝ libpdf」で PDF を直接出力するように見せているというモノ。
ただ，この場合は dvipdfmx 部分が主に freetype2 や libotf に新たに依存しています。ライブラリを増やして良ければ，案外簡単に実現できるのかもしれませんが，よくわかりません。 |
|
私がupTeXの基本的な機能として拡張したいのは、「絵文字をグリフとして持っているフォントを使ってフォントとしてpdfに埋め込む」場合です。図形として埋め込むことは関心の外にあります。
イメージとしては、絵文字をグリフに持ちVS等を使って呼び出せるように実装されているフォントを用いて、そのフォントのUTF-8のシーケンスに合致したグリフをpdfに埋め込むようなことです。 Unicode のシーケンスで分類すると
1は既に既存のupTeX環境で使えるはずです。2は漢字のVS=IVS と同様のやり方で対応出来るような気がします。 |
|
お勉強、備忘録を兼ねて書きます。
と纏められると思います。可変長のコードポイントの配列で表される塊を1つのグリフとして扱いたいという点では共通なので、その操作は共通で処理したい。
改造量が多くdviwareの対応のための開発が重くなり、結果としてdvipdfmx以外では新仕様に追従困難になるかもしれない、拡張dvi命令を知らない従来のdviwareでは拡張dvi命令を含む新dviを丸っきり処理できなくなる、など短所もあります。 |
IVDのテーブルを調べてみたところ、 異体字セレクタの種類が最多になっている文字は |
|
2022年9月に Ideographic Variation Database の新版が出ていました。 31350 E0100; Adobe-Japan1; CID+19130 なので計画を若干修正。 |
|
npTeX (#150) も考えたときに，どこまで「0x110000 以上の内部コード」を許容するかについて悩んでいます．#150 で h20y6m さんが
と書かれているように，仮に「0x110000 以上の文字トークン」を許さないことにすると……
t-tk さんの元コメント に便乗して，別の案を挙げてみます．
|
現状の (e-)upTeX は 0x110000 以上は「文字ノードとしては存在するが，文字トークンとしては存在しない」で一貫しています（\kansujichar や \Uchar はトークン生成時に mod 0x110000 で落とす）。OTF パッケージ対策は文字ノードさえ出来れば良く，これで十分だったのでしょう。異体字セレクタだとそうはいかない，と言われると確かに…。 %#!euptex
% ノード
\chardef\X="112603 \show\X % => \char"112603
% トークン
\kansujichar1="112603 \showthe\kansujichar1 % => 9731 = "2603
\expandafter\show\kansuji1 % => kanji character ☃
\expandafter\show\Uchar"442603 % => kanji character ☃
\endメモ: mod 0x110000 の処理は |
書記素ごとにループする
ここがちょっと気になっていています。 |
|
コメントありがとうございます。 MJ+ というのは知りませんでした。 また、下記のように現計画の延長線上で、 U+0hhhhの ～VS80, U+2hhhhの ～VS64 は賄えると思います。 絵文字の肌の色とか顔の向きとか、謎かつ予測不可能な進化についていくことは難しそうですが。 |
|
少し気になったのですが、VS付の文字について、 |
私は必要ないと思います。 |
|
#155 で 'cmap' Subtable Format 14 を読んで VS に対応するのをやったのでこちらも少し実験してみています。
が VF を作れば疑似的に実験できそうだったので、IVD_Sequences.txtを元に Unicode 私用面に Adobe-Japan1（0xF0000+CID）と Moji_Joho（0x100000+MJ番号）の異体字を 0x800000--0xFFFFFF にマップするVFを生成するスクリプトを作ってみました。 実際にやってみると また、実際に VS 付きの文字コードからグリフを検索する方法ですが、VS を使う場合フォント map は CMap として unicode を指定する場合の処理になるのではないかと思います（CIDに変換するわけにはいかないと思うので）。 それから、ToUnicode CMap をちゃんと作るのも必要になります。たぶん cmap Subtable Format 4/12 から逆引きで作っているのですが（たぶん tt_cmap.c の 【追記】 |
|
https://github.com/h20y6m/tex-jp-build/tree/dvipdfmx_uvs_experiment_1 を拝借しつつ、触り始めています。
この問題ですが、 4ed8031 でよいように思います。 |
|
いろいろ検討した結果、文字コードは以前の構想と少し変えました。以下で確定のつもりです。 |
|
現在の試作品はこちらです。
ここは解消しています。
現状のコードは、最大 U+10FFFF までは JFM を参照、それ以上の文字コードは chartype 0番を参照になっていると思います。ルックアップテーブルは巨大化していません。まだまだ節約の余地はあるのは確かです。
今回の案では、VSの値 + ユニコードスカラー値の正規の値、という組み合わせの独自の4byteのバイナリーコードで扱うことになります。
現状のテストではまだフォールバック機能はありませんが、DVIコードから簡単に基底文字が得られるので、フォントの検索結果を見てからフォールバックする機能の実装は容易と思います。
この辺はよく分からないのでノーコメントです。
非常に参考になっています。ありがとうございます。 |
|
3byte の内部トークンの文字コードから 4byteのDVIコードへの変換は、ptexencの中で、DVI出力の直前に行っています。 現状の試作品は、uptex で テストを |
|
いろいろ検討した結果、文字コードを再び変えました。今度こそ確定のつもりです。 |
|
{,e}uptex の方は、kcatcode 20 modifier を新設しました。 基底文字 + modifier の順に入力バッファに現れた場合、内部トークンに変換する際に基底文字のトークンの文字コードを、今回の 3バイトの内部トークンの文字コードに書き換える。 例えば、<U+8279 U+FE00> の文字は、以下のどれでも出力可能。 `\kchar"408279`
`\kchar"8279\kchar"FE00`
`艹︀`
`\Uchar"8279\Uchar"FE00` |
|
実装についてまとめます。
|
|
omfonts ver 2.2 r71118 |
ref: #28 texjporg/tex-jp-build#46 https://www.unicode.org/ivd/data/2022-09-13/IVD_Sequences.txt require: * ptexenc ver 1.5.0/dev TeX Live svn r71091 * upTeX ver 1.35, r71143 * omegafonts (omfonts) ver 2.2, r71118 * dvipdfm-x ver 20240429, r71117
|
begin-end の対応がずれていたのを 320633c で修正しました。 |
|
まだ全然理解できていませんが、
という理解であっていますか？ TeX 言語から見た時の変化は
ほかにありますか？ |
|
コメントありがとうございます。
これは yes です。ただし、以前からこれは同じだったはず。
少し書き足しました。
これは yes です。以前からと同じですが、0x408279 に意味があるところに今回新規のところと思います。
これは yes です。そのように意図しています。
これは、あまり考えていなかったのですが差し支えありますか? |
|
変体仮名を upTeX 1.35 + dvipdfmx 20240427 + Noto Hentaigana font v1.000 で試しています。
IPAmj明朝フォントだとずれませんでした。Noto Hentaigana fontの所為?
|
これについては以下のパッケージが影響を受けそうなので TL2025 までに対応してもらう必要がありそうです。 （kcatcode=20 が有効かどうかの判定方法は？
これらの展開結果が2トークンになるのはちょっとびっくりする結果かもしれません。
Noto Hentaigana font は vmtx を持っていないみたいなので縦組みはダメそうですね。 |
これには軽い衝撃を受けました。 |
upTeX+dvipdfmx で異体字セレクタ等を使えるようにしたいと考えています。
しかし知らないこと不勉強なことも多く、どのくらい開発のハードルが高いのかも分かっていません。議論にお付き合いいただけると助かります。
実装案1,2のいずれにせよ、dvipdfmxの拡張は要りそうです。dvips+(distiller or ghostscript)の場合は分かりません。
実装案1は、最近実現したばかりのJFM拡張を利用します。IVSや仮名の濁音までは対応できそうです。反面、携帯電話の絵文字の一部"U+0023 U+20E3"のようにASCIIから始まるような場合は処理が困難です。
実装案2は、upTeXの既存の方法(入力はptexencで頑張る。upTeXエンジンはフォントの情報を持たずCJKのグリフ1個として処理する。dviwareはフォントに依存する処理を頑張る)と整合します。実装としては筋がよいと感じ、最終的にはここまで持って行きたいです。
とりあえず、実装案1でdvipdfmxの拡張をして、次に実装案2を進めるという2段階の開発でも良いかなと思います。
実装案2では、IVSのテーブルunicode.orgのIVDは巨大(2017-12-12現在29303字)なので、ptexencの中にハードコードすることは気が進まないなどの課題もあります。
Variation Selectorを扱うためには、'cmap' Subtable Format 14 を読み出せばよいそうです。
参考: appleのところ, microsoftのところ
現状のdvipdfmxには実装されていないようです。
内部のことは全然知らないのですが、tt_cmap.c に'cmap' Subtable Format 4, 12 を扱う部分があるのでそこを拡張すれば良いと想像しています。
しかし、dvipdfmxの中身はまるで判らないので私にとっては高い壁です。
何か、ご意見やアドバイスなどがあればお願いします。
The text was updated successfully, but these errors were encountered: