Extended allocation for e-pTeX (FAM256)

[aminophen]

LaTeX が LuaTeX 向けの Extended allocation を導入したように、pLaTeX にも FAM256 patched な e-pTeX 向けのコードを導入するとよいのではという議論がどこかにあった気がしましたので、Issue を立ててみようと思います。

ptex-base の eptexdoc.pdf にもあるように、残念ながら現状では pLaTeX からの FAM256 フル活用が容易にはなっていません。

• 最小限のコード
• パッケージ化？ qa:52744, qa:52767, qa:52799

のあたりの試みが参考になるかと思いますが、せっかくなので pLaTeX kernel で何かできることはないかというのを考えてみたいというご提案です。

[kmaed]

色々提案いただいているのに，あまり反応できていなくてすいません．私も北川さんと同じく，ちょっと仕事に追われています．

私は昔 pLaTeX で数式フォントで色々遊んでいた覚えがあるのですが，最近はそういう遊びは LuaTeX の unicode-math などでやってしまって，pLaTeX が必要な場合は最低限の数式フォントで済ませてしまうので，この手の話は関心がなくなり気味です（必要な実例が身の周りで出てきたらまた違うかもですが）．元々 pLaTeX が必要な場面で脚注アキが入るのが気になっていただけなのが，なぜか CTAN に pTeX 関連ファイルをアップロードする羽目になっているというのが現状で，本当はもっと pTeX に関心がある人に取り組んでほしいと思っています．そういう人は潜在的にはまだまだいると思うのですが……．

まあ，人がどうしてもいなければ，テストとデバッグと CTAN へのアップロードはできるので協力いたします．具体的な提案までするのはちょっと苦しいかもしれないです．

Issue と関係ないですが：Twitter も見ていますが，変えた結果あとで文句を言われるのは嫌なので，どういうことをやってはいけないのかの基準は決めた方がよいのかもしれないです．platexrelease があるのでこれで対応せよとは言えますが……．e-pTeX のバイナリ自体変えてしまっているので，pLaTeX をある程度変えてしまってもよいというか，むしろ過去の出力と不整合が生じた部分についてはそうあるべき，というのが私の意見です．\underline については，私はアキが入るのが気になっていたのでむしろ修正されてよいのですが，アキが入るのが前提な人がいる可能性もあるかもしれないです．気づいていない人の方が多いかもですが．（ascmac はまったく使わないのでよくわかっていない．）

[aminophen]

この Issue もそうですが、自分自身が提案しているというつもりはあまりないのでお気になさらずに… というか、LuaTeX-ja の committer の方々に pLaTeX の面倒をみていただくのはアレなので、committer ではない私がやるほうがよいだろうと思って commit しているというのが今の状態です。まあ LuaTeX-ja も pLaTeX と無縁ではないでしょうから、こちらの議論が少しは LuaTeX-ja に貢献できるかなとは思います。ただ、私もそんなに pLaTeX に興味があるわけではないので、ほんとうはもっと関心のある方に取り組んでほしいという点では kmaed さんと同じなのだと思います。

さらにいうと、texjporg が継承した pLaTeX を自由に CTAN へ出せる状態にするまでが一番大変だろうと思っていましたので、そこに達するまで（あるいは長年のギャップを埋めるまで）の作業には協力できたらいいなと思っていたのが正直なところです。そのあとのことはあまり考えていなくて、過去のフォーラムを読み返して Issue を立てるところまでやっておけば、興味を持った方が出てくるかもしれないという期待を込めて、以下略

今の状態だと長続きしそうにないので、TeX Live 2016 が出たら（ちょうどその時期から私も時間がとれなくなってきます）、もう少し議論をオープンにしてしまおうと思います。

[kmaed]

closed なところで意見を募ったのはちょっと問題ありだったのかもしれません．元々はフォーラムで聞いたのですが，角藤先生以外反応がなかったので……．場の問題は色々あるとは思っています．

（あの ML にはフォーラムで反応のある人は大体いると思うのですが，期待よりも反応は薄いです……．まあ，私もそれほど反応できていないのでなんとなくわからんでもないです．）

[aminophen]

元々はフォーラムで聞いた

あの場で反応しなかったのは年末年始に PC をネットに繋いでいなかったのが大きいです、すみません。私は ML では既に他の方の反応があった場合は黙っていることも多いですが、そうでなければ極力賛否にかかわらず意思表示をしようと思ってはいます。（とはいえ実際難しいけれど…）

[kmaed]

あの場で反応しなかったのは年末年始に PC をネットに繋いでいなかったのが大きいです、

あっ，それはそうかも．年末年始はめずらしく余裕ができてしまうもので……．

[aminophen]

qa:52799 のパッケージたちを、最新の環境で確かめてみました。

