新 LaTeX カーネル対応

[aminophen]

forum:1558 で出ていた LaTeX2e kernel の変更に関する話です。

論点1： pLaTeX2e の LaTeX2e への追随

従来の pLaTeX も LaTeX の変更に追随してきたようですので，今後も LaTeX に合わせていく必要があると思います。ZR さんが

「今回の改修で変更されたもの」と「plcore で上書されるもの」の共通部分

を調べてくださった段階では，\em と \eminnershape だけだったようですが，2014年までにも数回は 2ekernel に“互換性を壊さない細かい変更”が入ったはずですので，調べたほうがよいかもしれません。

論点2： latexrelease への対応？

Forum やその解説 1，2 にもありますが，2015/01/01 リリース版からは従来の fixltx2e の機能やその他変更が 2ekernel にすべてとりこまれ，代わりに latexrelease を使えば過去の 2ekernel を emulate できるという仕様になっています。

pLaTeX2e でどこまでサポートするかですが，三段階あると思います。

1. そもそも latexrelease はサポートしない
2. latexrelease で過去の LaTeX2e kernel を emulate しても pLaTeX2e kernel の定義が失われない程度，つまり「pLaTeX が LaTeX の定義を上書きしているが，LaTeX 側でその箇所に変更が入った場合」だけをサポートする
3. pLaTeX2e kernel も完全に同じ仕組みを導入し，過去（現存するもの以降）の pLaTeX を emulate できるようにする

どれがよいでしょうか。1. が楽そうですが，仮に 1. だと latexrelease を読み込んだだけで「未だかつて存在しなかった（？）変な pLaTeX」ができてしまいます。

%\RequirePackage[1995/12/01]{latexrelease}
\documentclass{jarticle}
\begin{document}
あa{\em いb{\em うc}}
\end{document}

これを処理すると「\mcfamily \upshape → \gtfamily \itshape → \mcfamily \upshape」ですが，一行目のコメントを外すと「\mcfamily \upshape → (\mcfamily) \itshape → \mcfamily \upshape」になってしまいます。選択肢 2. や 3. も，手元で試してみた限りでは実装自体は可能そうですので，どの挙動がふさわしいか（あるいはどれもふさわしくないか）で決定してよいと思います。

ご意見よろしくお願いいたします。

[kmaed]

論点2について．platexrelease.sty でも作ればよいのでしょうか．実装自体は latexrelease の仕組みを流用すれば容易なのかな？ 論点1にも関係しますが，「pLaTeX の上書きが latexrelease でさらに上書きされて云々」については要調査ですね．

2 の案は中途半端な気がするので，やるなら 3 ではないかと思いますが，いかがでしょうか．

[aminophen]

コメントありがとうございます。私も 3. 推しでして，platexrelease.sty を作るつもりでいます。もうひとつ，platex.fmt のフォーマットファイル内に「latexrelease.sty は読まれたが platexrelease.sty は読まれなかった場合」に警告を出すコードを入れようと考えています。もう少し手元で動かしてから platexrelease.sty のテスト版を出してみますので，それを見てから導入の可否を決めるのでもよいです。

[aminophen]

platexrelease 実装の一例を，\em の定義の部分だけを使った実験で示します。

dtx をいじるのはちょっと面倒なので，試しに出来上がった ltx のほうをいじってみます。まず，新しい pldefs.ltx では以下のように \eminnershape を活用すると仮定します。

\DeclareRobustCommand\em
        {\@nomath\em \ifdim \fontdimen\@ne\font >\z@
                       \eminnershape \else \gtfamily \itshape \fi}
\def\eminnershape{\mcfamily \upshape}

新しい定義の日付と，昔の定義を，ともに platexrelease.sty に保存します。

%%% LaTeX2e core: ltfssini.dtx / pLaTeX2e core: plfonts.dtx
\IncludeInRelease{2015/01/01}{\eminnershape}{\eminnershape}%
\DeclareRobustCommand\em
        {\@nomath\em \ifdim \fontdimen\@ne\font >\z@
                       \eminnershape \else \gtfamily \itshape \fi}%
