[npTeX] 欧文トークンに似せたCJKトークン

[t-tk]

upTeXにcatcodeが15以下でかつCJKのトークンを追加で導入しよう、という提案です。
[upTeX] JIS-encoded TFM #149
とは別に扱った方がよさそうなので issue を立てます。

背景はこちら。
#149 (comment)

現状の LaTeX3 では regression test（大量に用意されたテストファイル入力 .lvt に対するログ .tlg を比較）の仕組みが (u)pTeX に対しては機能していません。

pTeX では高位ビットが現れるテストファイルの入力中断処理が仕込まれている
upTeX では regression-test.cfg で最初から \disablecjktoken している
その理由は恐らく

(u)pTeX が「和文(CJK)文字トークン」という独特の物が存在し，また文字コードが中途半端に 0--255 ではないこと（e.g.「あ」できるのに「\catcodeあ」できない）
が理解されないためだと思われます。和文(CJK)文字トークンの catcode が 16〜18(19) であることも考慮されておらず「カテゴリーコードは 16 進 1 桁」を前提にしたインタフェースが構築されています（https://github.com/h20y6m/plexpl3/issues/3）。

で、私の提案はこちら
#149 (comment)

思いつきですが、その対策として例えばupTeXの仕様の追加で
「catcodeが11で文字コードがある値(例えば0x2E00以上)より大きい場合は漢字トークンとみなす」
「catcodeが12で文字コードがある値より大きい場合はCJK記号トークンとみなす」
のようなものを用意し、それらに対しては
「あ」できて「\catcodeあ」できてしかもCJKトークンである
という風にするのはいかがでしょうか?

で @aminophen さんのリプライ
#149 (comment)

この特定の値については #135 からだと思いますが，あちらは「OFM に定義された最大の文字コード」だから良かったものの，今回のようなものには使えないように思います。（例えば 0xB7 (U+00B7) は uptex-fonts でも和文扱いを想定した中黒です）

[t-tk]

今回の私の提案は、「本格的に kcatcode 16以上をすべてcatcode15以下に移し替えよう」という前提ではありません。
upTeX では、0x80..0xFF の間で欧文と和文(CJK文字)を区別する必要があって、開発初期の頃からの悩みのタネでした。15以下のcatcodeで0xFF以下のcharcodeではどうしても欧文と区別がつかないので拡張する必要がありました。(U+00B7が話題になったのは時期的には後の話ですが、本質的にはupTeXの一番最初からある問題です。)
で、今回の提案は、「LaTeX3 の regression test」のような場でも(u)pTeXの立場を深く理解してもらうまでいかなくとも、せめてtest caseに混ぜてもらえる程度には欧文TeXに近づけよう、というものです。
従来のkcatcode16以上の動作は、機能として重複したままそのまま維持したいです。
私の提案の中の「特定の値」は実は0x2E00である必要はなく、0x0100以上でも0x2000でもいいです。
0x2E00の境界は、dvipsの「OFM→JFM の縦組みの読み替えをするか?」の判定に使いましたが、今回はもっと小さい値でも構いません。

「catcodeが11で文字コード 0x4E00はU+4E00で漢字の「一」でして、それをLaTeX3で処理したいです。」という風にしてそれをLaTeX3の開発チームに理解してもらえればよいです。
特定の値は0x2000でもよくて、
「catcodeが12で文字コード 0x2603はU+2603で「☃」でして、それをLaTeX3で処理したいです。」という風にしてそれをLaTeX3の開発チームに理解してもらう、という風でもいいです。
U+1FFF以下は、CJK以外の国々の言語の普通の文字(U+00B7のようなごく少数の例外を除く)が集まっていて、U+2000..206F が "General Punctuation"なので特定の値は0x2000でも妥当な感じがします。

[aminophen]

issue の分割と検討をありがとうございます。

