Kazuki Maeda

> 手動で？全角空白を入れろ，ということかなぁ どこが文末なのかは自動判定できないと考えると，それも仕様としてはありえる気がします．英文で文末のピリオドか，省略のピリオドか，という話と似ているような．

doc.sty についてはわかりませんが，multicol.sty については multicol-2017-04-11.sty というファイルが存在しますね．`\usepackage{multicol}[=2017-04-11]` とするとこちらが読み込まれるようです．

遅くなりましたが，きえださんありがとうございます． 仕様変更について，過去の仕様で変だと思われる部分でも，直してしまうと互換性が損なわれてしまうので，どこまで許容するのか，というのが論点の1つだと思っていました．もちろん誰がどう考えても「これじゃ使い物にならん」というほどおかしな点は直してしまえばよいのですが，そうでもない点の変更が入る場合が問題です．既にした変更だと \underline 前後のアキがあります．これは妥当だったのかどうか（私は妥当だと判断しましたが）．バグ混入対策のテストとも共通しますが，妥当性の評価をするにはある程度の数の人の意見が必要だと思いますので，変更点の周知に exppl2e.sty の活用は一つの手でしょうか． それから，Twitter に書かれていたクローズド云々の批判は確かに反省点で，github での作業開始時点でフォーラムなどでの周知もすべきでした．実際にアセトアミノフェンさんがフォーラムやブログ，Twitter などで広く宣伝してからいくつか提案が外から来るようになってきたので，形式をオープンにするというだけでなくて存在を広く知らせることも大事ですね． アセトアミノフェンさんもありがとうございます．David さんに聞いてみたのですね． 現状（潤沢にあるメモリと最新のエンジン）への対応とバグ修正が主ということですね．xetex と luatex の最新版への対応は latexrelease では扱わないという話は，e-pTeX で従来のコードが通らなくなるほどの激しい変更は入らないだろうと考えられるので，platex ではこのケースはないでしょうか．

CTAN への投稿についてもまとめます．create_archive.sh の使い方も（名前は適当だったのですが，LuaTeX-ja から変える必要もないので release.sh にするとか，今後次第では build.sh の方が短くてよいかも）．Github の Wiki を活用するときでしょうか． CTAN は今のところ私が上げていますが，誰でも上げれる体制にした方がよいのは確かです．CTAN では投稿者の名前とメールアドレスを管理しているようで，私以外の人が最初に上げるときは私への確認があるかもしれません．

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

jsclasses については，現状の [CTAN](https://www.ctan.org/tex-archive/macros/latex/contrib/jsclasses) のファイルを見ると .sty も含まれています．README にある通り生成に ISO-2022-JP の環境が必要なためでしょうか．あとは Release Date が README.md に追加されるとよいと思います．