\def\eminnershape{\mcfamily \upshape}%
\EndIncludeInRelease
\IncludeInRelease{0000/00/00}{\eminnershape}{\eminnershape}%
\DeclareRobustCommand\em
        {\@nomath\em \ifdim \fontdimen\@ne\font >\z@
             \mcfamily \upshape \else \gtfamily \itshape \fi}%
\let\eminnershape\@undefined
\EndIncludeInRelease

こうすると，最初に挙げたソース例を

%\RequirePackage[1995/12/01]{platexrelease}
\documentclass{jarticle}
\begin{document}
あa{\em いb{\em うc}}
\end{document}

のようにして一行目のコメントを付けたり外したりすれば，最新の pLaTeX と過去の pLaTeX の emulate を切り替えることができます。これだけだと platexrelease の必要性に気づきにくいので，plcore.ltx にも警告を出させようと考えています。

\AtBeginDocument{%
  \@ifpackageloaded{latexrelease}{%
    \@ifpackageloaded{platexrelease}{}{%
      \@latex@warning@no@line{%
        Package latexrelease is loaded.\MessageBreak
        Some patches in pLaTeX2e core may be overwritten.\MessageBreak
        Consider using platexrelease.\MessageBreak
        See platex.pdf for detail}%
    }%
  }{}%
}

こうすれば，少なくとも何か変だという情報は見えるようになります。（ほんとうは \AtBeginDocument ではなく \documentclass の時点で警告を出すのが最善ですが…）

[aminophen]

実際に導入すべきかどうかはまだ議論の余地がありますが，exp_2ekernel branch に platexrelease もどきを作るための dtx 改変版を置きました。
git fetch してから git checkout exp_2ekernel
で試すことができます。

目的の異なる変更が一度のコミットに混在して入ってしまったため，commit を取り消して再度 log を作り直しました。(2016/02/04)

[zr-tex8r]

ちゃんとは検討していないのですが、疑問点を書いておきます：

• 「LaTeXのリリース日付」と「pLaTeXのリリース日付」が相違することを許して、
  問題が起こることはないか？
  例えば、pLaTeXのパッケージにおいて(p)latexreleaseの仕組を使おうとすると、
  破綻するような気がする。
• 今後もし、アスキーがpLaTeXを更新したとすると、
  asciimwは何を指すことになるのか？

[aminophen]

コメントありがとうございます。

「LaTeXのリリース日付」と「pLaTeXのリリース日付」が相違することを許して、 問題が起こることはないか？

これは dtx を書こうと思って初めて気づいたのですが，本家 latexrelease.sty は \latexreleaseversion の値は ltvers.dtx に由来します。したがって，同じ実装（latest と current オプションの違いに注目）を目指すと plvers.dtx に \platexreleaseversion を記載する（というか \pfmtversion と同じ値が流用される）ことになります。そうすると必然的に pLaTeX の日付を LaTeX の日付に合わせることは非現実的になるので，「日付が相違する前提」で問題が起きないように実装する必要があると思っています。

今後もし、アスキーがpLaTeXを更新したとすると、 asciimwは何を指すことになるのか？

おっしゃるとおりです ;) 仮にアスキーが新しい pLaTeX を出したとして，それを emulate しようとすると明らかに破綻します。（それが，ドキュメントには書いたけれど実装の意欲がわいていない理由だったりします）

[zr-tex8r]

同じ実装（latest と current オプションの違いに注目）を目指すと

自分がこの問題（latexreleaseのpTeX対応）を考えていたときは、「パッケージでlatexreleaseを運用する」のと同じ扱いにすることを考えていた気がします。（\pfmtversion とかは誰も見てないのでどうでもよい。）マニュアルの3.1節に書かれている方法とかを駆使して何とかできないでしょうかね……。