まず『LaTeX3 をサポートするうえで (u)pTeX にとって最低限必要なのは何か』を把握する必要があると思います。

• 私としては，極端なケースでは「和文(CJK)文字トークンの廃止」すなわち \disablecjktoken 既定化まで追い込まれるかもしれないくらいの危機感を持っています。
  • 恐らく「和文(CJK)文字トークンに対しても欧文互換の \catcode を利用可能にする (kcatcode 16,17,19 に対しては 11 を返し，\kcatcode 18 に対しては 12 を返す)」程度の小改良では解決しないでしょう。
  • 前の issue [upTeX] JIS-encoded TFM #149 での「(u)pTeX の後方互換性を放棄してでも」という私の言及も，そのくらい高いレベルの危機感からの発言です。
• 仮に和文(CJK)/欧文の区別を維持できるとして，その境界を特定の文字コード値とするのは，後々その値を変えたくなるような禍根を残さないものとしたいです。仮にごく少数の例だとしても「その文字を CJK トークン扱いさせたい状況においてそれを実現できる手段」があるのが理想です。
  • 私個人かもしれませんが，U+00B7 は滅多に使いませんが × (U+00D7, JIS 1-1-63) は日本語の文書中でよく使います。マルバツでよく使われる和文文字ですし，CJK 扱いされてほしいです。
  • まあ，和文(CJK)文字トークンにならなかったとしても，例えば newunicodechar のようなものを援用して，欧文用 \usepackage[utf8]{inputenc} の仕組みの中で \kchar で日本語ノードを生成すれば済む話なので，出力できなくて困ることはないと思いますが。

[t-tk]

今はブレインストーミング的なフェーズだと思うので、外れかもしれないことを言うかもしれません。

「\disablecjktoken 既定化」とのことですが、理解出来ていません。
latexの中身について全然知らないのですが、
現状の uplatex.ltx を見ると latex.ltx, plcore.ltx, uplcore.ltx の順番に読んでいます。
冒頭で \disablecjktoken 既定でも latex.ltx と plcore.ltx の間に \enablecjktoken を入れれば問題ないようにすることが出来そうに見えます。
それもダメということでしょうか?
\enablecjktoken, \disablecjktoken はあくまでupTeXエンジンの入り口でCJKトークンに変換するかしないかを決めているだけだったはずで、既にCJKトークンになったものを無効化するとかいう風にはしなかったはずです。
(u)pTeX の特徴的な仕様を考えてみます。

1. kcatcode 16,17,18,19 を持つ。
2. charcode 0x0100..0xFFFFFF が可能。
3. 和文用tfm(jfm)を使うが欧文tfmとは全く別である。
4. 和文フォントと欧文フォントは個別に管理され、カレントフォントは欧文フォントと和文フォントの組である。
5. 和文フォントあるいは和文-欧文間に関わる組版規則がいろいろあって(u)pTeXエンジンがまかなっている。
6. kcatcode や cjktoken 化の設定の仕様いろいろ。(ブロック毎のkcatcodeとか\enablecjktokenとか)
7. その他。

(u)pTeX が欧文TeXからかけ離れている点はいろいろあると思いますが、LaTeX3開発で障害になるのはどれでしょうか。
kcatcode の取る値はまだupTeXと非互換になってもダメージが小さいように見えます。
charcode の範囲は luaLaTeX, XeLaTeX でも可能なのだから欧米の開発者からも理解されるような気がします。
それ以外は(u)pTeX互換から離れようとした場合にかなりダメージが大きいように思います。
(u)pTeX から離れて luaTeX-ja に完全移行という選択肢もあると思います。
kcatcodeを振る際の仕様とかは、欧文TeXと違いすぎるものの欧文TeXと関わりのある基本的機能ではないのでLaTeX3開発とは関係が薄いようにも思います。
(u)pTeX と luaTeX-ja の間になるであろう「upTeX 非互換だが LaTeX3開発に同期しやすい新CJK-TeX」の仕様とは?

