今後の pLaTeX/upLaTeX の開発について

[aminophen]

forum:1967 で告知したとおり、「今後の pLaTeX/upLaTeX の開発方針」をこの Issue でオープンに議論します。具体的なことはまだ何も決まっていないと言っていいです。そこで大前提として

• 開発リポジトリの管理、および議論の場を GitHub に一元化する
• upLaTeX の方針は pLaTeX の方針決定に準じる

これらをいま宣言します。まず決めておきたいのは

• どこまでコミュニティ版 pLaTeX での改変を許容するのか
• なるべくバグを出さないためにどうするか

です。目標は「次のリリースまで」くらいの曖昧なもので、これも未定ですのでゆっくりあります。（ただし万が一、その期間に何らかのバグフィックスが必要になった場合には、当該箇所にだけ例外的に拙速な決定を下しますのでご容赦ください。）

それでは、ご質問やご意見など遠慮なくお願いします。

---

いきなり議論よろしくお願いします、というのもアレなので、以下、取っ掛かりになりそうなら参考にしてください。（もちろん無視していただいても構いません）

一点めに対しては、ひとつの意見として「LaTeX カーネルと同じ基準にする」がありましたが、具体化が必要でしょう。二点目に対しては、2016/07/01 版で「テスト用 sty ファイルを TeX Live に入れておいて使ってもらう」を試し始めましたが、もしかするとより良い方法があったかもしれず、「リリースされるものとまんま同じ物が試せるべき」との意見もいただいています。

[yuw]

• どこまでコミュニティ版 pLaTeX での改変を許容するのか

この点に関してですが，ここでいう改変というのは仕様変更という意味でしょうか．もしそうであるなら，誰かから提案され，それが妥当であるとなった場合は改変すればよいと思います．妥当性の評価はまた別の問題とも思いますが．

バグフィックスの意味であれば，バグということが明らかになれば修正していくべきであろうと思います．

[aminophen]

ここでいう改変というのは仕様変更という意味でしょうか．

仕様変更という意味でした。後付けになってしまいますが、狭義にとらわれず、或る（好ましくないとされる）挙動が仕様なのかどうかわからない、という状況下でのコード書き換えおよび新仕様策定も包含させてください。「妥当であるとなった場合は改変すればよい」、私も同じ認識です。

バグフィックスに関しては、yuw さんと同じ意見です。

[aminophen]

「LaTeX カーネルと同じ基準にする」について、LaTeX team の David さんから直接いただいたコメントを一部抜粋します（転載許可もいただいております）。基本的には、LaTeX 配布物に含まれる latexchanges.tex や ltnews*.tex に各変更の背景や意図が書いてあるそうです。

---

[1] What is the policy to improve the LaTeX-kernel?

1a. When do you make improvements except for trivial bugs?

Really there hasn't been any intention to add major features to the kernel, however apart from bugs the main driving force is recognition of the greater memory available now, so for example many more commands have been made robust as they were only fragile originally as we could not afford any more csnames at the time to make them robust. Related to this there has been some recognition of newer engines, so extended etex register allocation and extended Unicode catcode settings where appropriate.

1b. When do you use latexrelease?

If the change is purely related to the macro layer so that latexrelease can be used to define the new macro on old distributions or define the old macro with new distributions then the changes are guarded in the source with \IncludeInRelease and have docstrip guards so that both old and new code are copied to latexrelease.sty.

If the change is related to a change in the engine (for example many changes this year in luatex, and most recently the change to the number of character classes in xetex) then usually we don't use latexrelease guards as someone with a new distribution can not do \usepackage[2014/01/01]{latexrelease} and use the old luatex code as it simply does not work anymore as the lua and tex interfaces have changed.

