Acetaminophen’s diary

化学に関すること,TeXに関すること,ゆきだるまに関すること。

TeX ユーザの集い 2016 で講演しました

発表スライドをお求めの方はこちらをどうぞ ↓

TeX Live 2016 の新しい pLaTeX(山下 弘展)

PDF へのリンクは(GitHub page のディレクトリを整理するなどの関係上)今後変わる可能性もあります。今後も本記事からのリンクは維持しつづける予定ですので、上の PDF へのリンクではなく本ブログ記事にリンクしていただけると、到達できる可能性が高まります。

2年前に続いて「TeX ユーザの集い」でしゃべってきました。

TeX ユーザの集い 2016

日付:2016年11月5日(土)全日

会場:九州大学伊都キャンパス・センターゾーン センター2号館2106教室

主催:TeXユーザの集い2016実行委員会

今回は一般講演「TeX Live 2016 の新しい pLaTeX」という題で、(本ブログで何度も解説してはいますが)pLaTeX の最近の動向や今後の開発に関する話をしました。

pLaTeX は日本語組版デファクトスタンダードとなっている.しかし,幾つかの組版上の問題点や LaTeX の修正との不整合も指摘されていた.本講演では,TeX Live 2016 以降に収録されている,日本語 TeX 開発コミュニティによる新しい pLaTeX の現状を整理する.

発表スライドとアブストラクトは以下にあります:

今回は特別にソースコードも公開してあります。

発表の要点としては、前半が(本ブログで既に解説した)「コミュニティ版 pLaTeX」の変更点の解説、後半が今後の開発をどのように進めていくかという自分なりの考えを表明した、というところです。

f:id:acetaminophen:20161109004459p:plain

前半部分については以下の記事をまとめ直したものですので、本ブログの読者の方には目新しいものはそれほどないと思います(ただし、ゆきだるま☃要素がふんだんに出てきますので、☃ファンの方は特に必見です)。

そして大事な後半部分は、今後の開発方針についてですので、改めて以下に書きます。

 

pLaTeX の今後の開発方針:変化することによる安定性

基本的には、LaTeX の方針となるべく合わせる予定です。既に何度も説明しているとおり、LaTeX は 2015/01/01 以降、次々と大きな修正を導入してきました。従来は互換性を損なうという理由で控えられてきた変更も、すべてカーネルに直接インストールされるようになっています。さらには、pLaTeX を動かすエンジンである pTeX も、TeX Live に取り込まれた 2011 年以降は組版にかかわる修正も多くなされています。このような事情に即して、pLaTeX も「問題のある部分は修正する」という方針をとります。

一部では「pLaTeX カーネルの仕様は(たとえ問題があっても)互換性のため変えてはいけない」という意見もあるようです。しかし、LaTeX の仕様も pTeX の仕様も変化していく以上、完全な互換性を担保するのはムリなのが実際です。それどころか、仮に「LaTeX の仕様が変わっても pLaTeX は一切書き換えない」という方針をとった場合、「LaTeX の変化によって pLaTeX で不都合が起きる」「LaTeX はバグ修正されたのに pLaTeX はいつまでもバグが残る」といった危険性が、どんどん高まってしまうのです。

こうした危険のないように、pLaTeXLaTeXpTeX の変更に常に追随させること、いわば「変化することによる安定性」を追求しようと考えています。pLaTeXpTeX/e-pTeXLaTeX あってこそのもので、出力は「その時点の (e-)pTeXLaTeX の上に構築された pLaTeX」という状態から得られることを忘れてはいけません。

 

古い jarticle, tarticle などの変更方針

では、jarticle や tarticle のような文書クラスはどうなのでしょうか。私はこれらも pLaTeX と同じことがいえると考えています。一部では「jarticle や tarticle の仕様は凍結すべき」という意見があるようですが、LaTeXpLaTeX や (e-)pTeX が変われば jarticle の挙動はおのずと変わってしまうものです。現時点ではコミュニティとして jarticle などの古いクラスに一切手をつけていませんが、今後は修正を加える可能性も十分にあります。

