search

texjporg / tex-jp-build

Minimum source repository to build Japanese TeX processing tools
23 stars 6 forks source link

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

Open t-tk opened 2 years ago

t-tk commented 2 years ago

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

背景はこちら。 https://github.com/texjporg/tex-jp-build/issues/149#issuecomment-1279731866

現状の 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）。

で、私の提案はこちら https://github.com/texjporg/tex-jp-build/issues/149#issuecomment-1279757248

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

で @aminophen さんのリプライ https://github.com/texjporg/tex-jp-build/issues/149#issuecomment-1279778635

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

aminophen commented 2 years ago

eqtb テーブルに格納された属性の kcatcode は… 和文文字トークンに格納された属性の kcatcode は…

どちらの言明も直接「欧文文字トークン」自体に kcatcode の情報が必要な理由には当たりませんが，これらの言明は最低限「eqtb テーブル」には catcode と kcatcode の両方の情報を持たせる必要があることは示しているので，結局『eqtb テーブル内で catcode=12 かつ kcatcode=17 な状態を許すかどうか』からは逃げられません。

原理としては「文字トークンは catcode か kcatcode のどちらか一方だけを持つ」でも可能だと思いますし，例えば「 あ が和文扱い (kcatcode=17)の状態で \catcode`あ=13 されれば欧文扱い (catcode=13) に自動で切り替わる」とできれば自然だと思います。ただ \catcode 以外の特性値の代入（\lccode のように「和文でも欧文でもありそう」なものとか，\sfcode のように「いかにも欧文専用っぽい特性」とか）でも切り替わるべきかどうか？

t-tk commented 2 years ago

現状 OTFパッケージの vf の文字コードの一時利用先として使っています。

これは「文字コード上限 U+10FFFF に落とすと，OTF パッケージは使えなくなる（改修が必要）」ということを仰っていますか？

はいそうですね。現状のvfは使えなくなります。 現状では \CID{}, \CIDT{} などのコード値の入力をsubfontに分けた残りのコード値を 64 x 64 = 4096文字 に写します。 その値に対しさらに pLaTeX では 64 x 64 を (16区 .. 79区) x (16点 .. 79点) (漢字の領域) のJIS→EUC/SJISに変換 (すなわち 8bit 8bitにして 0x3030 を足して \jis で内部コードに変換)します。 upLaTeX ではその代わりに 0x113030 を足した後 \kchar で内部コード (Unicodeではない値)にしています。 できれば、ディスク容量を食う subfont を使いまわしたいのでこういうコード変換にしました。

upLaTeX では pLaTeX よりも和文の文字コードの範囲がはるかに広いので、subfontの分け方を変えて内部コードも変えることで同等の動作を作り出すことは可能です。 現に、最近の japanese-otf-uptex では \UTF{}, \UTFT{} などはsubfontの分割をやめて Unicodeの値をそのまま使うように変えてしまいました。 \CID{}, \CIDT{} などは、文字幅(1/2角、1/3角、1/4角など)がいろいろあるのをちゃんと新subfontで作り直そうとすると面倒なうえ間違えてしまいそうなのと、Unicodeではない文字コード(CID)のものにUnicodeの文字コード(0x10FFFF以下, しがらみがありそう)を与えてしまった場合にどんな結果が起きるのか予見出来ず、もとの pLaTeXと同じ齋藤さんの vf, subfont を使い続けています。

ご参考: \UTFC{}, \UTFT{}, \UTFK{}の多書体化 和文vf の fallback を使った vf の軽量化

そういう事情で、仮称zpLaTeXでも多少はUnicodeではない内部コードを確保しておくことに +1 です。

上記の目的では、0x113030..0x116F6F を使っています。 IVSの漢字で使うことを考えないのであれば、max 0x1FFFFF で充分お釣りがきます。

h20y6m commented 2 years ago

原理としては「文字トークンは catcode か kcatcode のどちらか一方だけを持つ」でも可能だと思います

と書かれたあとですが「文字トークンがcatcode, kcatcode, is_cjkを独立に持つ」で思いついたことをかいておきます……

和文文字トークン⇔欧文文字トークンの変化は起こらないはずですので、 欧文文字トークンがkcatcodeを持つ意味はなさそうです。 和文文字トークンがcatcodeをもつ意味はkcatcode=16,17,19かつcatcode!=11またはkcatcode=18かつcatcode!=12を認めるかどうかによりそうです。

話の流れとは全く関係ありませんが、新しいものを作るならダメもとで無茶な提案をしてみてもいいかなと思ったので書いておきます。

和文フォントでもリガチャのようなことができないだろうというものです。

たとえば「か」＋U+309Aで「か゚」とか、IVSで異体字とか、くずし字連綿とかが組めるようになるのではないかという思い付きです。

aminophen commented 2 years ago

「文字トークンがcatcode, kcatcode, is_cjkを独立に持つ」で思いついたこと

ありがとうございます。情報は独立に持たせつつも，必要なところでは連動させるということですかね。それは確かに私が迷っていたところをかなり解決してくれそうです：

トークンはcatcodeに従って振る舞う（つまりcatcode=13ならkcatcode, is_cjkによらずアクティブ文字）…① \catcode の書き込みは連動してis_cjk=0（欧文）に更新する \kcatcode の書き込みはブロックの全文字に作用し16, 17, 19ならcatcode=11かつis_cjk=1（和文）に、18ならcatcode=12かつis_cjk=1、15ならis_cjk=0に更新する（互換性のため）

この辺りはなるほどと思いました。

和文文字トークン⇔欧文文字トークンの変化は起こらないはずですので、 欧文文字トークンがkcatcodeを持つ意味はなさそうです。 和文文字トークンがcatcodeをもつ意味はkcatcode=16,17,19かつcatcode!=11またはkcatcode=18かつcatcode!=12を認めるかどうかによりそうです。

そうですね。認めないことにして「和文文字トークンはcatcodeを持たない」でも良いように思えてきました（\ifcat では読替を行えば十分）。これなら「トークンは一律に 5bit(catcode/kcatcodeのどちらか)+24bit(文字コード) で表される」だけで済んでしまいますね。

t-tk commented 2 years ago

名称案

でいかがでしょう。 jpTeX だと japan を強く連想させすぎる感じがしていましたが nippon ならよいかと。

(ASCIIさんが nihongo TeX という呼び方もしていたのを思い出したので nihongo pTeX を追加しました)

aminophen commented 2 years ago

今のところ，いろいろ考え直して以下に傾いています。

に傾き始めています。 → 最新の頭の中を書き下したもの

h-kitagawa commented 2 years ago

最新の頭の中を書き下したもの

もやっと思ったことを書き連ねておきます．

h-kitagawa commented 2 years ago

新エンジン用にディレクトリだけ作ったもの https://github.com/h-kitagawa/texlive-source/tree/kitagawa_zptex_concept

  • npTeX: new pTeX, next pTeX, novel pTeX, notable pTeX でかつ nippon pTeX または nippon TeX

tex-jp-build の枠内に収まらないと不便なので，npTeX（仮称）の名称で https://github.com/h-kitagawa/tex-jp-build/tree/nptex_concept に． 名称が正式決定し次第，texjporg/tex-jp-build に移します． →(edit) 移しました．https://github.com/texjporg/tex-jp-build/tree/nptex_concept

t-tk commented 2 years ago

多数の賛同いただけたようなので npTeX / npLaTeX で決定しましょう。

以下はどうしましょうか。 (u)ppltotf, (u)ptftopl, (u)pdvitype, (u)pbibtex

np???を作ってそれに一本化して従来のものを廃止? np???を作って従来の名前はaliasで残す? np???を作らず、(u)p???を継続する?

web2c/*ptexdir/ の下に無い (u)pmpost は?

upmendexは、すでにforkしてから大きく逸脱しているのでそのまま続けるつもりです。

一応 nptex, nplatexでググってみると検索結果が少し出ますが TeXエンジンやコマンド名と混同することはなさそうです。

t-tk commented 2 years ago

ふくよかなお姉さんのロシア語サイトとトレードチャートが目立ちますが気にしないことにします。

https://www.google.com/search?q=nptex&sxsrf=ALiCzsYhZvYsjwIo9QkYOKFje4Vh3OrKpg:1666871283971&source=lnms&tbm=isch&sa=X&ved=2ahUKEwjqt5G2q4D7AhWGp1YBHSCnCXoQ_AUoAXoECAEQAw&biw=1286&bih=658&dpr=1.25

aminophen commented 2 years ago

多数の賛同いただけたようなので npTeX / npLaTeX で決定しましょう。

👍

以下はどうしましょうか。 (u)ppltotf, (u)ptftopl, (u)pdvitype, (u)pbibtex

web2c の下に無い (u)pmpost は?

これは正直イマイチ触れていないので考えないことにしたい…。

upmendexは、すでにforkしてから大きく逸脱しているのでそのまま続けるつもりです。

良いと思います。

h-kitagawa commented 2 years ago

(u)ppltotf, (u)ptftopl

ひょっとしたら

和文フォントでもリガチャのようなことができないだろうというものです。

みたいな機能拡張を行うことも考えられます．ただ，「機能拡張を使わない場合は従来と同じ jfm/jpl の結果が得られる」というのならば，up〜 のままで良いのではないかと思います．

web2c の下に無い (u)pmpost は?

(u)ppltotf を残すのであれば，これもわざわざ変える必要はないと思います．

t-tk commented 2 years ago

和文フォントでもリガチャのようなこと

リガチャそのものではなくてupTeX内で合成文字の私的な内部コードを使う考え方は以前述べていました。 [upTeX+dvipdfmx] 異体字セレクタ、Unicode合成文字

普通の全角文字は jfm の 0番に対応付ければ正常に組めることを利用して、 前述のような私的な内部コードを使う代わりに npTeX の内部コードで合成で表されるUnicodeのコードポイントの列 (例えば「か」＋U+309A)を一つの全角文字として扱って組むことが出来ると、漢字のIVSや鼻濁音の半濁点仮名位までは対応できそうです。 実装できるまで先が長そうですが。

aminophen commented 2 years ago

最新の頭の中を書き下したもの

もやっと思ったことを書き連ねておきます．

ありがとうございます。

内部バッファからのトークン生成や \Uchar などでは，和文欧文の判定で何を最初に見るのが良いか？

is_cjk = 1 に設定する場合は catcode=11,12 以外を許容しないことにして catcode も修正するという連動も仕様に追加しましょうか。「catcode が 11,12 以外の状態で，is_cjk=1 に設定されたら，kcatcode が 16,17,19 なら catcode を 11 へ / kcatcode が 18 なら catcode を 12 へ変更する」 → 書き下しを修正

(catcode, kcatcode)=(11, 18), (12, 17)……①という状況も「コントロールワード内に使えるか」という点で欧文扱い・和文扱いで状況が異なることは確か．

これは敢えて容認でもいいかと思います。

例えば (catcode, kcatcode)=(12,18) になっている文字コード "xyzw に対して，「コントロールワード内に使えるようにしたい」という目的で \catcode"xyzw=11 \kcatcode "xyzw=17 とすることができない（最初の代入で欧文扱いに固定されてしまう）．

なので，気にすることはないのではないでしょうか。

aminophen commented 2 years ago

[TODO] 文字コード X ≧ 0x100 の欧文文字トークンをどうするか？

これにどれくらいの手間がかかるか，で全体の方針も決まってきそうな気がします．… \tonoderecipe"xyzw={<token list>} みたいなものを導入する？

アクティブ化に頼らずに何らかの方法で「Unicode 値→出力命令へのマッピング」を定義できるようにしたい

LuaTeX には「仮にその文字コードがアクティブ化 (catcode=13) されたら…」を定義する \letcharcode というプリミティブがあって \def\foo{bar}\letcharcode<文字コード>=\foo とすれば \meaning<文字コード> が bar になります。（lowercase / uppercase トリックを使わずに済む）

% luatex
\show X         % > the letter X.
X               % => X
\char`X         % => X