ごく少数の例だとしても「その文字を CJK トークン扱いさせたい状況においてそれを実現できる手段」

現状 \kchar でどんなcharcodeでもCJKトークンになるようにしてあったような記憶があります。

仮に和文(CJK)/欧文の区別を維持できるとして，その境界を特定の文字コード値とするのは，後々その値を変えたくなるような禍根を残さないものとしたい

その閾値を決めるプリミティヴを導入すれば済む話のように思います。都合に合わせ設定し直せばよいです。
というか、そもそも、cjktoken化の範囲は現状(ブロック毎に)コントロールできるようになっているので、現状のupTeXの仕様不足という話でないように見えます。
「LaTeX3 の regression test」が \disablecjktoken になっていることも本質でないように見えます。
「LaTeX3の開発中のブランチのものが cjktoken を有効にしたとたん動かなくなる事態が起きるが、そのことに気づいてもらえない」という問題なのだ、と感じます。

[t-tk]

もう一つ。
「和文(CJK)文字トークンの廃止」でも和文の組版品質を pTeX と同等以上に、ということを目指しているのが luaTeX-ja なのだと思っていました。
luaTeX-ja のようなアプローチでは無くて、 (u)pTeX に存在する仕様でかつそれを捨ててもよくて、それでも和文の組版が維持できる、とかイメージが浮かびません。

[h20y6m]

全然追いつけていないのですが

(u)pTeX が欧文TeXからかけ離れている点はいろいろあると思いますが、LaTeX3開発で障害になるのはどれでしょうか。

現状どうしたらいいのかわからないのは

• [l3regex] [upTeX] 和文文字と欧文バイトがマッチしてしまう h20y6m/plexpl3#2 のl3regexが文字コードでマッチングしているので0x80--0xFFの範囲で欧文と和文が区別できない。
• [l3tl-analysis] \tl_analysis_map_inline関数で和文文字トークンがカテゴリコード 6 と判定される h20y6m/plexpl3#3 の \tl_analysis_map_inline 関数で和文文字トークンのカテゴリコードとして何を返すべきか。

でしょうか。

それから欧文については8-bitエンジンだけど和文文字トークンという異質なものが入ってくるという点でしょうか。

LaTeXでは(u)pTeXは8-bitエンジンとして扱われていて、8-bitエンジンではUTF-8でエンコードされたトークン列を前提としています。この前提のもとコードポイント単位での処理は、先頭のトークンを取得して何バイトのUTF-8バイトなのか判断してそのバイト数分のトークンを1文字として処理しています。
例えば ^^e6^^97^^a5 の場合先頭のトークンの文字コードは 0xE6 で3バイトのUTF-8バイト列なので後続の2トークンを追加で取得して3バイトを1文字として処理します。
ここで和文文字が入るとこの処理が破綻します。例えば 日本語 だと先頭のトークンの文字コードは 0x65E5 なので……となって「UTF-8の先頭バイトとして不正なのでエラー」とか「0xF0 以上なので4バイトなので追加で3トークン読んでこの場合は足りないので終端マーカーを巻き込んでよくわからないエラーがでたり無限ループしたり」とかが起こります。

あとupTeXの場合は0x80--0xFFの範囲に和文文字があるためUTF-8の2バイト以上を構成するはずの文字コードを持ったトークンがUTF-8バイト列の中に単独で現れるといったことが起こります。

[aminophen]

冒頭で \disablecjktoken 既定でも latex.ltx と plcore.ltx の間に \enablecjktoken を入れれば問題ないようにすることが出来そうに見えます。それもダメということでしょうか?

latex.ltx だけを \disablecjktoken で読むだけでは足りなくて「ユーザが書く LaTeX ソースの中身に現れる和文文字トークンが悪さをする可能性がある」ということです。さらに別の問題は「ptexenc による ^^-記法 への変換」が regex の ^ による文字除外シンタックスと衝突しうるということです。