[zr-tex8r]

確認ですけど、仮に、

「日付が相違する前提」

として、「LaTeXカーネルのリリース日付が L、pLaTeXカーネルのリリース日付が P」に設定された、とすると、仕様として、カーネルの状態はどうなる想定ですか？
L の時点の現物のLaTeXカーネルを読み込んだ後に、P の時点の現物のpLaTeXカーネルを読み込んだもの、でしょうか？

[aminophen]

日付に関しては一度話し合う必要があると考えていました。一度私の意図をはっきりさせておいたほうがよいですね。

「LaTeXカーネルのリリース日付が L、pLaTeXカーネルのリリース日付が P」に設定された、とすると、仕様として、カーネルの状態はどうなる想定ですか？

いま仮実装してみたものは，おっしゃるとおり『L の時点の現物のLaTeXカーネルを読み込んだ後に、P の時点の現物のpLaTeXカーネルを読み込んだもの』を想定しています。そして，今まさに起きているような「pLaTeX でせっかく定義したのに latexrelease すると消されてしまう」という状況が起きないように，『platexrelease を読み込んだ場合には必ず L ≦ P である』ことを保障しようとしています。　← これを保障しても十分ではなかった

以上の想定の根底には，「一般のパッケージと pLaTeX kernel は異なる」という考えがあります。

一般のパッケージは LaTeX の或る動作をベースにして作られるでしょうから，古い LaTeX でも新しい LaTeX でも同じ結果になるように latexrelease の機構に乗せて「LaTeX の変化に追随する」のだと思います。しかし，pLaTeX kernel は LaTeX の或る動作を書き換えてそれ自身がベースになるというイメージなので，自分自身が latexrelease と同等の機構 (= platexrelease) を持ってしかるべきで，そこから latexrelease をコントロールするのがよいのではないかと考えて，とりあえず仮実装したのが今のものです。これが妥当なのかどうか，そもそも latexrelease のサポートが必要なのかどうか，これらがいま検討したい点です。

[aminophen]

latexrelease への対応は pLaTeX kernel 全体からみるとあまり本質ではない気もしますので，いま exp_2ekernel にある platexrelease の機構で明らかな不具合がなければ merge してしまおうと思います。方針としては上に書いたとおりです。もっと精査すべき，興味のある部分は別のところにあるわけですし，いわばインフラとなる platexrelease の部分は早いほうがよいと思います。

＃ コードは書いてはみたものの，実際に使いはじめないと問題も見えてこない気がしていますので。

[zr-tex8r]

• 仕様が「L の時点の現物のLaTeXカーネルを読み込んだ後に、P の時点の現物のpLaTeXカーネルを読み込んだもの」である
• かつ L ≦ P であることを前提とする

ということであれば、仕様として問題はないと思います。
ただし、“複雑な場合”に実装がちゃんとできるかが気になります。

• ①ある時点で、pLaTeXカーネルが「LaTeXカーネルコードへのパッチ」を追加した。
• ②上記と同じ状況で、かつその部分がlatexreleaseのブロックに含まれている。

例えばこれらの場合に対処できるでしょうか？

[zr-tex8r]

むむ、「複雑な場合」と書いたが、今の実装の中に含まれる唯一の \eminntershape はソレに該当するのか。だとすると、ソレが上手くいってるなら、問題ないのか。

↑違った。
\eminnershape は「後からパッチが増えた」ケースじゃないな。

[aminophen]

• ①ある時点で、pLaTeXカーネルが「LaTeXカーネルコードへのパッチ」を追加した。
• ②上記と同じ状況で、かつその部分がlatexreleaseのブロックに含まれている。

この場合はそもそも pLaTeX カーネルにパッチを新たに追加するときに platexrelease ブロックを作成するだけで，問題なしです。しかし，逆に

ある時点で，LaTeX カーネルが新たな latexrelease ブロックを追加した。たまたまそこが pLaTeX でパッチを入れている部分だった。

