autodetect-engine の規定化と platex オプションの追加

[wtsnjp]

表題の通り，4年あまり前に実装 (#39, #40) された autodetect-engine を規定のオプションとすることと，新しく platex オプションを追加することを提案します．

現状すでに autodetect-engine またはそれに類する機能が各種文書クラスで実装されていることからもわかるように，エンジンの自動判定には長年の実績があり，デフォルトとしてその自動判定に依拠することも，技術的には問題のないところだろうと思います．

ひとつ autodetect-engine をデフォルトとしないことに（実利的な）メリットがあるとしたら，使用する「ワークフロー」の明示をユーザに要求できることですが，jsclasses に関しては（歴史的な事情と理解していますが）platex は明示できない一方で，uplatex については明示を要求するという状況になっており，強くワークフローの明示をベストプラクティスとして提示する意図があるものとは見受けられません．

そこで，現状の autodetect-engine の挙動を規定とし，一方でワークフローの明示を好むユーザ・状況に対しては uplatex に加えて platex オプションを用意して明示できるようにするのはどうでしょうか．この場合に想定している挙動は次のようなものです．

• 無指定（デフォルト）：現状の autodetect-engine 指定と同じ
• platex 指定：実際に pLaTeX で処理されていれば何もしない．upLaTeX の場合はエラー
• uplatex 指定：現状の autodetect-engine + uplatex 指定と同じ

この挙動は，後発の jlreq クラスの仕様に近いものです（もちろん jlreq では LuaTeX もサポートされている点は大きな違いですが）．

明確なメリットとして，現状 upLaTeX で uplatex を指定しないと問答無用でエラーになるという，ユーザにとっては（少なくとも目先では）ありがたくない挙動を改善することができます．

また細かいことですが「ワークフローを常にクラスオプションを明示する」という方針を採ったときに，platex を指定しても未使用オプションの警告が出ないようになるという効果も期待しています．クラス側の「敢えてエンジンを明示させる」というポリシーに関しては，近年はビルドツール向けの設定などでクラスオプションとは別に明示する機会が増えてきていることも考慮していいのではないかと思っています．

なお特筆すべき点として，この変更は後方互換性を壊しません．これまで正当な使い方としてあり得た「pLaTeX でオプションなし」および「upLaTeX で uplatex オプション明示」のケースは，いずれも仮に本提案を実現したとしても問題なく動作し続けます．

[t-tk]

jsclasses の Issues はあまり見ていなかったので久々の意見表明です。1年以上の放置になってしまい済みません。
当初 uplatex オプションを入れたのは私でして、当時は upLaTeX がよちよち歩きの頃で、不測の事故防止のために必要だったと思います。
もう時代が違うので autodetect-engine を規定に、upLaTeX 処理を明示の時は uplatex オプション、pLaTeX処理を明示の時は platex オプションにして良いと思います。
japanese-otf もそうしましょうかね。

[t-tk]

pull-requestをマージして CTAN投稿完了しました。ここは閉じます。
念のため仕様を再掲。

• autodetect-engine, platex, uplatex のオプションのうち一つが指定できる。重複指定した場合は最後が有効。
• 無指定(default)の場合は autodetect-engine を指定したのと同じ。
• 無指定(default)またはautodetect-engine 指定時は、platex, uplatex の自動判定をして処理を進める。
• platex 指定時かつ uplatex 使用時は、警告を出して止まる。
• uplatex 指定時かつ platex 使用時は、警告を出して止まる。
• platex 指定時かつ platex 使用時は、そのまま処理を進める。
• uplatex 指定時かつ uplatex 使用時は、そのまま処理を進める。

[t-tk]

エラーメッセージを少し変えて CTAN 投稿します。
エンジンがuplatexのとき、エラーに差し掛かるのは platex と書いてある場合なので。