1. ofamex1.sty
   \DeclareMathAlphabet で定義された \math?? の使用数の制限を緩めます．

この ofamex1.sty は、新 LaTeX2e カーネルがやっているのと全く同じコードでした（ただし、独自に命名された \max@mathgroup を \e@mathgroup@top に置き換えた場合）。したがって eptexdoc.pdf に書かれているように「\DeclareMathAlphabet を用いて数式用アルファベットを使うだけなら」の

\mathchardef\e@mathgroup@top=256

を e5361eb で exppl2e.sty に入れました。ついでに \e@alloc@chardef と \e@alloc@top も増やしてよいはずですから、これも入れました（これで ZR さんのコレの分は完了）。

2. ofamex2.sty
   symbolfont の使用数の制限を緩めます．

これはそのままでは動かなくなってしまいました。実は、LaTeX 2015/01/01 で「latexrelease には入っていないが、変更された定義」というのが存在して、それが \DeclareSymbolFont です。これは

! LaTeX Error: Too many symbol fonts declared.

というエラーを出すだけの変更のようです。つまり、LaTeX の方針としては「\DeclareMathAlphabet の制限を LuaTeX や XeTeX で緩める（＝これが ofamex1.sty に相当）が、\DeclareSymbolFont の個数は従来のまま緩めない（＝ ofamex2.sty に相当する処理はカーネルに入れていない）」ということのようです。

たしかに、qa:52767で

amsfonts.sty の中で，\edef\yen{\noexpand\mathhexbox{\hexnumber@\symAMSa}55}
という呼び出しがあります．これは変更したくないので，\hexnumber@ を変更しました
(そしてそれを他の部分でも多用しています)．これに関する副作用があるかもしれま
せん．

とあるので、副作用のリスクを冒してまでカーネルでは拡張できないのかもしれません。したがって、pLaTeX カーネルで提供しうるのはこの時点でストップだと思います。

しかし同時に、これは「LuaLaTeX も標準では symbol font が 16 個までという制約がある」ことを意味します。もし \DeclareSymbolFont を拡張するのであれば、新設のエラーを削除するコードを含めた「外部パッケージ」を作成して e-(u)pTeX / LuaLaTeX 両用とすれば役に立つ気がします。もちろん、副作用があるかもしれないことは留意しないといけないですね。

[aminophen]

メモ：「FAM256 パッチ」は e-TeX な pTeX のなかでも pTeX-ng (Asiatic pTeX) では無効になっていることを利用して、\omath... の存在チェックが正しく機能していることを確認できました。

\DeclareSymbolFont が 16 で制限されているのは phst/lualatex-math#7 からも意図的だとわかりました。たしかにフォーマットでサポートするのは押し付けがましいというのもわかる気がします。

I suspect it would be too intrusive for the format by default to use \U... but a package could add extended versions, say \UDeclareSymbolFont , \UDeclareMathSymbol etc that did go past 16 and use \U.... versions of the math primitives.

[aminophen]

ymt さんの 2009 年のコードを最新の LaTeX2e に追随させたものを

• https://github.com/aminophen/mathfam256

に置きました（ライセンスは未定）。platex / uplatex では動いていそうですが、lamed は動くかもしれませんが未チェックです（そもそも LaTeX team は lamed を想定しているのかどうかも不明なので後回し）。lualatex はまだサポートしていません。

[aminophen]

上の mathfam256 を CTAN にあげてみました。 https://ctan.org/pkg/mathfam256

[aminophen]

texjporg/ptex-manual#6 (comment) で発覚したのですが，なんと \let\float@count\e@alloc@top が抜けていて折角の 65536 個のレジスタを一部活用できていなかったようですorz

[davidcarlisle]

If you want us to detect \omathchardef in the base latex code and use the extended range as we do for luatex, let us know, but if that just complicates your patching, we could leave it as it is...

[aminophen]

I think adjustment in plcore.ltx is enough; testing against \omathchardef in latex.ltx will detect Aleph as well, which you would hesitate to support...

[davidcarlisle]

yes I was wondering if accidentally improving support in aleph/lamed was a good thing or a bad thing:-) OK I will not change the code (I may add a comment that the range is extended in plcore for ptex, so people (especially me) are not confused when looking at this later.

…

On Sat, 19 Oct 2019 at 09:53, Hironobu Yamashita ***@***.***> wrote: I think adjustment in plcore.ltx is enough; testing against \omathchardef in latex.ltx will detect Aleph as well, which you would hesitate to support... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3?email_source=notifications&email_token=AAJVYATBTBWGVWAWCZD7N3TQPLDG7A5CNFSM4CDXMVP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBXJDIQ#issuecomment-544117154>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJVYAWFJQCLHY5EFEL2PATQPLDG7ANCNFSM4CDXMVPQ> .

[aminophen]

Done (2cb7ea6).