という状況（＝今の \em が実例）への対処がまだ不十分であることに気づきました（新しい LaTeX カーネルのコードが読まれないことには成功するが，0000/00/00 の古い LaTeX カーネルのコードは依然として読まれてしまうのでマズイ）。

[aminophen]

そもそも，platexrelease で L ≦ P を固定してしまうのが筋がよいのかどうか，再考しています。これを固定せずに「L の時点の現物の LaTeX カーネルを読み込んだ後に，P の時点の現物の pLaTeX カーネルを読み込んだもの」を仕様とするほうがメリットが大きいのではないか？ ということです。

「今後新たに追加される latexrelease ブロック」と「pLaTeX カーネルが既にパッチしていた部分」がバッティングした場合

• 新しい LaTeX カーネルのコードが読まれないように制御

は（いま実装しているとおりで）可能ですが．原理的にどうやっても

• 古い LaTeX カーネルのコードを読ませない

は不可能です（完全に対処するには pLaTeX kernel のコードをすべて platexrlease.sty に書き込まないといけない）。ということは，「とりあえず latexrelease を読ませて，L > P だとわかった場合には念のため警告を出す」ほうが，ほかの多くの部分の LaTeX カーネルの新しいコードが採用できて幸せだという考え方もできます。こちらに切り替えようかな…

[aminophen]

58420ec で L と P の大小によらないコード，すなわち「指定された時点の現物の LaTeX カーネルを読み込んだ後に，同じ時点の現物の pLaTeX カーネルを読み込んだもの」をなるべくエミュレートするようにしてみました。つまり，platexrelease したときに「pLaTeX より LaTeX が新しい状態」も許されます。これは，フォーマットが実際にそうなっているのとも合います。そのうえで，今度は「\latexreleaseversion が \p@known@latexreleaseversion（platexrelease が知っている latexrelease のバージョン）よりも新しい場合」に警告を出してみました。

[aminophen]

platexrelease のコードを master branch へマージしました。仕様は

• \RequirePackage[yyyy/mm/dd]{platexrelease} とすると「yyyy/mm/dd 時点の LaTeX kernel を読み込んだ後に、同じく yyyy/mm/dd 時点の pLaTeX kernel を読み込んだもの」をエミュレートする。 （最初の実装とは異なり、LaTeX より pLaTeX が新しい日付である前提とはしない。）
  • pLaTeX kernel 本体は「latexrelease が使われたのに platexrelease が使われていない」場合に警告を出す。
  • ここで仮に「読み込まれた latexrelease について pLaTeX が未知である」なら、platexrelease が万全ではないため警告を出す。
• オプション current と latest は、latexrelease の仕様を踏襲する。
  • current ならば「何もしない」、すなわち今ある \pfmtversion そのままの挙動。
  • latest ならば「latexrelease が知っている最新の LaTeX kernel を読み込んだ後に、platexrelease が知っている最新の pLaTeX kernel を読み込んだもの」をエミュレートする。

このあたりは、別途ドキュメントを作成しておきます。とりあえず \eminnershape に関する改変 (commit 3b92701) が典型例ですので、わかりやすいと思います。

[aminophen]

対応しようかと考えていながら手をつけていなかったのが、FAM256 patched な e-pTeX に対応した Extended allocation の件です。ここにソレらしい検討がみえるのですが、そのまま plcore.dtx に入れたら使えるんでしょうか？（この辺りは問題を把握できていないものでして…）

→ これは eptexdoc.pdf にあるように、qa:52744, qa:52767, qa:52799 あたりも参考にするのがよいでしょうか。

[aminophen]

• pLaTeX2e の LaTeX2e 2016/03/31 への追随
• pLaTeX2e kernel に platexrelease を導入（仕様は先述のとおり）

のふたつが完了しておりますので、close します。

e-pTeX 拡張への対応は platex repository で別途議論できれば幸いです。