[upTeX] ofm読み込みと符号位置 256 以上の欧文文字トークン・ノード #170
Comments
|
現状のパッチは OFM level=0 は読めますが、OFM level=1 は読めません。
|
|
個人的に気になるのはやはり文字コード 128--255 の扱いでしょうか。 |
|
コメントありがとうございます。
使い方としては、kcatcode=14 に設定したら |
|
このissueのやり方を思いついたときのcommentを貼っておきます。 |
これについては，従来の upTeX 仕様から非互換な変更になるので注意です。0x100〜0x2E7F で従来は和文フォントで出ていたところ，欧文フォントで出るようになることによる影響（→欧文フォントが未対応で文字が出なくなる等）？ |
|
コメントありがとうございます。
その文字ブロックが kcatcode=14 になっていない限り latin_ucs と判定されないよう tex-jp-build/source/texk/web2c/uptexdir/uptex-m.ch Lines 2225 to 2231 in 0f4063e |
|
e2e161c \jfont\jpy=umin10
\jpy
\font\uctt=uctt10
\uctt
\kcatcode"152=16
\char"152 % -> 和文
\kcatcode"152=14
\catcode"152=11
\char"152 % -> 欧文
\kcatcode"152=15
\catcode"152=11
\char"152 % -> 和文
\bye
|
|
\jfont\jpy=umin10
\jpy
\font\uctt=uctt10
\uctt
\kcatcode"152=16
\char"152 % → 和文
^^^^0152 % catcode未設定なので出力されない
\catcode"152=11
\char"152 % → 和文
^^^^0152 % → 欧文
\kcatcode"152=14
\catcode"152=11
\char"152 % → 欧文
^^^^0152 % → 欧文
\kcatcode"152=15
\catcode"152=11
\char"152 % → 和文
^^^^0152 % → 欧文
\bye |
|
0fa0c33 |
|
ありがとうございます。他，従来成り立っていた仕様について
新設された欧文トークン kcatcode 14 の扱いについても，上の仕様範囲内に収まると理解しました。 ほかに気付いた点は
|
|
|
|
以下、多分こういう風になっているはず、の仕様案です。 |
|
ec9887c 以降で LaTeX のフォーマット作成が通らなくなっています。
とりあえず以下のパッチで通るようになったきがしますが、 diff --git a/source/texk/web2c/uptexdir/uptex-m.ch b/source/texk/web2c/uptexdir/uptex-m.ch
index 634c0fb4e..3970207c5 100644
--- a/source/texk/web2c/uptexdir/uptex-m.ch
+++ b/source/texk/web2c/uptexdir/uptex-m.ch
@@ -212,6 +212,14 @@ else if (kcode_pos=1)or((kcode_pos>=@'11)and(kcode_pos<=@'12))
@d partoken_name=set_enable_cjk_token+1 {set |par_token| name}
@z
+@x
+@d single_base=active_base+256 {equivalents of one-character control sequences}
+@d null_cs=single_base+256 {equivalent of \.{\\csname\\endcsname}}
+@y
+@d single_base=active_base+max_latin_val {equivalents of one-character control sequences}
+@d null_cs=single_base+max_latin_val {equivalent of \.{\\csname\\endcsname}}
+@z
+
@x
@d cat_code_base=auto_xspacing_code+1
{table of 256 command codes (the ``catcodes'')}
@@ -333,6 +341,12 @@ primitive("kchar",kchar_num,0);@/
@!@:kchar_}{\.{\\kchar} primitive@>
@z
+@x
+primitive("relax",relax,256); {cf.\ |scan_file_name|}
+@y
+primitive("relax",relax,max_latin_val); {cf.\ |scan_file_name|}
+@z
+
@x
char_num: print_esc("char");
@y
@@ -641,6 +655,12 @@ if cat=other_kchar then k:=k-multilenbuffchar(cur_chr)+1; {now |k| points to fir
begin cur_cmd:=t div max_char_val; cur_chr:=t mod max_char_val;
@z
+@x
+@d no_expand_flag=257 {this characterizes a special variant of |relax|}
+@y
+@d no_expand_flag=max_latin_val+1 {this characterizes a special variant of |relax|}
+@z
+
@x get_token
if (cur_cmd=kanji)or(cur_cmd=kana)or(cur_cmd=other_kchar) then {|wchar_token|}
cur_tok:=cur_chr
@@ -656,6 +676,12 @@ if cat=other_kchar then k:=k-multilenbuffchar(cur_chr)+1; {now |k| points to fir
else cur_tok:=(cur_cmd*max_char_val)+cur_chr
@z
+@x
+ begin eq_define(cur_cs,relax,256); {N.B.: The |save_stack| might change}
+@y
+ begin eq_define(cur_cs,relax,max_latin_val); {N.B.: The |save_stack| might change}
+@z
+
@x
if check_kanji(info(p)) then {|wchar_token|}
begin buffer[j]:=Hi(info(p)); buffer2[j]:=1; incr(j); buffer2[j]:=1;
@@ -1526,6 +1552,14 @@ adjust(char_base); adjust(width_base); adjust(lig_kern_base);
dvi_out(BYTE3(jc)); dvi_out(BYTE4(jc));
@z
+@x
+@d span_code=256 {distinct from any character}
+@d cr_code=257 {distinct from |span_code| and from any character}
+@y
+@d span_code=max_latin_val {distinct from any character}
+@d cr_code=max_latin_val+1 {distinct from |span_code| and from any character}
+@z
+
@x
hmode+kanji,hmode+kana,hmode+other_kchar: goto main_loop_j;
hmode+char_given: |
|
omlgc.ofm を読むと落ちる件は 653ba97 で直ったと思います。 latin modernのうち ec-lmr10.tfm をもとに、Unicodeに並べ替えた eu3-lmr10.ovp, eu3-lmr10.ofm, eu3-lmr10.ovf を作成しテストしています。 今の考えでは uptex version 2.00 として TeX Live 2025 に入れたいと思っています。 ofm level 1 は、今の uptex-m.ch には断片的に入っていますがメモリー管理がよく分かっておらず危険なので、TeX Live 2025向けには入れず、一旦削除するつもりです。 |
|
当初から予定だが気になっていた↓ですが、dvips b0db37c と dvipdfmx 6d5e8c3 で予定通り動いていることが確認できました。なので、このまま進めます。
ff, fi, fl, ffi, fflなどのリガチャはuptexの組版では0x1B..0x1F あたりを使い vf の指している先の文字コードが U+FB00..FB04 になっている状況で、Unicodeフォントの文字コード U+FB00..FB04 (ff, fi, fl, ffi, ffl) で出力できます。 ただし、和文vf の fallback を dviware で #99 で和文扱いしていた ofm の条件判定が緩すぎて、欧文扱いしてほしい ofm も和文判定されてしまう虞があるので和文判定の条件を厳しくしました。→ 19f63e6, b910da8 |
|
kcatcode=14のもとで |
と言っていましたが、 その他、本パッチの有無でplatexを走らせて比較し、 現時点で、リグレッションは見つからず、もし有ったとしても発見しづらいレベルになっていると思います。 |
Ref. [upTeX] ofm読み込みと符号位置 256 以上の欧文文字トークン・ノード texjporg/tex-jp-build#170
|
もうregressionの問題は発見できないレベルになり、CIのテストは充分に入れたと思うので とはいえ、upTeX ver0.0x の頃以来の大改造になるので、根拠のない不安は残っています。 今後の構想。
|
|
master は eupTeX u2.00-241020 にしましたが、 |
upTeX で欧文用に ofm を読めるようにして符号位置 256 以上の欧文文字トークンと符号位置 256 以上の欧文文字ノードを扱えるようにする、という構想です。
少し前↓で述べたことの続きです。
#153 (comment)
まだ実験レベルですがとりあえず手元でそれなりに動いているので紹介します。
スジは結構いいように感じていますが、完成度はまだまだです。
UTF-8の入力バッファで8 bit 文字コード列が正規のUTF-8として U+2E7F 以下と読み取れるとき、Unicodeの欧文であると解釈して符号位置 0x80～0x2E7F の欧文文字ノードを生成する。
和文は従来と変わらず JFM で扱う。
dviware側で必要な場合はvirtual fontで何とかする。
\catcode,\lccode,\uccode,\sfcodeの扱う欧文文字コードの最大値は 0x2E7F とする。(kcatcode=14,15両方)\char,\chardefは0～0x2E7F の欧文文字が扱える。\Uchar,\Ucharcat,\iffontcharは0～0x2E7F の欧文文字が扱える。^^^^xyzwの書式は欧文ノードを生成する。(kcatcode=14,15両方) 8d3be7e内部ノードの文字コードは以下。
The text was updated successfully, but these errors were encountered: