素の pTeX/upTeX バイナリ、バイナリ共通化検討

aminophen commented 7 years ago

TeXconf2017 の雑談で，「pTeX 系列のバイナリ，4つも要らないよね？」という話題が出ました。

eptex/euptex はそれぞれ ptex/uptex の上位互換である
TeX Live では，etex はもはや「素の e-TeX」ではなく，pdftex のエイリアスになっている

という事情から，ptex => eptex，uptex => euptex のエイリアスで済ませることはできないだろうか？という考え方はたしかに一理あるな，と思いました。ptex.fmt や uptex.fmt を作るときに eptex/euptex を使うとどうなるかは考えたことがなかったので，何かご意見を募ります。

以下，私が思いつく疑問点です：

要するに，オプション -etex は無効で，単に eptex -ini 等することになる？
その場合 pdfTeX / Omega 互換プリミティブは？ \lastnodechar，\epTeXinputencoding は？

h-kitagawa commented 7 years ago

その場合 pdfTeX / Omega 互換プリミティブは？ \lastnodechar，\epTeXinputencoding は？

今 -etex なしで eptex -ini したところ，ptex -ini より次の 11 個のプリミティブが多く定義されていますね：

\odelimiter
\omathaccent
\omathchar
\oradical
\pagefistretch
\hfi
\vfi
\omathchardef
\omathcode
\odelcode
\epTeXinputencoding

（数は log の最後の 984 multiletter control sequences の比較でわかります．具体的なプリミティブは WEB ソース探索．）

aminophen commented 7 years ago

eptexdoc.pdf によると，Omega 互換は

本節で述べる追加機能は extendend mode でなくても有効になっている. ただし，後に説明する「レジスタが各種類 65536 個まで」は，extended mode の時に限り有効になる.

pdfTeX 互換は

現在の ε-pTEX で利用できる pdfTEX 由来のプリミティブの一覧を以下に示す. これらは extended mode でないと利用できない.

なので，これと矛盾しないようですね。

\epTeXinputencodig が -etex なしで使えるのはありがたくて，ptex-base に含まれる plain pTeX フォーマット用ファイルを UTF-8 化できることを意味します。

t-tk commented 7 years ago

よく分からないので疑問点を書きます。もし"-etexなし" (互換モード)が不要の場合、ptex => eptex，uptex => euptex のエイリアスも不要で、ptex, uptexにetexの機能を入れてしまえばよいと思います。 (ASCIIさんのオリジナルpTeXから離れる方向になりますが。)

"-etex なし"の方が好ましいケースはあるのか? "-etexなし"を廃止することはできないのか?
もし"-etexなし"が不要の場合、ソース上もマージしてしまうのか? あるいは、あくまで"-etexなし"のバイナリーが作れるように今後も管理を続けるのか?

aminophen commented 7 years ago

もし"-etexなし" (互換モード)が不要の場合、ptex => eptex，uptex => euptex のエイリアスも不要で、ptex, uptexにetexの機能を入れてしまえばよいと思います。

機能を入れてしまえば，というのがよく理解できません。バイナリの数を減らして，かつ呼び出せるコマンド名は残すとすると，エイリアス（シンボリックリンク）は必要ですよね。 → もしかして，これは eptex/euptex というコマンド名自体を廃止して，ptex/uptex を e-(u)pTeX にしてしまう，という意味でしょうか？そうだとするとコマンドが消えて驚く人が出てきそうなので，私は「コマンド名としては少なくとも当面の間残すべき」という意見ですが，方向性としてはありえますね。

最初のコメントで書いた私の「疑問点」は，「エイリアスでいいのでは」という意見を出した方への質問のつもりでしたが，わかりにくかったですね。改めて書くと，

論点は「ptex という名前のコマンドが何であるか」。以下のどれを想定していたのか，どれが好ましいか？
- 現在：(u)ptex コマンドは，拡張なしの (u)pTeX バイナリである。
- 改変案1：(u)ptex コマンドは，e-(u)pTeX バイナリの「-etex 無効状態」である。
- 改変案2：(u)ptex コマンドは，e-(u)pTeX バイナリの「-etex 有効状態」である。つまり，e(u)ptex コマンドと完全に同じである。

私はまだ特に意見を持っていませんし，まだそれぞれの違いを調べている途中の段階です。

-etex なしの方が好ましいケース…実用上では思いついていません。
ソース上もマージしてしまうのか…たとえば現在でも「素の e-TeX バイナリ」は TeX Live に入っていませんが，web2c/ の下に etexdir/ は独立管理されていますね。また，pTeX-ng は「e-pTeX ではないが，e-TeX と pTeX をマージしたもの」なので，そちらは ptexdir/ が消えると困るのかも？

t-tk commented 7 years ago

論点は「ptex という名前のコマンドが何であるか」。以下のどれを想定していたのか，どれが好ましいか？
- 改変案3：(u)ptex コマンドは，e-(u)pTeX バイナリの「-etex 有効状態」である。e(u)ptex コマンドは廃止してしまう。

「e(u)ptex コマンドはdeprecatedだと宣言し何年後かに消す」のような方法もあり得ます。強硬な主張という訳ではなく、他の改革案と比較検討をするための叩き台と捉えてください。

aminophen commented 7 years ago

論点は「ptex という名前のコマンドが何であるか」。以下のどれを想定していたのか，どれが好ましいか？
- 改変案4：(u)ptex コマンドは廃止。e(u)ptex だけを残す。

改変案3と逆の，こういう方向性も叩き台として。

t-tk commented 5 years ago

ご参考に。 pTeX エンジンと upTeX エンジンの開発・メンテナンスとか互換性とか方針とか、upTeX開発初期にいろいろ語ったりご意見を頂いたログが三重大学の奥村先生のところの旧掲示板の記事49189とその前後のリンクにありました。2007年、約12年前です。

t-tk commented 2 years ago

upTeXファミリーのツール群(upbibtex, updvitype, uppltotf, uptftopl)はもともとpTeXファミリーのツール群(pbibtex, pdvitype, ppltotf, ptftopl)の内部コード切り替えという形で作ってあり、内部コードの設定をpTeX用にすればpTeXファミリーと同等に動作するようになっています(以下、コンパチモードと呼びます)。

upbibtex -kanji=internal=euc (ppbibtex) :: pbibtex compatible
updvitype -kanji=utf8 (ppdvitype) :: pdvitype compatible
uppltotf -kanji=utf8 (pppltotf) :: ppltotf compatible
uptftopl -kanji=utf8 (pptftopl) :: ptftopl compatible

まずは、同等に動くことを確認するためのテストを入れました。 https://github.com/texjporg/tex-jp-build/commit/98711ca7a8d04d114717dabef522137ef9bb903c

ppで始まるコマンド名をテスト用に用意しました。当面のテストのためupTeXファミリーのpTeXコンパチモードが動作するように意図したsymbolic linkであり、最終的には、pTeXファミリーのツールのバイナリーを削除し、オリジナルの名前のsymbolic linkに置き換えるつもりです。問題なさそうならば、整理した状態で TeX Live 2023 のプリテスト前にコミットしたいと思っています。

pbibtex については https://github.com/texjporg/pbibtex-manual にあるテストが全部同等に動作することを確認する予定です。

t-tk commented 2 years ago

TeX Live の Build/source/web2c/{,u}ptexdir/ のテストはコミットしました。(r65115, r65116)

pbibtex の https://github.com/texjporg/pbibtex-manual にあるテストは、手元では全部同等に動作していることを確認しました。

t-tk commented 2 years ago

(u)pbibtex は、もう少し詳細に記録しておいた方がよいと思うので issue を分けます。 (u)pbibtex バイナリの整理統合

t-tk commented 2 years ago

今まで pTeX tools は TeX tools にチェンジファイル .ch を当てたもの、 upTeX tools は pTeX toools にチェンジファイル .ch を当てたもの、という関係になっていましたが、今回のバイナリ共通化を機に upTeX/pTeX 共通 tools (コミュニティ版)は TeX tools にチェンジファイル *.ch を当てたもの、という形にしたいと思います。

このタイミングは版数のポリシーを変えるいい機会でもあると思います。今まで upTeX tools は、u1.xx のような版数をupTeX 本体と同期させていた一方で、 pTeX 関連を示す版数 pxxxx は、pTeX 本体の版数 p.4.1.0 などとは独立でした。今後はどうしましょうか?

希望としては、(u)p{pltotf,tftopl,dvitype,bibtex} では upTeX本体の版数との同期は、やめたいです。また、(u)pbibtex のみは j0.35 などの松井さんの jbibtex から引き継いできた歴史を尊重し、j0.xx の版数部分は継続したいです。

案(1): (u)p{pltotf,tftopl,dvitype} は pTeX 本体と同期させる。案(2): (u)p{pltotf,tftopl,dvitype} は pで始まる日付を版数とする。

ご意見があればどうぞ。

現在の版数 pPLtoTF 3.6-p2.0 (utf8.euc) (TeX Live 2023/dev) pTFtoPL 3.3-p2.0 (utf8.euc) (TeX Live 2023/dev) pDVItype 3.6-p0.5 (utf8.euc) (TeX Live 2023/dev) pBibTeX 0.99d-j0.35 (utf8.euc) (TeX Live 2023/dev)

upPLtoTF 3.6-p2.0-u1.29 (utf8.uptex) (TeX Live 2023/dev) upTFtoPL 3.3-p2.0-u1.29 (utf8.uptex) (TeX Live 2023/dev) upDVItype 3.6-p0.5-u1.29 (utf8.uptex) (TeX Live 2023/dev) upBibTeX 0.99d-j0.35-u1.29 (utf8.uptex) (TeX Live 2023/dev)

pTeX 3.141592653-p4.1.0 (utf8.euc) (TeX Live 2023/dev) upTeX 3.141592653-p4.1.0-u1.29 (utf8.uptex) (TeX Live 2023/dev) e-pTeX 3.141592653-p4.1.0-220214-2.6 (utf8.euc) (TeX Live 2023/dev) e-upTeX 3.141592653-p4.1.0-u1.29-220214-2.6 (utf8.uptex) (TeX Live 2023/dev)

今回の統合版の版数(案1) upPLtoTF 3.6-p4.1.0 (utf8.uptex) (TeX Live 2023/dev) upTFtoPL 3.3-p4.1.0 (utf8.uptex) (TeX Live 2023/dev) upDVItype 3.6-p4.1.0 (utf8.uptex) (TeX Live 2023/dev) upBibTeX 0.99d-j0.36 (utf8.uptex) (TeX Live 2023/dev)

今回の統合版の版数(案2) upPLtoTF 3.6-p221201 (utf8.uptex) (TeX Live 2023/dev) upTFtoPL 3.3-p221201 (utf8.uptex) (TeX Live 2023/dev) upDVItype 3.6-p221201 (utf8.uptex) (TeX Live 2023/dev) upBibTeX 0.99d-j0.36 (utf8.uptex) (TeX Live 2023/dev)

aminophen commented 2 years ago

色々と進めていただきありがとうございます。

希望としては、(u)p{pltotf,tftopl,dvitype,bibtex} ではupTeX本体の版数との同期は、やめたいです。また、(u)pbibtex のみは j0.35 などの松井さんの jbibtex から引き継いできた歴史を尊重し、j0.xx の版数部分は継続したいです。

大筋で同意です。ただし upbibtex の is_kanji_str だけは kcatcode キーを引いているので常時 uptex の kcatcode テーブルと同期が必要であることに注意が必要です。この点から upbibtex は「同期していること」を示すのもありかと。

upPLtoTF 3.6-p221201 (utf8.uptex) (TeX Live 2023/dev)
upTFtoPL 3.3-p221201 (utf8.uptex) (TeX Live 2023/dev)
upDVItype 3.6-p221201 (utf8.uptex) (TeX Live 2023/dev)
upBibTeX 0.99d-j0.36-u1.29 (utf8.uptex) (TeX Live 2023/dev)

個人的にはこれを推します。

t-tk commented 2 years ago

コメントありがとうございます。 upBibTeX の u1.29 同期はどうしようか迷ったところです。入れることにします。いろいろなテストで問題ないので4つともそろそろ TeX Live svn にコミットしようと思います。

t-tk commented 2 years ago

TeX Live svn にコミットしました。r56177, r65178 残件は、pTeX, e-pTeX, upTeX, e-upTeX の4個をどうするか、になりました。

aminophen commented 2 years ago

r65177, 65178

少し気になったのですが kpse_set_program_name が p〜から up〜に変わることによって kpse 変数の参照が切れてしまうことはないでしょうか？

t-tk commented 2 years ago

dvipdfmx の実体が xdvipdfmx であるとか pdflatex の実体が pdftex であるとかと同様に、 kpse の検索について、/hoge/fuga/pdvitype みたいなコマンドは updvitype への symbolic link でも元の binary でも同様の検索が行われるはずです。何かテストの方法を考えてみます。

t-tk commented 2 years ago

やはり、symbolic linkの場合は、置き換えた名前の方で kpse_set_program_name されるみたいです。

https://github.com/texjporg/tex-jp-build/blob/e3558a2b5eb91a1f94de2987e867d9b8193e9339/source/texk/web2c/uptexdir/kanji.c#L528

aminophen commented 2 years ago

ありがとうございます。大丈夫だとわかって安心しました。

t-tk commented 1 year ago

ptex/eptexのソースコードの整理を検討します。私が分かっていないので、まず現状の把握から。

ptex -ini と比較して -etex なしの eptex -ini に追加されているプリミティブ11 個：

\odelimiter
\omathaccent
\omathchar
\oradical
\pagefistretch
\hfi
\vfi
\omathchardef
\omathcode
\odelcode
\epTeXinputencoding

pTeX は BSD 3条項、OmegaはGPL2、pdfTeX はGPL2 のようです。 Omega拡張、pdfTeX拡張を pTeX に当てること自体は問題ないはずですが、ソースコードを完全にマージしてしまうのはまずそうです。

eptex-base.ch の冒頭に

% In this TeX Live realisation
% eptex.web is build from:
%       tex.web
%       + etexdir/etex.ch               e-TeX changes
%       + etexdir/tex.ch0               glue
%       + tex.ch                        Web2C changes
%       + etexdir/tex.ech               e-TeX+Web2C changes
%
% and eptex.ch from:
%       + eptexdir/etex.ch0             glue
%       + ptexdir/ptex-base.ch          pTeX changes
%       + eptexdir/eptex.ech            e-TeX+pTeX changes
%       + eptexdir/etex.ch1             glue
%       + eptexdir/fam256.ch            borrowed from Omega
%       + eptexdir/pdfutils.ch          borrowed from pdfTeX
%       + tex-binpool.ch                compiled pool file

かなり想像が入っているので違っていたらご指摘お願いします。上記eTeX拡張ではない11個のプリミティブのうち \epTeXinputencoding 以外の10個は Omega拡張で fam256.ch に対応している、という理解でよいでしょうか。 fam256.chは eTeX拡張を当てた後に当てる順番になっている。 Omega拡張は機能としては eTeX 無効の時にも使えるものなので、 chファイルの順番を入れ替えて e無しptex のソースの方に持ってきて ptex.fmt の段階で使えるようにすることは可能。 pdfTeX拡張は eTeX拡張に依存しているので ptex のソースの方に持っていくことは出来ない。

それで、現状の ptex, eptex の構成を組み直す案としては、「Omega拡張と \epTeXinputencoding を eptex から ptex に移す」ということは、やってもいいかなと思います。また、「\epTeXinputencoding が -etex なしで使えるのはありがたい」のならば、別案として、「Omega拡張を eptex の方のまま」\epTeXinputencoding の移動だけ単独でもやってもいいかな、と思います。

\epTeXinputencoding を ptex に持っていくならば名前は \pTeXinputencoding に換えた方が ptex になじむような気がします。

しかし、上記のような案では結局 ptex のソースコードを整理した感じにはならないので、メンテナンス性の向上などのメリットもあまりないのかも、という気がしてきています。

h-kitagawa commented 1 year ago

上記eTeX拡張ではない11個のプリミティブのうち \epTeXinputencoding 以外の10個は Omega拡張で fam256.ch に対応している、という理解でよいでしょうか。

そうです．

pdfTeX拡張は eTeX拡張に依存しているので ptex のソースの方に持っていくことは出来ない。

正直言いますと，e-pTeX で追加された（pTeX 拡張 + e-TeX 拡張以外の）各種プリミティブのうち，どれを extended mode でのみ使用可能にしているか，というのは結構適当です．たとえば \pdfstrcmp は pdfTeX の compatibility mode で利用可能ですが，e-pTeX では extended mode でのみ利用可能です．この差異はおそらく次によるものです：

私が pdfTeX のコードを読んだとき，extended mode か否かほぼ確認していなかった
pdfTeX 由来のプリミティブを e-pTeX に追加したのは，LaTeX やパッケージのためにという面が大きい

この機会に「pdfTeX で compatibility mode で使えるものは e-pTeX でもそうする」と整理するのも良いですね．

Omega拡張と \epTeXinputencoding を eptex から ptex に移す

これの良い副作用として，eqtb[] の各要素内に 32 bit 整数 (integer) を 2 つ 格納することができることが挙げられます．pTeX で何の役に立つか，すぐには思いつきませんが．

aminophen commented 1 year ago

素の pTeX バイナリは廃止して「eptex の compatibility mode」が ptex を兼ねるようにするならば，\epTeXinputencoding を pTeX の change file に移す労力はかけずに現状維持でいいように思います。
fam256.ch についても同様です。

aminophen commented 1 year ago

メンテナンスをしやすくするためには pdftex.web や xetex.web のように一個の WEB にまとめてしまう（あるいは nptex-base.ch でやっているように一個の change file にまとめる）のが良いと思いますが，そのときライセンスについては微妙ですね。「pdfTeX と Omega に由来する部分には GPLv2 が適用される」というデュアルライセンスを表記することになるのでしょうか。

同じことは XeTeX でも起きていて，あちらは表面上 MIT (X11) License ですが pdfTeX 由来分についてはほぼ pdftex.web からそのまま移植されているので GPLv2 を表記していないのはグレーです。

t-tk commented 1 year ago

私の理解では、pTeX の場合、大元が ASCII さんが宣言している BSD3条項であり、「改変はいいけどASCIIの名前は明記してください」、であり、GPLの思想は、「GPLを好きなだけ改変してもいいがGPLを守ってください(コピーレフトが強い)」なので、ASCIIの名前明記にはそぐわない、だと思います。「デュアルライセンス」でよく聞くのは、「二つがまざっているよ」ではなくて、著作権者が「どっちを使ってもいいよ」と宣言することだと思います。ドワンゴさんにお願いして pTeX は「BSD3条項と GPLv2のデュアルライセンスですよ」と宣言してもらえると、pTeX拡張はデュアルライセンス、Omega拡張とpdf拡張はGPLv2 と宣言して、混ぜてしまうことが可能になると私は思います。

https://ja.wikipedia.org/wiki/%E3%83%A9%E3%82%A4%E3%82%BB%E3%83%B3%E3%82%B9%E3%81%AE%E4%BA%92%E6%8F%9B%E6%80%A7 を見ると BSD3条項とGPLは、混ぜてもよくて、GPLで配布になる、とのことです。なので、先ほどの発言は撤回します。

aminophen commented 1 year ago

BSD3条項とGPLは、混ぜてもよくて、GPLで配布になる、とのことです。

はい，これがいわゆる「GPL汚染」とも言われる所以です。ソースコードを一個のファイルにすることによって，せっかくアスキーが緩いBSD3条項で公開してくださっている部分まであたかもGPLであるかのように見えてしまうのは嫌だなと思います。

アスキー由来の ptex-base.ch は残して BSD3条項を明記
pdfTeX 由来と Omega 由来もそれぞれ分離したまま残して GPLv2 を明記
e-(u)pTeX は「その両方のソースからビルドされるから GPLv2 になる」と明記したうえで著作権者はアスキー + ~~pdfTeX作者 + Omega作者~~ + texjporgを併記 (edit: いや，GPLは著作権でないから並列するのは変なのか?)

こうするほかないのですかね。

t-tk commented 1 year ago

{,e}{,u}ptexdir/am/{,e}{,u}ptex.am を眺めて (e)(u)ptex の作られ方を見ています。結構複雑ですね。 eptex, euptex 両対応のために(特にeuptexで)グルーが多く必要になっているのが見て取れます。 ptex,uptex,eptex,euptexのバイナリーを4種類とも作っているのを整理統合しない限り整理にならないように思えてきました。私の uptex の部分は、ASCII pTeXの後続という意識が強く、BSD3条項で出していました。また、現状のeuptexの作られ方は euptex.ch の部分を見ると大筋では、 ptex-base.ch → uptex-m.ch → eptex.ech → fam256.ch → pdfutils.ch の順番になっているようです。

もろもろの事情を考えると、私の現在考えている方向性は、大筋では以下です。

素の ptex は当面残すが、将来 euptexバイナリへのシンボリックリンクにする。
uptex-m.ch, eptex.ech, fam256.ch, pdfutils.ch は、大筋今の区分けのまま残す。 uptex-m.ch は BSD3条項、fam256.chとpdfutils.ch (pdfTeX 由来と Omega 由来)はGPLv2として明記する。 (euptexバイナリの配布はGPLv2相当になる)
uptex, eptexのバイナリの作成は無しにして euptexバイナリへのシンボリックリンクにする。
platex は euptex --kanji-internal=euc で動くようにする。
eptexdir/ は不要になる。グルーは euptex 向けに調整したものだけを残す。(eptexが作れなくなるがよしとする)

euptexdir/am/euptex.am より

# Generate euptex.ch
euptex.ch: tie$(EXEEXT) euptex.web $(euptex_ch_srcs)
    $(tie_c) euptex.web $(euptex_ch_srcs)
euptex_ch_srcs = \
    eptexdir/etex.ch0 \
    ptexdir/ptex-base.ch \
    uptexdir/uptex-m.ch \
    euptexdir/euptex.ch0 \
    eptexdir/eptex.ech \
    eptexdir/etex.ch1 \
    euptexdir/euptex.ch1 \
    $(euptex_ch_synctex) \
    eptexdir/fam256.ch \
    euptexdir/pdfstrcmp-eup-pre.ch \
    eptexdir/pdfutils.ch \
    euptexdir/pdfstrcmp-eup-post.ch \
    eptexdir/suppresserrors.ch \
    eptexdir/char-warning-eptex.ch \
    tex-binpool.ch

t-tk commented 1 year ago

上記の案で、心配になりそうな点は「platex は euptex --kanji-internal=euc で動くようにする。」だと思います。まずは手元でいろいろ動かしてみて、作戦を考えようかと思います。

aminophen commented 1 year ago

素の ptex は当面残すが、将来 euptexバイナリへのシンボリックリンクにする。

段階的にする意図はどのようなことでしょうか？個人的には，変更は一度にやってしまうほうがわかりやすくて（もし互換性のためにバージョン判定が必要になっても分岐を減らせるし）ありがたいのですが…。もはや素の pTeX を残す意味は薄いのではと思っています（ptexenc ライブラリ化 + pTeX-4.0.0 にメジャー更新した時点で，すでにコミュニティによる色々な改修が入っており，アスキー版とは異なるものになっている）。

私は以下のようなものをイメージしていました。

ptex-base.ch + uptex-m.ch + eptex.ech とそれに必要なグルーをまとめて新しい「日本語化 change file」を作る = BSD3条項
fam256.ch と pdfutils.ch はそのまま残す = それぞれ GPLv2
バイナリは euptex だけにする = GPLv2 相当
ptex, eptex, uptex は全て euptex バイナリへのシンボリックリンクにする
platex は「Windows では "euptex --kanji-internal=sjis"」「Unix では "euptex --kanji-internal=euc"」とする（従来と同じにするため）

日本語化部分をまとめるだけでもかなり整理できるのではないかなと思います。今は4つのバイナリを作るために順番を気にしてグルーをたくさん用意しているのですが，1つのバイナリにすれば順番を気にせずに済むのでグルーが不要になります。

ptex と eptex のバイナリを削除して euptex ベースにした時に (e)p(la)tex の「仕様」が変化するのは https://github.com/texjporg/ptex-manual/issues/4#issuecomment-868380122 の「和文文字トークンがカテゴリーコードを持つかどうか」だけだと理解しています。これは影響がゼロではないでしょうが，和文文字のカテゴリーコードを変更することは想定されていないと推察されることから許容範囲だと思いますし，将来のメンテナンス性と天秤にかければ些細な差です。

t-tk commented 1 year ago

euptexの整理は、こんな感じですかね。日本語周りを一つ(BSD)にして

    eptexdir/etex.ch0 \
    ptexdir/ptex-base.ch \
    uptexdir/uptex-m.ch \
    euptexdir/euptex.ch0 \
    eptexdir/eptex.ech \
    eptexdir/etex.ch1 \
    euptexdir/euptex.ch1 \

synctexはまあいいとして

    $(euptex_ch_synctex) \

ここは維持

    eptexdir/fam256.ch \

pdfTeX周りはまとめて

    euptexdir/pdfstrcmp-eup-pre.ch \
    eptexdir/pdfutils.ch \
    euptexdir/pdfstrcmp-eup-post.ch \

あとは必要に応じて整理

    eptexdir/suppresserrors.ch \
    eptexdir/char-warning-eptex.ch \
    tex-binpool.ch

h-kitagawa commented 1 year ago

euptexの整理は、こんな感じですかね。

まさしくこれで良いと思います．これで作業してみます．

synctexはまあいいとして

ここも e-TeX + pTeX + glue のところで change file が入り乱れていますが，後でも良さそうです．