\def\foo{Y}\letcharcode`X=\foo
\show X         % > the letter X.
X               % => X
\char`X         % => X

\catcode`X=13
\show X         % > X=macro:->Y.
X               % => Y
\char`X         % => X

\end

\tonoderecipe"xyzw={<token list>} は「仮にその文字コードが is_cjk=0 だったら…」が欲しいのでちょっと似ていますが「アクティブ化は要しない（catcode=11,12 専用）」「そのトークン列を使うのは \meaning の時ではなく \char の時である」というのが異なります。

h-kitagawa commented 2 years ago

\tonoderecipe"xyzw={} は「仮にその文字コードが is_cjk=0 だったら…」が欲しいのでちょっと似ていますが「アクティブ化は要しない（catcode=11,12 専用）」「そのトークン列を使うのは \meaning の時ではなく \char の時である」というのが異なります。

まだコードを見ていませんが，実装については「自動的にトークンを挿入する」という点で \XeTeXinterchartoks が参考になったらいいな，と思っているところです．

最初に提案した \tonoderecipe"xyzw={<token list>} だと各文字コードごとに命令を割り当てることになり面倒な気がしてきました（メモリも食う）． →(edit) アクティブ文字の意味を格納する場所 (active_base) とかを流用してよい？

\nptextonodeprefix={<token list>} を 1 つ準備し，

