\ucs and \toucs #121

h-kitagawa · 2021-06-20T05:14:01Z

pTeX に \ucs（もともとは upTeX にあったもの，Unicode 値→内部コード）と \toucs（内部コード→Unicode 値）を実装しました．
ASCII の範囲 (0--255) はそのまま通すようにしています．

aminophen · 2021-06-20T05:20:40Z

ありがとうございます。\show\toucs が \ucs になっていそう？

ちょっといま出先なので，この Pull Request の背景については帰ってきたら書きます。 → #122

h20y6m · 2021-06-20T05:58:32Z

\ucs の存在だけで upTeX と判定するコード

plcore, ifptex, minijs, okumacro, jlreq 辺りでしょうか。

ASCII の範囲 (0--255) はそのまま通すようにしています．

\ucs は 128--255 の範囲にも和文文字（「×」 U+00D7 等）が含まれます。

aminophen · 2021-06-20T06:38:55Z

ASCII の範囲 (0--255) はそのまま通すようにしています．

\ucs は 128--255 の範囲にも和文文字（「×」 U+00D7 等）が含まれます。

内部コードが euc/sjis の場合は~~該当しなくなります。~~ → いやこれを和文文字コードに変換しないといけない話ですね。すみません。
内部コードが uptex の場合は該当しますが，結果的に恒等変換でよいはずです。

t-tk · 2021-06-20T08:09:38Z

pTeX (EUC/SJIS) の場合、 \ucs で求めるものは引数を内部コード(EUC/SJIS)に変換したものが期待されると思います。
仮にU+0080..00FF の範囲を欧文優先で変換するという思想だと仮定して 0x80 -- 0xFF の範囲をそのまま素通ししたとしても、pTeX の 8bit 欧文のエンコードは通常 T1 等であり、UCS とは異なる文字コードになりますよね。
そうすると意味的な整合が取れていないように感じます。

\ucs の 0x80 -- 0xFF の範囲も可能ならばEUC/SJIS に変換する。EUC/SJISに変換できない場合は 0x100以上と同様

でよいように思います。
「×」U+00D7 を欧文TeX の 0xD7 だと思っても役には立たず、和文のEUC-JPの 0xA1DF になってくれた方が役立つような気がします。
逆に、素通しした方が便利な場面はありますか?

t-tk · 2021-06-20T08:15:32Z

ASCII の範囲 (0--255) はそのまま通すようにしています．

一応突っ込んでおきますが、ASCIIの範囲は (0--127) ですよね。

h-kitagawa · 2021-06-20T09:15:05Z

0x80--0xFF の和文文字についてあまり考えていませんでした，すみません．

\ucs の 0x80 -- 0xFF の範囲も可能ならばEUC/SJIS に変換する。EUC/SJISに変換できない場合は 0x100以上と同様

f5f90b9 で引数が 255 以下の特別扱いをほとんど行わないようにしました．

内部コード uptex では \ucsk, \toucsk (0<=k<=255) は結果的に恒等変換．
内部コード euc/sjis では，\toucsk (0<=k<=255) はみな 0 を返す．
\ucs ではできるだけ EUC/SJIS に変換し，ダメなら 0 を返す
上で「ほとんど行わない」としたのは，fromUCS(0) が JIS 222F（最初の未定義位置）を返す一方で，\ucs0 は 0 を返すようにしたためです．

t-tk · 2021-06-20T10:52:09Z

fromUCS(0) の返り値は JIS 222F が適切でしょうか?

ptexenc/kanjicnv.c を眺めていたら、JIStoSJIS() で計算不能な場合は 0x813f を返すようにしてありました。

tex-jp-build/source/texk/ptexenc/kanjicnv.c

Line 78 in 518774f

return 0x813f;

同様に今回も
JIS 0x2120, EUC 0xA1A0, SJIS 0x813F, 1区0点にするのはいかがでしょうか。