euptex_ch_synctex = \
        synctexdir/synctex-def.ch0 \
        synctexdir/synctex-ep-mem.ch0 \
        synctexdir/synctex-mem.ch0 \
        synctexdir/synctex-e-mem.ch0 \
        synctexdir/synctex-ep-mem.ch1 \
        synctexdir/synctex-p-rec.ch0 \
        synctexdir/synctex-rec.ch0 \
        synctexdir/synctex-rec.ch1 \
        synctexdir/synctex-ep-rec.ch0 \
        synctexdir/synctex-e-rec.ch0 \
        synctexdir/synctex-p-rec.ch1

aminophen commented 1 year ago

euptexの整理は、こんな感じですかね。

はい，良いと思います！

h-kitagawa commented 1 year ago

機械的に (tie -c 利用）ですが https://github.com/texjporg/tex-jp-build/tree/refactor_euptex でまとめました．

h-kitagawa commented 1 year ago

あとは必要に応じて整理 eptexdir/suppresserrors.ch \ eptexdir/char-warning-eptex.ch \ tex-binpool.ch

suppresserrors.ch は（自分で作ってなんですが）悩みどころです．ロジック自体は LuaTeX から引っ張ってきましたが，LuaTeX は WEB 言語ではないので，ライセンス的にはどうなんでしょうか．
char-warning-eptex.ch はもともと pdfTeX 向けに書かれた char-warning-pdftex.ch (public domain) を e-pTeX 用に書き直したものです．XeTeX 向けにも同様のパッチがあります．こちらはまとめてしまってもよいのかなあ．
tex-binpool.ch は各エンジン共用なのでまとめないほうがいいですね．

aminophen commented 1 year ago

char-warning-eptex.ch

これは tracingstacklevels.ch, showstream.ch, partoken.ch と同列の「TeX Live 拡張」にあたると思います。どうやらそれらは敢えて pdftex.web や xetex.web にまとめずに個別の機能ごとに change file として置かれているので，そうすることに意味があると捉えて「まとめない」方が良さそうです。

t-tk commented 1 year ago

いろいろご対応ありがとうございます。 ptex-manual.tex を eptex と euptex --kanji-internal=euc の間で比較してみたところ、ほぼ同じなのですが違いは出てしまいました。許容範囲でしょうか?

%#!make ptex-manual.pdf
\documentclass[a4paper,11pt,nomag,dvipdfmx]{jsarticle}
\usepackage[textwidth=42zw,lines=40,truedimen,centering]{geometry}

%%%%%%%%%%%%%%%%
% additional packages
\usepackage[T1]{fontenc}
\usepackage{booktabs,enumitem,multicol}
\usepackage{newpxmath}
% common
\usepackage{ptex-manual}

%%%%%%%%%%%%%%%%

\begin{document}

\begin{cslist}
\csitem[\.{inhibitglue}]
  この命令
\begin{itemize}
 \item 本命令は現在のモードが（非限定，限定問わず）水平モードのときしか効力を発揮しない
       （数式モードでも効かない）．
       段落が和文文字「\verb+【+」で始まり，その文字の直前にメトリック由来の空白が入る
\end{itemize}
\end{cslist}

\end{document}

ptex-manual-p.dvi は eptex, ptex-manual-ue.dvi は euptex --kanji-internal=euc でコンパイル。 *.dvispc は dvispc -a hoge.dvi > hoge.dvispc の結果。

diff --git a/ptex-manual-p.dvispc b/ptex-manual-ue.dvispc
index c077cc1..a633d64 100644
--- a/ptex-manual-p.dvispc
+++ b/ptex-manual-ue.dvispc
@@ -113,7 +113,7 @@ y0
 push
 right3 3562094
 set2 0x244a
-w2 11060
+w2 4853
 set2 0x2424
 x3 331786
 set2 0x214a
@@ -167,7 +167,7 @@ fntdef1 51 0 689631 655360 0 4 'jisg'
 fntnum51
 set2 0x215a
 pop
-right3 663572
+right3 849785
 fntnum48
 setchar23
 fntnum43

t-tk commented 1 year ago

ロジック自体は LuaTeX から引っ張ってきましたが，LuaTeX は WEB 言語ではないので，ライセンス的にはどうなんでしょうか

ロジックに何か特殊な内容が含まれないのであれば、実装が別ならば著作権などは実装した人のものになると思います。なので @h-kitagawa さんが LuaTeXのライセンス如何によらず、ご自由に決めればよいと思います。

h-kitagawa commented 1 year ago

いろいろご対応ありがとうございます。 ptex-manual.tex を eptex と euptex --kanji-internal=euc の間で比較してみたところ、ほぼ同じなのですが違いは出てしまいました。許容範囲でしょうか?

切り詰めました（\xkanjiskip が入るか否かのようです）が，よくわかっていません．

\documentclass[]{minimal}
\usepackage[T1]{fontenc}
\xspcode23=3 % \textcompwordmark
\begin{document}
  \leavevmode\hbox{【}\textcompwordmark.
\end{document}

--- a-p.txt 2022-12-11 19:50:03.375580117 +0900
+++ a-up.txt    2022-12-11 19:50:03.045583252 +0900
@@ -17,7 +17,7 @@
 fntnum28
 set2 0x215a
 pop
-right3 1641030
+right3 1798679
 fntdef1 45 0xC31EAB1 655360 655360 0 8 'ecrm1000'
 fntnum45
 setchar23

aminophen commented 1 year ago

%#!uptex -ini
\input plain

\font\x=ec-lmr10 \x
\font\y=rml \y

\inhibitxspcode`あ=2

\tracingonline1
\showboxdepth10000
\showboxbreadth10000

\setbox0=\vbox{a\hbox{あ}a}\showbox0

\end

なぜか (e)uptex で \inhibitxspcode=2 が効いていないようですが理由がわかりません…。

t-tk commented 1 year ago

inhibit_xsp_code の table の大きさが不足しているみたいです。バグでした。 256 → 512 に拡張すればよいように思います。

ptex ::

@d cat_code_base=auto_xspacing_code+1
  {table of 256 command codes (the ``catcodes'')}
@d kcat_code_base=cat_code_base+256
  {table of 256 command codes for the wchar's catcodes }
@d auto_xsp_code_base=kcat_code_base+256 {table of 256 auto spacer flag}
@d inhibit_xsp_code_base=auto_xsp_code_base+256
@d kinsoku_base=inhibit_xsp_code_base+256 {table of 256 kinsoku mappings}
@d kansuji_base=kinsoku_base+256 {table of 10 kansuji mappings}
@d lc_code_base=kansuji_base+10 {table of 256 lowercase mappings}

uptex ::

@d enable_cjk_token_code=auto_xspacing_code+1
@d cat_code_base=enable_cjk_token_code+1
  {table of 256 command codes (the ``catcodes'')}
@d kcat_code_base=cat_code_base+256
  {table of 512 command codes for the wchar's catcodes }
@d auto_xsp_code_base=kcat_code_base+512 {table of 256 auto spacer flag}
@d inhibit_xsp_code_base=auto_xsp_code_base+256
@d kinsoku_base=inhibit_xsp_code_base+256 {table of 256 kinsoku mappings}
@d kansuji_base=kinsoku_base+256 {table of 10 kansuji mappings}
@d lc_code_base=kansuji_base+10 {table of 256 lowercase mappings}

h-kitagawa commented 1 year ago

adjust_hlist 内の @<Insert a space after the |last_char|@> のところで，cx を mod max_cjk_val しないまま代入していたのが原因のようです．https://github.com/texjporg/tex-jp-build/commit/b1429925ce076ace54c7549322442a01d5968b84 で直しました．

inhibit_xsp_code の table の大きさ

私も気にはなっていたので，禁則テーブルと inhibit_table を 1024 ずつに増やしておきました．npTeX では「文字ごとに保持」ですかね．

aminophen commented 1 year ago

b1429925ce076ace54c7549322442a01d5968b84

ありがとうございます。

TeX Live svn r65246
euptex-base.ch にも 6cbb008b098b960d49bd0fcef777fcfab0fd94ce で反映

t-tk commented 1 year ago

ありがとうございます。パッチとコミットとリファクタリングもご対応ありがとうございます。 tableの大きさは無関係でしたね。しかし 1024 への拡張ありがとうございます。初期化のところも拡張が要ると思い、入れてみました。 TeX Live svn r65248

先日の ptex-manual.tex 以外にもいろいろな platex の入力で試してみて、eptex と euptex --kanji-internal=euc の間で違いが見つからなくなりました。「euptex ベースにした時に (e)p(la)tex の「仕様」が変化する」というのは、通常の platex 入力に対して違い無し、実際の出力も違い無し、と言えると思います。まだ若干バグが心配ではあります。どこかにいいテスト用のサンプルはありませんかね?

aminophen commented 1 year ago

初期化のところも拡張が要ると思い、入れてみました。

確かにそうですね，ありがとうございます。

テスト用のサンプル

用意しないといけないとは思いつつ，全然手が出ていません…。

t-tk commented 1 year ago

tests-shipout/atbegshi_nextpage.tex を試して気づいたのですが、 euptex --kanji-internal=euc で bxjalipsum.sty が動きません。

bxjalipsum.sty の版数は \ProvidesPackage{bxjalipsum}[2017/03/01 v0.3a]

aaa.tex ::

\documentclass{article}
\usepackage{bxjalipsum}
\begin{document}
Hi!
\end{document}

❯ euptex -fmt=uplatex-euc --kanji-internal=euc -kanji=utf8 aaa.tex
This is e-upTeX, Version 3.141592653-p4.1.0-u1.29-220214-2.6 (utf8.euc) (TeX Live 2023/dev) (preloaded format=uplatex-euc)
 restricted \write18 enabled.
entering extended mode
(./aaa.tex(guessed encoding #3: ASCII = utf8)
pLaTeX2e <2020-02-02>+2 (based on LaTeX2e <2020-02-02> patch level 2)
L3 programming layer <2020-02-14>
*************************
* Loading platex.cfg.
*************************
(./platex.cfg(guessed encoding #5: UTF-8 = utf8)) (/usr/share/texlive/texmf-dist/tex/latex/base/article.cls(guessed encoding #5: ASCII = utf8)
Document Class: article 2019/12/20 v1.4l Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo(guessed encoding #6: ASCII = utf8)))
(/usr/share/texlive/texmf-dist/tex/latex/bxjalipsum/bxjalipsum.sty(guessed encoding #5: ASCII = utf8)
! Invalid KANSUJI char ("3044).
<argument> \bxjl@cc

l.646 }

? x
No pages of output.
Transcript written on aaa.log.

engineの判定で上手くいっていないようです。

%% \bxjl@engine
\let\bxjl@engine=b
\bxjl@next\kanjiskip{\let\bxjl@engine=p}
\bxjl@next\enablecjktoken{\let\bxjl@engine=u}
\bxjl@next\luatexversion{\let\bxjl@engine=l}
\bxjl@next\XeTeXversion{\let\bxjl@engine=l}

aminophen commented 1 year ago

euptex --kanji-internal=euc で bxjalipsum.sty が動きません。

とりあえずファイルしておきます → https://github.com/zr-tex8r/BXjalipsum/issues/1

aminophen commented 1 year ago

(e)(u)ptex --version などの Copyright / Primary author は

Copyright 2022 D.E. Knuth. Primary author of e-upTeX: Peter Breitenlohner.

のままで良いでしょうか？ lib/printversion.c → ... → (e)(u)ptexextra.h の

#define COPYRIGHT_HOLDER "D.E. Knuth"
#define AUTHOR "Peter Breitenlohner"

を変更しても良いと思います。この機会に全て Japanese TeX Development Community にしてはどうかと思いますが，如何でしょう？

t-tk commented 1 year ago

現状、AUTHOR が Peterさんになっているのは eptex と euptex のようです。 ptex, uptex は、NULLになっていて、ptex --version では Primary author のところに Knuth が出るようです。いずれにせよ、「(e)(u)ptex 全て Japanese TeX Development Community」にすることに賛成です。

❯ grep  AUTHOR *ptexdir/*ptexextra.h
eptexdir/eptexextra.h:#define AUTHOR "Peter Breitenlohner"
euptexdir/euptexextra.h:#define AUTHOR "Peter Breitenlohner"
ptexdir/ptexextra.h:#define AUTHOR NULL
uptexdir/uptexextra.h:#define AUTHOR NULL

t-tk commented 1 year ago

TeX Live 2023のpretestが約1か月あと(2/10)に迫ってきてしまいました。 TeX Live 2023は以下の2案のうちいずれかにしたいと思っています。 platex は、もう euptex --kanji-internal=euc (euptex-euc)を実体とする方向にしたいです。まだバグ(eptexベースのplatexと動作が意図に反して異なってしまう)が不安ですが、差分を見つけにくく、あったとしても軽微なものになりそうなので、バイナリ共通化を進めてしまいたい。案1は、eptexのバイナリを残して、euptex-eucベースのplatexで問題が発生しても eptexベースの従来法のplatexに戻りやすいようにする保険を意図しています。案2は、eptexも残さず、バイナリ共通化を優先したものです。どうしましょう。案2は過激でしょうか。

現在の版数 pTeX 3.141592653-p4.1.0 (utf8.euc) (TeX Live 2023/dev) e-pTeX 3.141592653-p4.1.0-220214-2.6 (utf8.euc) (TeX Live 2023/dev) upTeX 3.141592653-p4.1.0-u1.29 (utf8.uptex) (TeX Live 2023/dev) e-upTeX 3.141592653-p4.1.0-u1.29-220214-2.6 (utf8.uptex) (TeX Live 2023/dev)

今回の統合版(案1) etex付きに絞る。platexはeuptex --kanji-internal={euc,sjis}, uplatexはeuptexを実体とする。 ptex -> eptex (alias) eptex (binary) uptex -> euptex (alias) euptex (binary)

今回の統合版(案2) euptexに絞る。platexはeuptex --kanji-internal={euc,sjis}, uplatexはeuptexを実体とする。 ptex -> euptex (alias) eptex -> euptex (alias) uptex -> euptex (alias) euptex (binary)

aminophen commented 1 year ago

案1（eptex バイナリの保険あり，platex は euptex で動く）に +1 しておきます。何かあった時のリビルド要求はしたくないので…。

euptex で作る platex で動かないものは

bxjalipsum https://github.com/zr-tex8r/BXjalipsum/issues/1
pxchfon https://github.com/zr-tex8r/PXchfon/issues/10

これらは @zr-tex8r さんにお願いしましょう。

他にもあったでしょうか。

h-kitagawa commented 1 year ago

私も案 1 に +1 です．

t-tk commented 1 year ago

コメントありがとうございました。統合版(案1)で作ってみてコミットしました。ここのmaster, TeX Live svn (r65543) に入っています。不慣れなことをしているので不安です。意図通りでない動作や不具合がありましたらお知らせください。 platex を euptex --kanji-internal={euc,sjis} ベースにするのは、Build/source/texk/web2c ではないところでやっているような気がします。今回は何もしていません。 AUTHORを「(e)(u)ptex 全て Japanese TeX Development Community」にする、は済みです。 TeX Live 2023向けに Build の下を触るのは、不具合修正を除いて、ここまでにしようかと考えています。

今回の統合版(案1) etex付きに絞る。platexはeuptex --kanji-internal={euc,sjis}, uplatexはeuptexを実体とする。 ptex -> eptex (alias) eptex (binary) uptex -> euptex (alias) euptex (binary)

binary をただの alias へ置き換えただけなので、 https://github.com/texjporg/tex-jp-build/issues/32#issuecomment-336882901 でいうところの、改変案1になっていると思います。

改変案1：(u)ptex コマンドは，e-(u)pTeX バイナリの「-etex 無効状態」である。

texjporg / tex-jp-build

素の pTeX/upTeX バイナリ、バイナリ共通化検討 #32