とかやっても良いかもしれません（npLaTeX では \nptextonodeprefix が u8: になる）．

aminophen commented 2 years ago

仕様案の書き下しではなるべく今の和文(CJK)トークンの仕様を生かそうとしたのですが，書き進めるうちに内部改修量が随分と多いように思えてきました。もちろん頑張ってもいいのですが…。

従来の「和文(CJK)トークン」のどんな特性を維持すれば，日本の大量の (u)pTeX の資産を生かすことができるのでしょうか？「1文字1トークン」？「kcatcode という値」？

確かに upTeX の \disablecjktoken 状態は「1バイト1トークン」かつ「kcatcode も関係ない」ですので，欧文 8bit TeX (pdfTeX in DVI mode) と何ら変わらず，日本では殆ど使い物にならないと思います。しかし，仮に「1文字1トークン」にさえできれば kcatcode はなくてもどうにかなる可能性はあるでしょうか。例えば XeTeX に (e-)(u)pTeX から和文組版処理を切り出した change file を当てる形で npTeX を実現することはできないか，ということを考えています。

zr-tex8r commented 2 years ago

自分の考えとしては、やっぱり、 和文文字トークンのkcatcodeは要らない （従ってnpTeXの文字トークンのkcatcodeも要らない） と思いました。

zr-tex8r commented 2 years ago