[2] Do you have the policy description to the change history especially since you changed not to use fixltx2e? (We could find what you changed, NOT why you changed, from change.txt

as I mentioned above, the document latexchanges.tex has some background to each of the changes covered by the latexrelease package, so I hope that helps.

---

まだ私は latexchanges.tex や ltnews*.tex を精査しきれていないので（従来も少しずつ pLaTeX に反映させてはいましたが）、とりあえず David さんにありがとうとだけ伝えた状態です。個別に疑問が生じたらまた聴いてみてもいいんじゃないかと思います。

[kmaed]

遅くなりましたが，きえださんありがとうございます．
仕様変更について，過去の仕様で変だと思われる部分でも，直してしまうと互換性が損なわれてしまうので，どこまで許容するのか，というのが論点の1つだと思っていました．もちろん誰がどう考えても「これじゃ使い物にならん」というほどおかしな点は直してしまえばよいのですが，そうでもない点の変更が入る場合が問題です．既にした変更だと \underline 前後のアキがあります．これは妥当だったのかどうか（私は妥当だと判断しましたが）．バグ混入対策のテストとも共通しますが，妥当性の評価をするにはある程度の数の人の意見が必要だと思いますので，変更点の周知に exppl2e.sty の活用は一つの手でしょうか．

それから，Twitter に書かれていたクローズド云々の批判は確かに反省点で，github での作業開始時点でフォーラムなどでの周知もすべきでした．実際にアセトアミノフェンさんがフォーラムやブログ，Twitter などで広く宣伝してからいくつか提案が外から来るようになってきたので，形式をオープンにするというだけでなくて存在を広く知らせることも大事ですね．

アセトアミノフェンさんもありがとうございます．David さんに聞いてみたのですね．
現状（潤沢にあるメモリと最新のエンジン）への対応とバグ修正が主ということですね．xetex と luatex の最新版への対応は latexrelease では扱わないという話は，e-pTeX で従来のコードが通らなくなるほどの激しい変更は入らないだろうと考えられるので，platex ではこのケースはないでしょうか．

[aminophen]

David さんに聞いてみたのですね．

直接きいてみるという提案および初動は @kuroky49 さんです。ありがとうございました。

David さんのを受けて、もし仮に同じ方針をとるならば…という観点で私が思ったことは：

• pLaTeX カーネルや周辺パッケージの命令も、必要そうなものをいくつか robust にする？
• pLaTeX も e-pTeX 拡張を利用してもよい？（要するに Extended allocation for e-pTeX (FAM256) #3 のこと）
• pLaTeX に加える修正や改変は、ほとんど全部 platexrelease 化できるはず。（pTeX や e-pTeX は非互換な変更がずっと起きていないから）

latexrelease パッケージ対応については、platexrelease の実装を始めた時点で一応いろんな可能性を考慮したつもりですので、向こうの方針ががらりと変わらないかぎり大丈夫です。ただ、ガードの付け方のドキュメント化を私がサボっているので、皆様に迷惑をかけていると思います。数か月以内には…。

[kmaed]

CTAN への投稿についてもまとめます．create_archive.sh の使い方も（名前は適当だったのですが，LuaTeX-ja から変える必要もないので release.sh にするとか，今後次第では build.sh の方が短くてよいかも）．Github の Wiki を活用するときでしょうか．

CTAN は今のところ私が上げていますが，誰でも上げれる体制にした方がよいのは確かです．CTAN では投稿者の名前とメールアドレスを管理しているようで，私以外の人が最初に上げるときは私への確認があるかもしれません．

[aminophen]

#12 の議論で yuw さんから

特定の，しかも自動的にロードされるわけでもないパッケージを用いたときに起る現象への対処は，クラスファイルレベルで行うべきでないと考えます．

という意見がでたのは本件に関係しそうなことなので、貼っておきます。仮に何かを変えるとしたとき、その変え方についてもなにか合意形成する必要があるという事例でしょう。（具体的な事例から少しずつ全般の方針を決めていけばよいのではないかと思うので、こういうやりかたを今後もとります）

[aminophen]

上記の「具体的な事例から少しずつ」のひとつとして書きます。

仕様変更について，過去の仕様で変だと思われる部分でも，直してしまうと互換性が損なわれてしまうので，どこまで許容するのか，というのが論点の1つだと思っていました．

「\footnote の合印直後の改行 (#16)」は「過去の仕様で変だと思われる部分」の一例にあたるように思います。私はこれに関しては直したほうがよいと思っているのですが、いかがでしょうか。

[yuw]

#16 では形式的にですが，仕様変更の具体的主張がなされておらず，コードのやりとりによって実験が行われている状態に見えます．仕様変更の主張は何かを明記しないと，主張の取り違えや途中からの議論参加の阻害要因になりかねません．

「\footnote の合印直後の改行 (#16)」は「過去の仕様で変だと思われる部分」の一例にあたるように思います。私はこれに関しては直したほうがよいと思っているのですが、いかがでしょうか。

次の2点についての仕様のようにみえますが，現行仕様と変更後の仕様案をはっきりと主張してからでないと，仕様変更の是非について議論が始められないと思います．

1. 合印前後のアキ量
2. 合印前後での改行の許容

[aminophen]

現行仕様と変更後の仕様案をはっきりと主張して

ご指摘ありがとうございます。そのようにしてみました。

[aminophen]

ぼちぼち次のリリースのタイミングを計りたいと考えています。

• 脚注関係の仕様変更 (\footnote の合印直後の改行 #16)
  • 合印直後の改行許可（ただし \footnotetext でペナルティがある場合は禁止）
  • 合印直前の改行禁止
  • 合印直前をベタ組に

について告知することが最優先事項だと思っています。（追記：これはカーネル plcore に導入した状態でリリースして問題ない変更内容だと思いますので、そのようにします。）

ほかに入れたいと考えている修正は、Issue で既出の

• jltxdoc.cls：\verb の前の \xkanjiskip を復活 (jltxdoc.cls の \verb #14)
• plext.sty：\multicolumn のエラー解消 (横ディレクション中の縦組の表の \multicolumn #17)

のほか

• plext.sty：tabular 環境と \parbox の余分な \xkanjiskip 削除 (aminophen/platex@715330f)
  • pTeX の仕様変更にあわせ、pLaTeX カーネルと同様に \null を追加
• tascmac.sty：pdfLaTeX/XeLaTeX 対応 (aminophen/platex@f80b268)
  • pTeX 系以外の場合に \tbaselineshift などのプリミティブを使用しない定義を採用させる

です。ご意見等お願いします。

[aminophen]

platex / uplatex / jsclasses すべて、いったんリリースしましょう。（texconf16 の前の最後のリリースになるでしょうし、「美文書」に入るバージョンになる可能性も高いです。）

ドキュメント pdf はリビルドしました。脚注関係は完全にカーネルに取り込みましたので、exppl2e から削除してあります。あとはリリース作業なのですが、platex / uplatex はなぜか手元で create_archive.sh がうまく動かず .tds.zip が出来ない状態で、jsclasses も今回初なのでよくわからないです。

[kmaed]

.tds.zip が出来ない状態

うまく動いていれば，platex.zip を展開すれば platex.tds.zip が出てくるはずです．

[aminophen]

無事動きました（win32）。tar が別の何かと干渉したかなにかで落ちていただけでした…

$ git tag 2016-09-03
$ ./create_archive.sh

platex.zip と uplatex.zip を CTAN にアップすれば良いのですね。jsclasses の方はいまは ctan2tds では角藤さん頼みになっていますが、platex のときと同じ手続きが必要でしょうか。

[kmaed]

jsclasses については，現状の CTAN のファイルを見ると .sty も含まれています．README にある通り生成に ISO-2022-JP の環境が必要なためでしょうか．あとは Release Date が README.md に追加されるとよいと思います．

[aminophen]

とりあえず platex.zip と uplatex.zip をアップしてみました（前回と違う人がアップロードしたのでどういう風になるのかは分かりませんが…）。

jsclasses のほうは、たしかに CTAN には generated files もありますが、TeX Live には手動でコミットされていますので、おそらく使われていない状態なのだと思います。platex と同じ方法を採用してもらえそうな create_archive.sh を作ってアップしてみました。何か問題があったら私に連絡がくるのだと思います。

[aminophen]

TeX ユーザの集い 2016 で述べましたが、当面の間、pLaTeX / upLaTeX の開発については

1. 副作用が明らかになさそうな拡張であれば早めに pLaTeX 本体に反映
2. 影響の大きそうな変更は（告知期間を兼ねて）長めにテスト
3. 年度の前半は（不安定になることを覚悟して）積極的に変更を導入
4. 年度終わりには（よほど critical なバグ等を除いて）pLaTeX 本体を凍結

という方針でいこうと思います。詳細については講演資料を参照いただければと思います。

TeX Live 2016 の期間中の pLaTeX カーネルのリリースは、（よほど critical な問題を fix する必要が生じない限り）次回を最後にする予定です。リリースする立場にある私の都合で、予定は 2016/11/29 ということで設定します。

予定する変更は

• カーネル
  • Extended allocation for e-pTeX (FAM256) #3 の FAM256 対応（exppl2e から昇格）
  • hyphen.cfg のバナー #25 のフォーマット作成に関する修正
• テスト版 exppl2e
  • アクセント付き文字前後の \xkanjiskip #5 のアクセント文字パッチ（引き続き）
  • \strutbox の仕様 #20 の \strutbox パッチ（引き続き）
  • （もし間に合えば 強制改行と \par で Underfull 警告が出ない（← platex と pdflatex でハイフネーションが変わる） #27 の強制改行とハイフネーションのパッチ）
• plext.sty
  • plext.sty: 横組時の \rensuji #26 の横組時の \rensuji

です。

なお、TeX Live 2017 pretest 期間に入るタイミングで、#5, #20 をカーネルに導入します。これと同時に、#26 の plext の大規模改修を行う予定です。

[aminophen]

次回 pLaTeX と upLaTeX のリリースについて考えていることを書きます。

次回は TeX Live 2017 pretest が始まった直後にリリースする予定です。具体的には 2017/04/08(土) 辺りです。ただし、4月以降は私の身分が変わるため、どうしてもコミットが減らざるを得ないです。

そこで、以下の手順を考えています。

• pretest に出す一ヶ月前、すなわち 2017/03/08（すなわち今からあと3週間）辺りには、リリース予定版と全く同じものを master ブランチに確立。
• 確立次第、変更点を周知のうえ、テストケース増設に注力。

なお pretest では、多少バグの恐れがあっても exppl2e の修正点は全部カーネルに含めてしまうつもりです。アクセント文字のパッチも入れます。pretest が終わる直前（5月中旬）の時点で、危険なものや反対が出たものだけ再び外し、exppl2e に戻せばよいと思っています。

したがって、残っている pLaTeX issue の修正を master に随時マージしていき、upLaTeX のほうも sync させていきます。

[aminophen]

pLaTeX2e / upLaTeX2e 2017/07/29 を来週末に出す予定です。

• tabular 内のJFMグルーの入り方 (tabular 内のJFMグルーの入り方 #43)
• plext の揃え位置 (plext の挙動（揃え位置） #24)
• algorithm2e と ascmac の衝突回避 (#15)

[aminophen]

月末をめどに pLaTeX2e <2017/07/29>+1 を出します。日付そのまま，patch level だけ +1 するつもりで，カーネルの直接の修正は以下の2点です：

• \adjustbaseline の基準文字 (\adjustbaseline の基準とする全角文字を「全角空白」から「漢」へ #48)
• 禁則ペナルティの設定間違いの修正 (禁則ペナルティの設定間違い？ ptex-base#5)

テスト版 exppl2e.sty の方には，以下の修正を入れます。

• \ref のあとのスペースファクター (目次の中の \ref で後ろの空白が喰われる ＋ スペースファクター #31)
• \verb の冒頭の空白対策 (\verb の冒頭の空白 #49)
• \inhibitglue の省略形の垂直モード対応 (\inhibitglue の省略形 \< #50)
• \text... の左側イタリック補正を入れるためのリバート (\text... の \xkanjiskip 対策は必要か？ #51)

なおアクセント合成文字のベースライン補正と \xkanjiskip 対策 (#5) は保留のままになっていますが，どうしましょうかね。一年経ちますがどのくらいの人が \RequirePackage{exppl2e} しているか未知数ですよね。

[aminophen]

↑ 月末が多忙のため無理そうなので，早めることにして明後日 8/27 にアップロードします。

• \nolinebreak で \xkanjiskip が消える (和欧文間に \nolinebreak があるとき当該箇所に \xkanjiskip が挿入されない #52)

は割と緊急のフィックスなので，もう exppl2e ではなくカーネルに入れてしまいます。さらに

• tabbing 環境の行冒頭の JFM グルー (tabbing 環境の JFM グルーの入り方 #53)

は exppl2e に入れます。

[aminophen]

次のリリースへ向けて，大丈夫そうなものから順に本体へ移してみました。

• 相互参照 \ref の後のスペースファクター調整＝本家 LaTeX との互換性向上 (目次の中の \ref で後ろの空白が喰われる ＋ スペースファクター #31)
• \verb の冒頭の空白を保持＝本家 LaTeX との互換性向上 (\verb の冒頭の空白 #49)
• tabbing 環境の冒頭要素の JFM グルー削除 (tabbing 環境の JFM グルーの入り方 #53)
• \text... 命令のイタリック補正の正常化＝本家 LaTeX との互換性向上 (\text... の \xkanjiskip 対策は必要か？ #51)
• \inhibitglue の省略形 \< の改良 (\inhibitglue の省略形 \< #50)
• jclasses の基準和文文字を全角空白から「漢」へ，\box0 を空に (\adjustbaseline の基準とする全角文字を「全角空白」から「漢」へ #48)

[aminophen]

次のリリースへ向けて，大丈夫そうなものから順に本体へ移してみました。

この時から一ヶ月経っているので，2017/10/28(土)に platex / uplatex をリリースします。

[aminophen]

簡易的ではありますが英語ドキュメント (u)platex-en.pdf を追加したので，これを TeX Live に入れる目的でいったん platex / uplatex を今日 2017-12-06 付でリリースします。カーネル等の変更は，platexrelease パッケージの内部実装絡みのちょっとした改良と，タイポの修正だけです。

なお #56 に書いたような「共通化」は TeX Live 2017 の間は入れないつもりです。ただし，バナーを定義するコードの改善だけは，今回のリリースに含めます。

[aminophen]

TeX Live 2017 の最後がいつもよりひと月ほど早い

12mar: tlnet (and TL'17) frozen, pretest starts

なので，それまでに異論が出なければ，2018 pretest 開始次第すぐに

• pLaTeX -> upLaTeX の sync を必要なくする (platex / uplatex の sync の効率化など #56)
• ascmac と nidanfloat の独立 (ascmac と nidanfloat を独立させたい #62) → 同時に縦組での pict2e との共存 (#60) も入れる
• クラスファイルが意図する和文スケール値 \Cjascale の規約化 (jsreport クラスと otf パッケージ jsclasses#63)

を出すつもりでいます。他にも何かあれば変更点は追加されるかもしれません。