もちろん、「jarticle は min10 メトリックのようなちょっと変な仕様」「jsarticle は jis メトリックに従った綺麗な仕様」という “評判” が既に定着しているようですが(私個人としては、この違いは jarticle の作者が意図した “仕様” というわけではないと考えています;単に「未完成品」なだけだと思うので…)、これはもう “評判” が定着してしまっている以上、特に変えないつもりでいます。しかし、他の細かい部分については pLaTeX の変更や、もっと大事な LaTeX 本家の article などの修正にあわせて追随する必要があると考えています。

 

変更にあたって:十分なテストと変更タイミングの見計らい

現在 pLaTeX に残されている不都合な点は

  • pTeX エンジンの挙動に深く絡んでいる
  • 修正するとほかの予期しない影響が出かねない

などの理由で、修正の難しいものが多くなっています。こうしたなかでも、やはり可能な限り不都合な点は改善していきたいわけです。このためには、やはり十分なテストが必要です。ところが、開発のマンパワーは割と不足していて、その少数のテストだけでは潜在的なバグを露呈させるには不十分という状態が続いています。やはり TeX ソースの書き方には個々人のパターンがあるのが普通ですので、コードを改修する人と同じ人がテストしてもほとんどバグ発見には至らないわけです。

そこで準備してあるのが、みなさんのお手元の TeX Live にも(Windows の方は W32TeX にも)届いている「exppl2e パッケージ」です。あなたが今書いている論文の .tex ファイルの冒頭(一行目)に

\RequirePackage{exppl2e}

と書くだけで、将来リリースされる予定の新しい pLaTeX と(ほぼ)同じものを試すことができるというわけです。簡単ですね! もちろん出版する本の最終印刷などには(もしかしたらバグが潜んでいるかもしれませんので)お勧めしませんが、それ以外のときであれば大した手間にはならないはずです。ぜひどんどんテストしてください。

そして、めでたく「問題なさそうだ」と判断された場合は、パッチが正式に pLaTeX に反映されます。このタイミングをどのように見計らうかは、状況にもよるため一概には言えませんが、大まかに私が考えているのは以下のとおりです:

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

1. と 2. については割とわかりやすい基準だと思いますが、私は 3. と 4. を特に重視しています。これは TeX Live の開発周期と重なります。