さらに、 文字のkcatcodeについての(u)pTeXとの互換性もそれほど重要でない とも考えています。

aminophen commented 2 years ago

jcharwidowpenalty の判定に絞ると，upTeX は「和文文字トークンに kcatcode を持たせて和文文字ノードに波及させる」としています。ZR さんの仰るような和文文字トークンの kcatcode は存在しない（catcode のみ存在する）状態でも，jcharwidowpenalty の判定に要るのは「kcatcode が 18 かどうか」だけなので

とすれば済みそうですね。

こうなると eqtb テーブルの kcatcode も重要ではなく，is_cjk と catcode の2つの属性を持つことにして「\kcatcode 代入」のアドホックな互換性対応で

でも一見良さそうに見えます。しかしこのとき「ハングル(19)直後の改行は空白になる」が区別できない問題が残ります。

aminophen commented 2 years ago

こう考えると，eqtb テーブルには 3 つの独立属性がやっぱり必要なように思います。組み合わせは

後者のように kcatcode の意味を分離するとよさそう？

zr-tex8r commented 2 years ago

現在の仕様を見るとやっぱり複雑な「連動の仕様」が異様にみえます。そもそもこれが必要になる理由は「catcode、is_cjk、kcatcodeで機能の重複がある」（このため「catcode=11、kcatcode=18」みたいな困った状態が生じる）だと考えられます。「連動無しで済ます」かつ「欧文側のみの操作を期待通りにする」ために、次のような方針を考えてみます。

zr-tex8r commented 2 years ago

自分の考えた仕様の概要は以下のようになります。

h-kitagawa commented 2 years ago

h-kitagawa/kitagawa_nptex_sandbox_1 でいろいろ遊んでいます（まだ動きません）が，内部バッファや文字列のトークン化について考えているところです．