現状 \kchar でどんなcharcodeでもCJKトークンになるようにしてあったような記憶があります。

それは CJK ノードの生成であって，CJK トークンを生成しているのではありません。「CJK ノードが存在すること」は LaTeX3 と一切衝突せず，TeX 入力を解釈するうえで「CJK トークンが存在すること」が課題になっています。

[h-kitagawa]

CJK トークンを生成

e-upTeX なら，\Uchar, \Ucharcat でできます：

\disablecjktoken
\expandafter\expandafter\let\expandafter\A\Uchar"3042\relax
\message{\meaning\A}
\bye

---

極端なことを言えば，「和文文字ノード」（aminophen さんの言葉だと「CJK ノード」）があれば，「和文文字トークン」がなくても

• 和文フォントと欧文フォントは個別に管理され、カレントフォントは欧文フォントと和文フォントの組である。

• 和文文字の UTF-8 バイト列，例えば ^^e3^^81^^82 から，きちんと和文文字ノード「あ」が作られる
• 和文文字ノードについては和文の組版規則に沿って処理が行われる．
• 必要に応じて，和文組版処理に関わる \prebreakpenalty 他のパラメータが設定できる

だけでもなんとかなりうると思います．

いくつか着地点は思いつくのですが，文章化できるほどには考えをまとめる時間がありません……（後で書きます）．

[t-tk]

あまりよく分かっていませんが
「一見欧文トークンに見えるもの」から「CJKノード」が生成できれば目的(LaTeX3と衝突せずCJKの組版ができる)ということでしょうか。
issueのタイトルを変更してみました。もっと適切な言い方があればどなたかお願いします。

[aminophen]

「一見欧文トークンに見えるもの」から「CJKノード」が生成できれば目的(LaTeX3と衝突せずCJKの組版ができる)ということでしょうか。

端的に書いていただいてありがとうございます。私の理解と合っています。

[t-tk]

雑感です。

• [l3regex] [upTeX] 和文文字と欧文バイトがマッチしてしまう h20y6m/plexpl3#2
  l3regexが文字コードでマッチングしているので0x80--0xFFの範囲で欧文と和文が区別できない。

こういう話を聞くとCJKノードが内部バッファでもUTF-8のバイトの並びでなければならない、という状況は理解します。
upTeXの最初の頃2007年の状況では、T1 や T2A などの8bit欧文と和文の混在は想定していましたが LaTeX がこれほどまでUTF-8化することは想像できませんでした。
upTeXはpTeXの和文をUnicodeのCJKに置き換えるのが根幹にあり、CJKを内部バッファでUTF-8の並びにすることは全く頭にありませんでした。

全く別のソフトですが、Unicode化したときの内部バッファは、upbibtex, bibtexuはUTF-8, upmendexはUTF-16でして、それを採用した事情もさまざまです。
LaTeXのUTF-8化が進んだ場合、upTeXでは、CJKがUTF-32改で欧文がUTF-8の二階建て構造となり、見通しが良くない状況に陥ることは理解できます。

luaLaTeX, XeLaTeX のCJKは内部バッファでUTF-8になっているのでしょうか?

[h-kitagawa]

luaLaTeX, XeLaTeX のCJKは内部バッファでUTF-8になっているのでしょうか?

LuaTeX は内部バッファが UTF-8 です (tex/textoken.c, utils/unistring.c)．

XeTeX は，ビルド時に作られる xetexd.h を見ると EXTERN UnicodeScalar * buffer ; とあるので，内部バッファは Unicode 値のようです．

[t-tk]

ありがとうございます。

XeTeX は，ビルド時に作られる xetexd.h を見ると EXTERN UnicodeScalar * buffer ; とあるので，内部バッファは Unicode 値のようです．

XeLaTeXでは h20y6m/plexpl3#2 の問題は発生しないのでしょうか?