TeX Live の開発は、TeX Live 2015 や TeX Live 2016 と名のつくとおり一年周期です。TeX Live 2016 を例にすると

  • 2016 年 4 月頭 : TeX Live 2015 frozen
    一般向けのパッケージの更新停止
  • 2016 年 4 月 -- 5 月 : TeX Live 2016 pretest
    開発者がバイナリのプログラムを新しくなったソースからビルド
    有志が新しいバイナリとパッケージをテスト
  • 2016 年 6 月 : TeX Live 2016 正式リリース
    一般向けに新しいバイナリ配布(むこう 1 年間は critical なバグ以外直さない*1
    一般向けに新しいパッケージが 2 ヶ月ぶりに届く
  • 2017 年 4 月頭 : TeX Live 2016 frozen
    一般向けのパッケージの更新停止

例年、このような周期になっています。4 月から 6 月にかけての 2 ヶ月間は、プレテスト期間にあたるため「テストしてくれる有志以外には新しいパッケージが提供されない」状態になります。これは私たちの pLaTeX マクロパッケージについてもあてはまり、pLaTeX にバグが見つかって修正しても、みなさんの手元に届かないということになり、最大で 2 ヶ月間、バグ入りの pLaTeX を使い続ける必要が生じてしまいます。

たとえば 3 月に修正を加えてバグが 4 月に発覚するということは十分考えられるため、このようなギリギリのタイミングでの pLaTeX の変更はしないと宣言します(ちょうど 1 月から 3 月といえば卒論などで学生 pLaTeX ユーザにとって繁忙期ですから、この期間の安定性が保証されてちょうどよいのではないかと思います)。逆に、年度の前半はプレテスト期間にあたるため、「テストに積極的な有志に新しい pLaTeX を試してもらう」という目的で積極的に pLaTeX に変更を加えます。たとえ正式リリース後にバグが判明しても、年度の前半であればすぐに fix を提供することができますから、入ってしまったバグによる悪影響を最小化することができます。

このように、新しい pLaTeX では「バグを入れない」ことよりも「入りうるバグの影響を未然に最小化する」ことを重視しようと考えています。もしどうしようもない場合は「platexrelease パッケージ(本記事では次項に登場)を使えば対症療法的にバグを回避できる」という二重の策を講じているわけですから、それほど致命的に困ることはないはずです。

 

どうしても互換性が気になる方へ

LaTeX後方互換性のために latexrelease パッケージを用意しているのと同じように、pLaTeX でも platexrelease パッケージを用意しています。ですから、後方互換性がどうしても気になる場合は \RequirePackage[2015/10/01]{platexrelease} のように過去の日付をエミュレートすることが可能です。

ただし、この platexrelease パッケージもやはり万全ではないことに注意が必要です。というのも、platexrelease パッケージは「マクロレベルでのエミュレート」はできますが、それを動作させる当のエンジン (pTeX, e-pTeX) はあくまで新仕様だからです。

pLaTeX の方針は

「旧エンジン+旧マクロ」の問題ありな挙動を「新エンジン+新マクロ」で改善する

というものですから、昔の(問題ありな挙動を)エミュレートしようとしても「新エンジン+旧マクロ」の組み合わせでは、うまくエミュレートできるという保証はありません。昔の挙動が欲しい場合の万全な方法は、やはり「古い環境でコンパイルすること」に尽きるのです。

それでも platexrelease パッケージを提供する意味はもうひとつあり、それは前項で触れたとおり「入りうるバグへの未然の対症療法」としての役割です。platexrelease パッケージは過去の挙動をエミュレートするわけですから、新版の pLaTeX にもしバグが入ってしまった場合にそれを回避する手段としても役に立ちます。

 

終わりに

2014 年までの LaTeX は「fixltx2e パッケージを読み込んでバグを直す」という方針だったことから比べると、2015 年以降は “困ったデフォルト” がいくつも改善しました。pLaTeX もこの流れに乗るべく、今後も改良が施されることになるでしょう。デフォルトがずっと改善せずに、それを小手先で直すバッドノウハウがあちこちで蓄積するよりは、長期的に見てずっと好ましい方向に進んでいくと思います。いかがでしょうか?

 

補遺

雑多なことを書きます。

  • 「今の時代、LuaTeX-ja でしょ!」な方へ:実は、LuaTeX-ja は pTeXpLaTeX に相当する機能を Lua スクリプトTeX マクロで実装していますが、pTeXpLaTeX のマクロを元に作られたためにpLaTeX に存在する不都合がそのまま LuaTeX-ja にも残っている」という状況がいくつか存在しています(すでに開発元には報告済み)。もちろん、LuaTeX-ja の開発者が pLaTeX の不都合に気づいて直してしまった部分も多々ありますが、まだそれでも日本語組版のうえで pLaTeX 同様に LuaTeX-ja も完全にはなっていません。日本語組版の難しさを考えるうえでも、pLaTeX という歴史的資産を振り返れば、LuaTeX-ja の今後の可能性を考える糧になると思います。
  • 公開したソースについて:ソースは全体を通して jsarticle の slide オプションで組みました。スライドの overlay を実現するためにマクロを組むところから始まり、変態なコードを書いてしまいました(^^;) 興味のある方はいろいろ突っ込んでください。
  • ゆきだるま☃について:同時開催されていたと思われる、「ナントカconf16」に遠隔参加することができました、ということにしてください(えっ)

最後に:TeX ユーザの集い 2016 実行委員会のみなさま、講演者のみなさま、参加者のみなさま、楽しい時間をありがとうございました。

*1:たとえば 2016 年 9 月についに LuaTeX 1.0 がリリースされましたが、TeX Live 2016 の間はずっと LuaTeX 0.95 のままです。