pTeX p4.0.0 (#81) において，文字列を格納するstr_pool を 16 bit に拡張し

今の所考えている仕様&実装案は：

→\<edit>

  • x=1 のとき．U+0080 以上の欧文文字トークン由来のバイト列の一部
    • x=2 のとき，和文文字トークン由来のバイト列の一部（U+0000--U+007F の和文文字トークン由来もここ）

は区別しなくても良い気がしてきました．upTeX と違い，欧文文字トークンも Unicode ですし． \</edit>

今更ですが，和文文字トークンと欧文文字トークンの区別を一切なくし，

のようにするのは互換性を考えなさすぎ？

aminophen commented 2 years ago

別に「和文の特殊文字／文字トークン」が存在しても何も困ることはない。 互換性のために「\kcatcode への代入」で文字の属性の設定が行われるようにする。「\kcatcode の取得」は（互換性を保つ動作ができないので）サポートしなくてよいと思う。

これはそうだなと思いました。

今更ですが，和文文字トークンと欧文文字トークンの区別を一切なくし，…のようにするのは互換性を考えなさすぎ？

最近ようやく和文トークンと欧文トークンの区別をつけたところから逆行するので理解が追いついていません…。「ノード化の際，その時点での is_cjk の値を参照して欧文・和文組版処理を切り替える．」で大丈夫かどうかは，欧文TeX想定で書かれたマクロから意図せず和文組版されるケースが出てくるかどうかにかかると思います。

zr-tex8r commented 2 years ago

今更ですが，和文文字トークンと欧文文字トークンの区別を一切なくし，…のようにするのは互換性を考えなさすぎ？

まず気になるのが \textquotedblleft の類のLICR系のマクロ（これは欧文が想定されている）なんだけど、これはchardefトークンに帰着されるので、考慮中の仕様では問題にならないらしい。（LuaTeX-jaではchardefも和文になりえるので対策が必要なようだが。）

h-kitagawa commented 2 years ago

いろいろ遊んでみていますが，

@d cs_token_flag=@"1FFFFFFF {amount added to the |eqtb| location in a
  token that stands for a control sequence; is a multiple of~@@"1000000, less~1}

この値は現在の 2^29-1 より増やすのに気が進まなくなってきました． tangle.ch で制限を緩和させればいいのでしょうけれど……．

256 以上の欧文文字トークンのノード化（\noderecipe とか）なども悩んでいますが，そちらは別 issue を立てようと思います．

h-kitagawa commented 1 year ago

すっかりご無沙汰です．まとまって作業できる時間がやっと取れたので，ここ二週間ぐらい一から考え直しています．

@aminophen さんが以前 Slack で，「XeTeX に pTeX の和文組版を載せる」といった趣旨の発言をされていた覚えがあります．当時は私はその方針には反対だったのですが，実際にコードを書いてみたところ，悪くない気がしてきました．

aminophen commented 1 year ago

ご無沙汰しております。こちらも Slack で・GitHub で色々と意見だけ言っておきながらその後何も検討も動けていませんでした。もうすっかり忘れてしまったので，一から勉強し直しています。(u)pTeX 特有の重要な概念として「①和文文字トークン」「②和文文字ノード」がある中で，現在の①の挙動は expl3 とって不都合があるので，維持したい機能を残しつつ欧文文字トークンに近づけたいという話でしたね。

思いつきに過ぎなかった「XeTeX に pTeX の和文組版を載せる」を拾っていただいてありがとうございます。ざっとざっと実装を見てみましたが，整っていて綺麗だと感じました。

和文文字トークンの現在の挙動のうち，維持したいのは「(1バイト1トークンではなく)“見た目の1文字”で1トークンになる」「ノード化すると(欧文文字ノードではなく)和文文字ノードになる」ということくらい（例えば \prebreakpenalty`」=10000 のため）だと改めて思いました。実装していただいているとおり「文字トークンの段階では和文と欧文の区別はない」「\kcatcode は実質廃止・読み出しのみ可能」「代わりに \cjkxcode で諸々制御」で良いですね。禁則テーブルでなく文字ごとに設定可能（→ \prebreakpenalty と \postbreakpenalty を同時に設定できる）というのも含めて良いと思います。

e-upTeX ベースと XeTeX ベースのどちらが良いかは迷います。内部コード Unicode 固定はもう確定路線とみなすと，どちらを使っても実現はできると思えてきましたが，違いは以下くらいのことでしょうか：

aminophen commented 1 year ago

(あと，XeTeX だと dvips が使えなくなって困る人も出てくるのでしょうかね)

h-kitagawa commented 1 year ago
  • XeTeX ベースの場合：欧文文字ノードについて 8-bit TFM (Type1) から Unicode (OpenType) への乗換による組版変化（※ inputenc UTF-8 による 8-bit TFM 利用は XeTeX/LuaTeX では使えないんでしたよね）

styと使用例 のように，一行で「8-bit TFM の状況」，つまり

に戻せれば良いかな．と思いました．

h-kitagawa commented 1 year ago

XeTeX だと dvips が使えなくなって

xdv (pdf) の代わりに dvi を出力させるスイッチ -dvi を https://github.com/h-kitagawa/texlive-source/commit/fd45512f96770163da6c7d290e1256bc22f9f829 で入れてみました．今のところは次の二点が変わるだけです：

e-upTeX ベースと XeTeX ベースのどちらが良いかは迷います。内部コード Unicode 固定はもう確定路線とみなすと，どちらを使っても実現はできると思えてきましたが，違いは以下くらいのことでしょうか：

  • e-upTeX ベースの場合：符号位置 256 以上の欧文文字ノード生成方法の用意 [nptex] 符号位置 256 以上の欧文文字トークンのノード化 #153
  • XeTeX ベースの場合：欧文文字ノードについて 8-bit TFM (Type1) から Unicode (OpenType) への乗換による組版変化（※ inputenc UTF-8 による 8-bit TFM 利用は XeTeX/LuaTeX では使えないんでしたよね）

そうすると，「XeTeX ベースの npTeX + -dvi (A)」「e-upTeX ベースの npTeX (B)」はほとんど差がないように感じます．#153 では，(B) について

そもそも \nptexnoderecipe なる仕組みを考えだしたのは，アクティブ文字 (catcode=13) がコントロールワードで使えないから．

と書いていますが，この点は (A) でも変わらない気がします．

aminophen commented 1 year ago

xdv (pdf) の代わりに dvi を出力させるスイッチ

ありがとうございます。

「XeTeX ベースの npTeX + -dvi (A)」「e-upTeX ベースの npTeX (B)」はほとんど差がない

エンジン自体の機能およびユーザレベルでは仰る通りですね。パッケージ開発者レベルでは差があって，(A)の場合は LaTeX の随所にある「LuaTeX or XeTeX か否か」という名称判定から「Unicode フォントかどうか」という機能判定に変更して回る処置が必要と思われます。ちょうど pLaTeX が eptex から euptex -kanji-internal=euc になったことで誤判定を直して回ったばかりですが，あの時は日本側で済んだところを今度は海外に説明して回らないといけない感じはします。その点に限っては(B)に軍配が上がります。もちろん，機能的には，XeTeX ベースの npTeX の方が「-dvi 無効＝欧文 Unicode フォントできる状態」も存在することの利点があるわけですが。

aminophen commented 1 year ago

(A)を採る場合に「パッケージ開発者レベル〜〜〜(中略)〜〜〜海外に説明して回らないといけない」を避けるため，スイッチ -dvi 有効時に全ての \XeTeX〜 及び \Umath〜 系列プリミティブを未定義にする，というのが良さそう？

aminophen commented 1 year ago

ざっと試しに動かしてみていますが，うまく動いていません。私のところでは Mac でビルドするため nptex.am をこのように改変（nptex_LDFLAGS が肝）していますが，そのせいだとは思えず。

他，エンジンの機能上 e-upTeX との差異に気づいた点：

\documentclass{article}
\begin{document}

\tracingonline1
\showboxdepth10000
\showboxbreadth10000
和文と違って、Latinの禁則は[まだ]完全でない。
\showoutput % "[" の後の禁則ペナルティが入らない
\end{document}

今後の実装については，fam256.ch 及び \epTeXinputencoding の機能を持ってきたときに XeTeX 拡張（それぞれ \Umath〜 及び \XeTeXinputencoding）と衝突しないかが今後気になるところ。

h-kitagawa commented 1 year ago

nptex.am

  • \postbreakpenalty が入らない：下記コード

確認ありがとうございます．直しました．

  • 欧文 Unicode 文字ノード (whatsit) に対して
    • \lastnodechar, \lastnodefont が動かない (-1, \nullfont)

こっちは一筋縄ではなさそうです．Latin\typeout{\the\lastnodechar} のように「Unicode 文字ノードの生成が終わっている」状態だとうまく行くのですが，Latin\the\lastnodechar のような「生成途中」だと動かないですね． なお，同じこと \lastnodetype にも当てはまっています，

aminophen commented 1 year ago

\postbreakpenalty の修正ありがとうございます。

他，不具合がおきる例は作っていませんが

@d ita_kern=3 {|subtype| of kern nodes from \.{\\/}}
@d space_adjustment=3 {|subtype| of kern nodes from \.{\\XeTeXinterwordspaceshaping} adjustment}

ここの subtype 値はずらした方が良さそうです。

あと，nptexdir/memo.txt に書かれていませんが \readpapersizespecial は未実装ですね。それと \pdfsavepos の組方向対応。

aminophen commented 1 year ago

test02.tex の結果： test02-230820-hy.zip

~この理由がまだわかりません…。~

→ [edit] 2023-08-22: 何度か rebuild / fmt 再生成したらいつの間にか治りました。

aminophen commented 1 year ago

欧文ノード生成途中の \the\lastnodechar が -1 の件ですが，\ifnum\lastnodechar〜も同様になります。多分 \relax 前置で生成打ち切りするのが筋でしょうけども。

[edit] 気づいたことを書いていきます。2023-08-24

h20y6m commented 1 year ago

ようやく動かしてためしはじめました。（Windowsは諦めてUbuntu 22.04 on WSL2）

気になったことを書いておきます。

h20y6m commented 1 year ago
  • upLaTeXで\kcatcode`α=15のようにkcatcode=15で欧文扱いにするみたいなことをしているコードはそこそこある気がするので互換性のためにあったほうがよいかも

自分で言っておいてなんですが、あまり意味がないような気がしてきました。 TeX Wikiのこのページの欧文の例のようなものを想定してだったのですが、cjkxcode=0にして欧文扱いするだけでは組めるようにはならないみたいなので、結局xllegacyenc.styのような追加のパッケージが必要になるのならそのパッケージで必要な文字をcjkxcode=0にする機能を提供できれば十分な気がします。

早速実装していただいたのにすみません……

h-kitagawa commented 1 year ago 
* `$c_i\in C_i$ \bye` で Segmentation fault: 11（[h-kitagawa/texlive-source@1942650](https://github.com/h-kitagawa/texlive-source/commit/1942650063daa1a21786b9035dd1af6d77ac196d), [h-kitagawa/texlive-source@3234f2b](https://github.com/h-kitagawa/texlive-source/commit/3234f2b8c8a2bed27230799bbec0d75a7b8598e2) の両方で発生確認）

後で調べます．

* ajmacros.sty (otf.sty) など ISO-2022-JP なファイルをそのままでは読めない

* 要確認：ptexenc による文字コード変換（内部 Unicode な upTeX でも濁点・半濁点の結合文字列は合成されていたはず）が npTeX でどうなるか

XeTeX では input_line が XeTeX_ext.c で定義されていますが，ここで行われる XeTeX による Unicode 正規化やコード変換の前に）ptexenc の input_line2 に通してしまう，というのはどうでしょうか．

こういう点を見ると，e-upTeX ベースの方が「後から発覚する」トラブルが少なくなる気がしており，悩みます．TeXConf2023 で何かは（「悩んでいる」ということでもいいので）報告したいところですが……．

aminophen commented 1 year ago

いろいろな検討をありがとうございます。悩ましいです。

XeTeX ベースはどうかと提案した理由は，あまり深く考えずに

という期待でしたが，安直でしたかね…。確かに，後から発覚するトラブルが少ないのは e-upTeX かもしれません。

悩みつつ要件と論点の整理中…。

npTeX / npLaTeX の目標：(u)pLaTeX ユーザが自然に使える npLaTeX を実現すること

TeXConf2023 で何かは（「悩んでいる」ということでもいいので）報告したいところですが……．

何かしら話すきっかけになればありがたいです。

h-kitagawa commented 1 year ago

こちらこそ，整理をどうもありがとうございます．

h-kitagawa commented 1 year ago

自己レスです．

otf パッケージで使われる「0x110000 以上の文字」をどこまで許すか．

e-upTeX の main_loop において chardef トークンや \char の処理方法を見てみると，

hmode+char_given:
  if check_echar_range(cur_chr) then goto main_loop
  else begin cur_cmd:=kcat_code(kcatcodekey(cur_chr)); goto main_loop_j; end;
hmode+char_num: begin scan_char_num; cur_chr:=cur_val;
  if check_echar_range(cur_chr) then goto main_loop
  else begin cur_cmd:=kcat_code(kcatcodekey(cur_chr)); goto main_loop_j; end;
  end;

のように「kcatcode を算出し，文字トークンとして扱う」ことをしています． また，#46 も考えると，「0x110000 以上の和文文字トークン」まで考えないといけないように思いました．

0x110000 以上の文字コードに対して \catcode, \prebreakpenalty, ... を設定できるようにするのは意味がないように思います，たとえば（0x400000 が境目だったとして）次のようにすると良い？

h20y6m commented 1 year ago

「0x110000 以上の和文文字トークン」まで考えないといけないように思いました．

個人的には 0x110000 以上の 文字トークン は無いほうがいいと思います。 これが存在すると expl3 等に特別扱いしてもらう必要が出てきてしまいます。 （例えば文字列を UTF-16 の HEX 表記（PDF 文字列）に変換するとき 0x110000 以上の文字コードのトークンがあると困ったことになる。）

ところで 0x110000 以上の 和文文字ノード は otf パッケージの \CID コマンド等で必要になりますが、0x220000 以上の文字コードって必要なんでしょうか？

気付いたことの追加：

t-tk commented 1 year ago

ところで 0x110000 以上の 和文文字ノード は otf パッケージの \CID コマンド等で必要になりますが、0x220000 以上の文字コードって必要なんでしょうか？

[upTeX+dvipdfmx] 異体字セレクタ、Unicode合成文字 https://github.com/texjporg/tex-jp-build/issues/46 で述べているような構想があるのみで、いまだに実用には至っておりません。ただ、いつかは使いたいと思っており、 "reserved" のつもりです。

h-kitagawa commented 1 year ago

XeTeXのinterchartokensと和文組版機能（(x)kanjiskip等）が競合しないか

実現自体はなんとかなりそうですが， XeTeX デフォルトだと，CJK 文字は \XeTeXcharclass 1, 2, 3 のどれかに割り当てられており，xetex.ini 中で

  \gdef\xtxHanGlue{\hskip0pt plus 0.1em\relax} % between ideographs
  \global\XeTeXinterchartoks 1 1 = {\xtxHanGlue}
  \global\XeTeXinterchartoks 1 2 = {\xtxHanGlue}
  \global\XeTeXinterchartoks 1 3 = {\nobreak\xtxHanGlue}
  \global\XeTeXinterchartoks 2 1 = {\nobreak\xtxHanGlue}
  \global\XeTeXinterchartoks 2 2 = {\nobreak\xtxHanGlue}
  \global\XeTeXinterchartoks 2 3 = {\xtxHanGlue}
  \global\XeTeXinterchartoks 3 1 = {\xtxHanGlue}
  \global\XeTeXinterchartoks 3 2 = {\xtxHanGlue}
  \global\XeTeXinterchartoks 3 3 = {\nobreak\xtxHanGlue}

と，すでにトークン列が割り当てられていることには注意が必要です（nptex.ini からこれらの行を削除するだけでよい？）．

個人的には 0x110000 以上の 文字トークン は無いほうがいいと思います。

なるほど……それはそうですね．「[upTeX+dvipdfmx] 異体字セレクタ、Unicode合成文字 (#46 )」の（e-upTeX ベースか XeTeX ベースかに関わらず）npTeX での実装方法とも絡んでくるので，引き続き考えてみます．

t-tk commented 11 months ago

全然ついていけておらず、少しずつ読み返しております。シロウト質問です。

多くの LaTeX パッケージのエンジン判定が「XeTeX なら OpenType フォントが使える」と思い込んでいて，欧文 8-bit TFM 対応が弱い

そうすると、"多くのLaTeXパッケージ"は、「XeTeX ベースの npTeX + -dvi (A)」ではそもそも使用できない、ということでしょうか。 "多くのLaTeXパッケージ"は、「8bit欧文tfmが使える」ようには一応なっているので「e-upTeX ベースの npTeX (B)」は使用できるであろう、ということでしょうか。

npTeX が「Unicode 1 文字から 1 トークンができる」かつ「（本文の）欧文フォントは tfmであってUnicode フォントではない」というエンジンになったとして、\sys_if_engine_xetex:pでは「本文の欧文フォントはUnicode」という前提を要求されるので"多くのLaTeXパッケージ"は動かない、ということでしょうか。 あるいは、「XeTeX ベースの npTeX + xdv, pdf出力」で「fontspec, unicode-mathは欧文のみ」が実現できれば「和文フォントはJFM」が拡張機能として混入していても、"多くのLaTeXパッケージ"が動くようなことは可能、ということでしょうか?

「日本語pLaTeX向けパッケージ」は「欧文の本文が8bit tfm」であることを要求していてnpTeXは「欧文の本文が8bit tfm」で動かしたいので、"多くのLaTeXパッケージ"にも「Unicode 1 文字から 1 トークンができる」かつ「欧文の本文が8bit tfm」に対応してもらう必要がある、ということでしょうか?

頭の中が混乱しています。

h-kitagawa commented 11 months ago

多くの LaTeX パッケージのエンジン判定が「XeTeX なら OpenType フォントが使える」と思い込んでいて，欧文 8-bit TFM 対応が弱い

これは

多くの「LaTeX パッケージのエンジン判定」が……

としたほうが良かったでした．すみません． 実際にエンジン判定があるのは，エンジンによって OpenType か 8 bit TFM か切り替える，フォント関連のパッケージが大半だと思います．

こんな感じでしょうか：

あるいは、「XeTeX ベースの npTeX + xdv, pdf出力」で「fontspec, unicode-mathは欧文のみ」が実現できれば「和文フォントはJFM」が拡張機能として混入していても、"多くのLaTeXパッケージ"が動くようなことは可能、ということでしょうか?

私はそのように考えています．

"多くのLaTeXパッケージ"にも「Unicode 1 文字から 1 トークンができる」かつ「欧文の本文が8bit tfm」に対応してもらう必要がある、ということでしょうか?

「どこまでやってもらえるか」は未知数ですが，私は必要性を感じます．

「e-upTeX ベースの npTeX (B)」でも「XeTeX ベースの npTeX + -dvi (A)，ただし XeTeX と判定されない」で問題になる事象は，pdfLaTeX 用のソース

\documentclass{article}
\usepackage{times}
\begin{document}
foobar
\end{document}

を「LuaTeX の \directlua って便利そうだな」という理由からタイプセッタを lualatex に変えても意図通りにならない（フォントが Times にならない）というものと同じことです．