JIS 0x222F は、JIS X 0213 では文字が定義されているのと、単純に数値としてJISの有効範囲と判定するソフトの場合に思わぬ動作をする懸念があるかと思います。杞憂かもしれませんが。

h-kitagawa · 2021-06-20T12:00:26Z

fromUCS(0) の返り値は JIS 222F が適切でしょうか?

私としては「和文の内部コードの範囲ではない」ことが明確にわかるという意味で（JIStoSJIS() についても）0 を推しますが，JIS 0x2120 に統一するというのもありだと思います．

現行で 0x222F になるのは，unicode-jp.c の UCS2toJISnative() に 0 を渡したときに，UnicodeTbl 中の最初の 0 のエントリを拾ってしまうことによるようです：

tex-jp-build/source/texk/ptexenc/unicode-jp.c

Lines 115 to 122 in 518774f

    
           for (i=0; i<MAXJIS; i++) { 
        
               for (j=0; j<94; j++) { 
        
                   if (UnicodeTbl[i][j] == ucs2) { 
        
                       return HILO(i, j) + 0x2121; 
        
                   } 
        
               } 
        
           } 
        
           return 0;

for ループの前に

if (ucs2==0) return 0; /* or 0x2120 */

を入れれば良いと思います．

aminophen · 2021-06-21T07:38:08Z

master に入った b443b80

ptexenc/unicode-jp.c: changed the returned value of UCS2toJISnative(0) from 0x222F to 0

これは「fromUCS(0) の返り値を JIStoSJIS() などに合わせて JIS 0x2120 つまり1区0点に統一する」ということでよいでしょうか。問題なければ後ほど svn にコミットしておきます。

h-kitagawa · 2021-06-21T08:29:11Z

b443b80 は fromUCS(0) の値を 0 にするものです．UCS2toJISnative(0)=0 → UCS2toJIS(0)=0 → fromUCS(0)=0 となります．

tex-jp-build/source/texk/ptexenc/ptexenc.c

Lines 381 to 387 in b443b80

    
           long fromUCS(long kcode) 
        
           { 
        
               if (is_internalUPTEX()) return UCStoUPTEX(kcode); 
        
               kcode = UCS2toJIS(kcode); 
        
               if (kcode == 0) return 0; 
        
               return fromJIS(kcode); 
        
           }

tex-jp-build/source/texk/ptexenc/unicode-jp.c

Lines 265 to 266 in b443b80

    
           /* second: UnicodeTbl[][] */ 
        
           return UCS2toJISnative(ucs2);

なお，\kuten で範囲外の値 ("089F) を与えると，内部コード euc では -1，sjis では 0x813F が返ってきます．せっかくだからこの辺も統一したいところです．
(6/21 19:08 edit: 実験用 shell script を追加（もっと追記したい））

aminophen · 2021-06-21T08:57:45Z

fromUCS(0) の値を 0

了解しました。

\kuten で範囲外の値

（範囲外の値が未定義動作なのは承知の上で，それでも）『この値が返ってきたら範囲外だったことが一目で判別できる』という状態のほうが，expl3 のようなプログラミング言語を実装する側にとって望ましい状態であると思います。せっかくなので統一するという方向に賛成します。

ところで kanji.c の is_char_kanji() が 0x10000 以上を受け付けてしまうのも未定義動作な気がします。上限を max_cjk_val で縛っておいた方が無難に思います。

aminophen · 2021-06-23T14:41:31Z

\ucs（もともとは upTeX にあったもの，Unicode 値→内部コード）
\toucs（内部コード→Unicode 値）

動作確認しました。副次的効果として「is_char_kanji でエラーが出ないが，JIS X 0208 外のためサポートされない文字コード」も弾ける \if〜文を \ifnum\ucs\toucs<数字>=<数字> で実現できました。これで「pTeX がサポートする JIS X 0208 の和文文字が 6,879 字あること」を TeX 言語の範囲内で確認できるようになりました ;-)

遊んでみた例: "Check if a number is in the range of JIS X 0208" (Gist)

「Bad character code のエラーを出すことなく，和文文字の内部コードとして有効かどうか判定する」という \if〜文（これは is_char_kanji と等価）が \iffontchar\jfont<数字> で実現できた (#77) のと合わせて，何かに使えそうです。

aminophen · 2021-06-24T13:34:23Z

実験用 shell script を追加（もっと追記したい）

拝見しました。一部だけですがコメントしておきます。

\typeout{\kuten"015F} %" 本来は不正のはずだが，

これは以下の行の > を >= が正せば良いと思います。

tex-jp-build/source/texk/ptexenc/kanjicnv.c

Lines 94 to 101 in b443b80

    
           int KUTENtoJIS(int kcode) 
        
           { 
        
               /* in case of undefined in kuten code table */ 
        
               if (HI(kcode) == 0 || HI(kcode) > 95) return -1; 
        
               if (LO(kcode) == 0 || LO(kcode) > 95) return -1; 
        
               return kcode + 0x2020; 
        
           }

内部コード EUC の時

  \typeout{\sjis"817F}%" 本来は不正のはずだが．

SJIS 0x817F (不正) --> EUC-JP 0xA1DF (×: 正当)

内部コード SJIS の時

  \typeout{\euc"2422}%" 本来は不正のはずだが，
  \typeout{\euc"A2A0}%" 本来は不正のはずだが，
  \typeout{\euc"A29F}%" 本来は不正のはずだが，

EUC 0x2422 (不正) --> SJIS 0x82A0 (あ: 正当)
EUC 0xA2A0 (不正) --> SJIS 0x819E (◇: 正当)
EUC 0xA29F (不正) --> SJIS 0x819D (◎: 正当)

不正なコードが内部コードとして正常な範囲に化けてしまうので，計算がまずいのでしょうね…。

[edit] コメント欄にパッチ案を載せてみました。

zr-tex8r · 2021-06-25T05:03:12Z

今更なんですけど……

b443b80 は fromUCS(0) の値を 0 にするもの

(u)pTeXの一部のプリミティブの「文字コード」の引数は和文と欧文を兼ねます。もし従来の動作を変更するのであれば、
「従来は不正コード値であったはずが改修後は0になってしまう」
というパターンが発生していないか、が気になります。

aminophen · 2021-06-25T10:57:39Z

「従来は不正コード値であったはずが改修後は0になってしまう」というパターンが発生していないか

例のコミット b443b80 は UCS2toJISnative(0)=0x222F だったものを 0 にする物，とあります。従来返っていた JIS 0x222F という値は JIS X 0208 には含まれませんが JIS X 0213 では文字が定義されています。

内部コードEUCの時 41647 = 0xA2AF となり is_char_kanji は TRUE が返る
内部コードSJISの時 33197 = 0x81AD となり is_char_kanji は TRUE が返る

ということから，従来も ! Bad character code. にはなりませんでした。（先日触れた「is_char_kanji でエラーが出ないが，JIS X 0208 外のためサポートされない文字コード」に該当）

…回答になっているでしょうか？

h20y6m · 2021-06-25T12:40:12Z

[edit] コメント欄にパッチ案を載せてみました。

不十分なところを見つけたのでコメントに書きました。

zr-tex8r · 2021-06-25T21:06:40Z

…回答になっているでしょうか？

その点は了解です。

ただ、改めて考え直してみると、自分が懸念しているのは
「従来の動作（エラーも含めて）が変わってしまう」
ということよりむしろ
「無効な場合に0を返そうとしているけど、文字コードが欧文としても解釈される状況では、0は無効ではないし、また（JIS X 0208の0x222Fのような）”実際には使われない”コードでもなくて、有効な文字コードである」
という点である気がしました。

aminophen · 2021-06-25T21:44:49Z

「無効な場合に0を返そうとしているけど、文字コードが欧文としても解釈される状況では、0は無効ではないし、また（JIS X 0208の0x222Fのような）”実際には使われない”コードでもなくて、有効な文字コードである」

何を返すのが妥当か，ですね。無効な (unsupported) 文字コードを与えた場合の挙動は，現状で

fromUCS(0) が JIS 222F（最初の未定義位置）を返す

なお，\kuten で範囲外の値 ("089F) を与えると，内部コード euc では -1，sjis では 0x813F が返ってきます．せっかくだからこの辺も統一したいところです．

と指摘があるとおりバラバラです。

何を返すのが妥当か，上の方で出てきた値を一覧にしてみます。

最初の未定義位置 JIS 0x222F, EUC 0xA2AF, SJIS 0x81AD
- 和文文字コードとして有効だが，JIS X 0208 では未定義，JIS X 0213 では定義。
- 発生状況: 従来の UCS2toJIS(0)
0
- 欧文文字コードとしては有効，pTeX の和文文字コードとしては無効（Bad character code エラー），upTeX の和文文字コードとしては有効。
- 発生状況: 改修した UCS2toJIS(0)
-1
- 文字コードとして無効（Bad character code エラー）
- 発生状況: KUTENtoJIS(不正)→JIStoEUC(-1)
1区0点 JIS 0x2120, EUC 0xA1A0, SJIS 0x813F
- 文字コードとして無効（Bad character code エラー）
- 発生状況: JIStoSJIS(不正)

何が無難でしょうか。

aminophen · 2021-06-25T22:01:56Z

個人的には，不正コード入力は全て -1 にするのがわかりやすいと思っています。先日のパッチ案もその方向性です（UCS2toJIS には未着手，また「不十分なところ」もあり，また3バイト以上の文字コードも未考慮ですが）。ただ，今までエラー出なかったものがエラーになる危惧はあります。

→ [edit] パッチ案を https://github.com/texjporg/tex-jp-build/tree/kitagawa_toucs-1 へ（返り値を -1 にするという意味でブランチ名に -1 を付けた）。3バイト以上の文字コードは未考慮。

zr-tex8r · 2021-06-26T06:07:33Z

少なくとも「和文文字コードとして不正な値」を意図しているなら「−1」がよさそうですね。

h20y6m · 2021-06-26T08:50:40Z

パッチ案を https://github.com/texjporg/tex-jp-build/tree/kitagawa_toucs-1 へ

pTeX で UTF-8 のファイルを入力したときに内部コード (sjis/euc) に変換できない文字が ^^ff^^ff^^ff^^ff に化けてしまいますね…

以下のところを j == -1 にすればよさそうです。

tex-jp-build/source/texk/ptexenc/ptexenc.c

Lines 676 to 677 in d439ece

    
           j = (u != 0) ? toBUFF(fromUCS(u)) : 0; 
        
           if (j == 0) { /* can't represent (typically umlaut o in EUC) */

他にも同様の問題が無いか調べる必要がありそうです。

ところで upTeX に sjis/euc のファイルを入力したときに変換できない文字（例えば SJIS 0x8740 等）はどうするのがいいのでしょうか？
（現状は JIStoUCS2native が 0 を返すので ^^@ に変換されて ! Text line contains an invalid character. になるようですが…）

aminophen · 2021-06-26T11:08:24Z

pTeX で UTF-8 のファイルを入力したときに内部コード (sjis/euc) に変換できない文字が ^^ff^^ff^^ff^^ff に化けてしまいますね…

ご指摘ありがとうございます。全然テストしていなかったので気づきませんでした。さらに悪いことに，試しに https://github.com/texjporg/texjporg-testing のテストケース（cur-plain, cur-latex に置いてある標準ログ .tlg は，現時点の TeX Live svn r59701 で生成したものです）を走らせてみると，内部コード sjis の時に cur-plain/filename.lvt のテストが Segmentation fault: 11 しました。かなり良く検査しないと危ないですね…。

以下，関係ありそうなところ：

tex-jp-build/source/texk/ptexenc/ptexenc.c

Lines 616 to 617 in d439ece

    
           i = toBUFF(fromUCS(i)); 
        
           if (BYTE2(i) != 0) buffer[last-3] = BYTE2(i);

fromUCS() が -1 を返すと？

tex-jp-build/source/texk/ptexenc/ptexenc.c

Lines 807 to 808 in d439ece

    
           i = fromJIS(HILO(i,j)); 
        
           if (i == 0) i = fromUCS(U_REPLACEMENT_CHARACTER);

fromJIS() が -1 を返すと？

aminophen · 2021-06-27T03:19:13Z

ptexenc のローレベルな関数で -1 を返すと，あちこちに影響が出て追跡がしんどい…。

~~アスキー文字に対して fromDVI() が恒等変換だった~~（←[修正] これは内部 uptex の時；内部 euc では元々 0x8080 を足していた）のが -1 を返してしまう fromDVI() の挙動変化 → DVIware にも影響

tex-jp-build/source/texk/dviout-util/dvispc.c

Lines 1914 to 1924 in 7068ae9

    
           if(f_jstr){ 
        
               wch = fromDVI(code); 
        
               if (is_internalUPTEX()) wch = UCStoUTF8(wch); 
        
               imb = 0;  memset(mbstr, '\0', 4); 
        
               if (BYTE1(wch) != 0) mbstr[imb++]=BYTE1(wch); 
        
               if (BYTE2(wch) != 0) mbstr[imb++]=BYTE2(wch); 
        
               if (BYTE3(wch) != 0) mbstr[imb++]=BYTE3(wch); 
        
               /* always */         mbstr[imb++]=BYTE4(wch); 
        
               fprintf(fp_out, 
        
                   (f_dtl&DTL_CHAR2)?" %u \"":" 0x%x \"", code); 
        
               fputs2(mbstr, fp_out);

今回やりたいのは「expl3 のプログラミングレベルで，不正な文字コードをそれと分かりやすくする」ことが目的なので，(e-)(u)pTeX のプリミティブの返り値を調整する程度に止めようと思います。

ptexenc の文字コード変換関数の返り値が「1区0点」又は「最初の未定義文字」だったものを「0」に統一する。 → 明らかに和文文字でないとわかる。
ptex-base.ch などの WEB 側で「0 なら -1 を返す」とする。

これでいこうと思います。

aminophen · 2021-06-27T08:28:46Z

ptexenc の文字コード変換関数の返り値が「1区0点」又は「最初の未定義文字」だったものを「0」に統一する。 → 明らかに和文文字でないとわかる。

ptex-base.ch などの WEB 側で「0 なら -1 を返す」とする。

https://github.com/texjporg/tex-jp-build/tree/kitagawa_toucs-invalid (5ead93a) でこの方針としました。

ところで upTeX に sjis/euc のファイルを入力したときに変換できない文字（例えば SJIS 0x8740 等）はどうするのがいいのでしょうか？
（現状は JIStoUCS2native が 0 を返すので ^^@ に変換されて ! Text line contains an invalid character. になるようですが…）

については「現状維持」になります。

\jis, \euc, \sjis で3バイト以上の文字コードは不正なので，ptexenc で弾くようにしました。
コード無変換の場合，すなわち「内部コード euc の時の \euc」「内部コード sjis の時の \sjis」では何もチェックを行いません（Bad character code，3バイト以上も素通り）。

追記：upTeX では \ucs"0 を -1 でなく 0 にすべき → 3d8183b で修正

aminophen · 2021-06-28T12:49:48Z

3d8183b の実装を upTeX で以下のソースに通してみると

\message{\jis"6 }% => -1
\chardef\X=\jis"6 \relax % => ! Bad character code (-1).
\kansujichar1=\jis"6 \relax % => ! Invalid KANSUJI char ("6).
\bye

のように Invalid KANSUJI char のエラーで出る文字コード値が非直感的なので，もう少し考えます。

（補足）特に「upTeX で」と書いたのは，upTeX では 0--127 も和文文字コードとして正当だから不自然に見える，という意味。（upTeX では 0--127 の和文文字トークンが存在しないので，生成するのは欧文トークンである: #36 参照）

（追記）いや特に \jis"6 に限らず「不正な文字コード」を与えると Invalid KANSUJI char ("6) が出ていて，変だな…。

aminophen · 2021-06-28T13:41:56Z

「不正な文字コード」を与えると Invalid KANSUJI char ("6) が出ていて変

これは今回の issue とは関係なく print_hex() 関数に -1 を渡すと "6 が出るようです。

パッチを当てる前でも

\inhibitxspcode-1=3
\prebreakpenalty-1=120
\kansujichar1=-1

などで

! Invalid KANJI code ("6).
! Invalid KANJI code for prebreakpenalty ("6).
! Invalid KANSUJI char ("6).

となりました。tex.web にも

@ Hexadecimal printing of nonnegative integers is accomplished by |print_hex|.

@p procedure print_hex(@!n:integer);
  {prints a positive integer in hexadecimal form}

とあるので，負の値かもしれないところに print_hex() を使うこと自体がまずいようです。

→ 81ad436 で修正。

aminophen · 2021-06-28T14:36:38Z

\ucs の存在だけで upTeX と判定するコード

plcore, ifptex, minijs, okumacro, jlreq 辺りでしょうか。

plcore

texjporg/platex@34de126 で対処。

→ ptex-manual も追随完了。

ifptex

[TODO] マージした時点でZRさんに対応をお願いします。（pTeX を upTeX だと誤判定するのみならず，返り値を -1 に変更した影響で upTeX でも ! Invalid KANSUJI char (-1). のエラーが出るようです）

minijs, okumacro

texjporg/jsclasses@384aa1a で対処。

jlreq

[TODO] マージした時点でabenoriさんに対応をお願いします。 → abenori/jlreq#86

aminophen · 2021-06-29T03:45:37Z

https://github.com/texjporg/tex-jp-build/tree/kitagawa_toucs-invalid (95835d3) での仕様をまとめます。

追加プリミティブについて

pTeX: upTeX にあった \ucs を pTeX にも移植。「Unicode値→内部コード」への変換を行う。
pTeX/upTeX: \toucs を追加。「内部コード→Unicode値」への変換を行う。

不正な文字コード（変換できない場合など）の処理

文字コード変換が不要なケース
- 内部 euc における \euc，内部 sjis における \sjis，内部 uptex における \ucs および \toucs … (*)
- 恒等変換となる。不正な文字コードを与えてもそのまま通る。
文字コード変換が必要なケース
- 上記 (*) 以外のケース。
- \jis, \sjis, \euc, \kuten, \ucs に不正な値を与えると -1 を返す。
- \toucs に不正な文字コードを与えると 0 を返す。

実装

ptexenc (ptexenc.c, kanjicnv.c, unicode.c) の関数
- 文字コード変換が不要な場合は恒等変換。必要な場合で不正な文字コードなら 0 を返す。
ptex-base.ch の実装
- ptexenc に従う。ただし \jis, \sjis, \euc, \kuten, \ucs の返り値が 0 の場合は -1 を表示。
uptex-m.ch の実装
- ptexenc 及び ptex-base.ch に従う。ただし，内部コード uptex の時の \ucs0 は（ptex-base.ch が無条件に -1 を表示しようとするが，ここは無変換とすべきなので）0 を表示。

…こんな感じに整備したつもりですが「ブランチの実装が仕様どおりになっていない」或いは「仕様がまずい」等あればご指摘いただけるとありがたいです。

aminophen · 2021-06-29T03:53:05Z

追記：私がまだ迷っているのは

文字コード変換が不要なケース … 恒等変換となる。不正な文字コードを与えてもそのまま通る。

→ チェックを入れるべきか？

文字コード変換が必要なケース … \toucs に不正な文字コードを与えると 0 を返す。

→ これも -1 を返すべきか？

→ \toucs-1234 等も 0 になって気持ち悪かったので，やっぱり -1 にします (8dfa6ad) 。

zr-tex8r · 2021-06-29T11:35:04Z

→ チェックを入れるべきか？

恒等変換というのは「わかりやすい動作」なので、現状維持の方が安全な気がしますね。

やっぱり -1 にします

「ここだけ0」なのは違和感があるので、-1で正解だと思います。

aminophen · 2021-06-29T11:39:38Z

ありがとうございます。ぼちぼち printkanji_16bit の方 (#81) のテストに注力したいと思いますので，この時点でマージしておき，何かあった時に再考しようと思います。

aminophen · 2021-06-29T13:24:00Z

pTeX マニュアル (texjporg/ptex-manual@1fbfe35)

t-tk · 2021-06-29T13:33:26Z

不正な文字コードを与えてもそのまま通る。

不正な文字コードをはじく、という仕様にするためには何が不正かを決める必要があり、

明らかに不正なコード (例えば EUC で 0x7FFF以下とか)
正規のコード位置に近いが規格上現れないはずのコード (例えば 0区とか 0点とか)
JIS X 0208 では不正だが機種依存文字や JIS X 0213 で現れるコード (例えばSJISの85区以上とか。)

などどこかで線を引く必要が生じますね。
逆に言うと、「はじかれるか否かで不正なコードの判別をする」ような使い方は期待できそうにありません。
私の意見としては、ややこしい線引きなしに、「恒等変換の場合不正なコードでも素通しする」に一票入れます。

aminophen · 2021-06-29T14:24:28Z

もしコード無変換でも不正な文字コードをはじくなら「is_char_kanji が偽」で判定すれば済むと思ってはいます。しかし「無変換なら（不正かどうかも判定せず）恒等変換」は仕様としてわかりやすいので，これはこれで良いかと。

h20y6m · 2021-07-07T14:32:06Z

\ucs の存在だけで upTeX と判定するコード

plcore, ifptex, minijs, okumacro, jlreq 辺りでしょうか。

すみません。
ifxptex, pxeverysel, pxchfon も該当しそうです。

aminophen · 2021-07-13T12:07:01Z

ありがとうございます。

pxeverysel

aminophen/platex-tools@aa3851a で対応。

pxchfon

zr-tex8r/PXchfon#10 に issue を立てました。

ifxptex

Man-Ting-Fang/ifxptex#1 に issue を立てました。

h-kitagawa added 3 commits June 14, 2021 22:21

pdfutils.ch: added \toucs primitive

9819f46

implement \ucs and \toucs in pTeX

6555c9c

ChangeLog

61bd9c1

fix: \show\toucs

9f94196

aminophen mentioned this pull request Jun 20, 2021

(u)pTeX で expl3 をサポートするために #122

Open

\ucs, \toucs: 0--255, added tests

f5f90b9

Merge branch 'master' into kitagawa_toucs

1872987

aminophen added the feature request label Jun 21, 2021

tiny

2f3c205

aminophen mentioned this pull request Jun 25, 2021

[(e)(u)pTeX] INI モードで \char すると Segmentation fault: 11 #123

Closed

ptexenc.c, kanjicnv.c: invalid code -> -1

d073455

ptexenc.c: fromUCS changed to -1

d32cfbe

invalid code 0 -> -1, detect in ptex-base.ch

5ead93a

uptex-m.ch: \ucs0 should be 0 for internal-uptex

3d8183b

ptex-base.ch: wrap print_hex for negative value

81ad436

ptex-base.ch: cleanup

95835d3

\toucs returns -1 for invalid code

8dfa6ad

aminophen merged commit 3c523b3 into master Jun 29, 2021

aminophen deleted the kitagawa_toucs branch June 29, 2021 12:25

aminophen added a commit to texjporg/ptex-manual that referenced this pull request Jun 29, 2021

ptex-manual.tex: mention \ucs and \toucs (texjporg/tex-jp-build#121)

1fbfe35

aminophen mentioned this pull request Jun 29, 2021

pTeX への \ucs 追加に対応 abenori/jlreq#86

Closed

aminophen mentioned this pull request Jul 1, 2021

pTeX への \ucs 追加に対応 zr-tex8r/ifptex#1

Closed

This was referenced Jul 13, 2021

pTeX への \ucs 追加に対応 zr-tex8r/PXchfon#10

Closed

Support pTeX-p3.10.0 with \ucs Man-Ting-Fang/ifxptex#1

Open

\ucs and \toucs #121

\ucs and \toucs #121

Conversation

h-kitagawa commented Jun 20, 2021

aminophen commented Jun 20, 2021 • edited Loading

h20y6m commented Jun 20, 2021

aminophen commented Jun 20, 2021 • edited Loading

t-tk commented Jun 20, 2021

t-tk commented Jun 20, 2021

h-kitagawa commented Jun 20, 2021

t-tk commented Jun 20, 2021

h-kitagawa commented Jun 20, 2021

aminophen commented Jun 21, 2021

h-kitagawa commented Jun 21, 2021 • edited Loading

aminophen commented Jun 21, 2021

aminophen commented Jun 23, 2021

aminophen commented Jun 24, 2021 • edited Loading

zr-tex8r commented Jun 25, 2021

aminophen commented Jun 25, 2021 • edited Loading

h20y6m commented Jun 25, 2021

zr-tex8r commented Jun 25, 2021

aminophen commented Jun 25, 2021 • edited Loading

aminophen commented Jun 25, 2021 • edited Loading

zr-tex8r commented Jun 26, 2021

h20y6m commented Jun 26, 2021

aminophen commented Jun 26, 2021 • edited Loading

aminophen commented Jun 27, 2021 • edited Loading

aminophen commented Jun 27, 2021 • edited Loading

aminophen commented Jun 28, 2021 • edited Loading

aminophen commented Jun 28, 2021 • edited Loading

aminophen commented Jun 28, 2021 • edited Loading

plcore

ifptex

minijs, okumacro

jlreq

aminophen commented Jun 29, 2021

追加プリミティブについて

不正な文字コード（変換できない場合など）の処理

実装

aminophen commented Jun 29, 2021 • edited Loading

zr-tex8r commented Jun 29, 2021 • edited Loading

aminophen commented Jun 29, 2021

aminophen commented Jun 29, 2021

t-tk commented Jun 29, 2021 • edited Loading

aminophen commented Jun 29, 2021

h20y6m commented Jul 7, 2021

aminophen commented Jul 13, 2021

aminophen commented Jun 20, 2021 •

edited

Loading

aminophen commented Jun 20, 2021 •

edited

Loading

h-kitagawa commented Jun 21, 2021 •

edited

Loading

aminophen commented Jun 24, 2021 •

edited

Loading

aminophen commented Jun 25, 2021 •

edited

Loading

aminophen commented Jun 25, 2021 •

edited

Loading

aminophen commented Jun 25, 2021 •

edited

Loading

aminophen commented Jun 26, 2021 •

edited

Loading

aminophen commented Jun 27, 2021 •

edited

Loading

aminophen commented Jun 27, 2021 •

edited

Loading

aminophen commented Jun 28, 2021 •

edited

Loading

aminophen commented Jun 28, 2021 •

edited

Loading

aminophen commented Jun 28, 2021 •

edited

Loading

aminophen commented Jun 29, 2021 •

edited

Loading

zr-tex8r commented Jun 29, 2021 •

edited

Loading

t-tk commented Jun 29, 2021 •

edited

Loading