mendexのデフォルト文字コードのUTF-8化

[t-tk]

Windowsでp(La)TeX等の入出力のデフォルト文字コードがUTF-8になったのに刺激を受け
mendex のデフォルト文字コードを変更しようかと考えています。
mendexのUTF-8対応の状況は、フォーラムの2014年頃の議論
MakeIndex, Mendex, XindyとMendexのUnicode化の通りです。

mendexの場合、インデックスは「表記」「読み」で管理されています。
読みは常にEUC-JPで扱われます。
表記はアスキー社のオリジナル版はEUC-JP限定でした。2014年の拡張でUTF-8に切り替えられるようになり、表記にJIS第1,2水準の縛りが無くなりました。
mendexの内部コードとは、表記の文字コードを指します。
入出力の文字コードは ptexenc により、Shift_JIS, EUC-JP, JIS(ISO-2022-JP), UTF-8が利用可能になっています。

TeX Live 2018の現状は、ソースを眺めた限り、以下のようになっているようです。
Windows:

• デフォルト: 入出力:SJIS, 内部:EUC
• 環境変数PTEX_KANJI_ENC指定あり: 入出力コードを変更
• -U オプション: 入出力:UTF-8, 内部:UTF-8 両方変更
• -E, -J, -S オプション: 入出力コードを変更
• -I euc, -I utf8: 内部コードを変更

Unix系:

• デフォルト: 入出力:UTF-8, 内部:EUC
• 環境変数PTEX_KANJI_ENC指定あり: 入出力コードを変更
• -U オプション: 入出力:UTF-8, 内部:UTF-8 両方変更
• -E, -J, -S オプション: 入出力コードを変更
• -I euc, -I utf8: 内部コードを変更

それを以下のように変更しようと考えています。
Windows, Unix系共通:

• デフォルト: 入出力:UTF-8, 内部:UTF-8
• 環境変数PTEX_KANJI_ENC指定あり: 入出力コードを変更
• -E, -J, -S, -U オプション: 入出力コードを変更
• -I euc, -I utf8: 内部コードを変更

デフォルトの内部コードの変更に伴い、同音異義語の順番が入れ替わる場合が発生するなど、僅かな影響は予想されます。
アスキー社さんのオリジナルのmendexの動作を変更することになりますが、許容されると考えています。

• 仕様書に書かれることが無いほど軽微な挙動の違いにすぎないこと
• 従来の動作が好ましい場合-I euc を利用すれば従来通り動作すること
• 大多数のユーザーにはメリットの方が大きいこと
• 文字コードの仕様としては明快になること
• 内部コードUTF-8の動作は、導入後時間が経ち安定していること

ご意見があればお願いします。

[aminophen]

Windowsでp(La)TeX等の入出力のデフォルト文字コードがUTF-8になった

ことから考えると，「Windows のデフォルト入出力を Shift-JIS から UTF-8 に変える」だけでも十分な気もします。ざっと思いつくことを書いてみます。

• デフォルトの内部コードを UTF-8 にする場合，
  • それによって実際の書籍の索引はどのくらい変わるのか？
  • upmendex の優位性は「ICU が使える」だけ？
  • バージョン番号を v2.6f → 日付に変更して区別すべき

[t-tk]

「Windows のデフォルト入出力を Shift-JIS から UTF-8 に変える」だけでも十分

今回の変更で「森鷗外」のようなJIS第1,2水準でカバー出来ない例がデフォルトで使えるようになります。入出力コードの変更だけでは、それは実現できません。

• それによって実際の書籍の索引はどのくらい変わるのか？

五十音順で決定できる項目の順序は全く変わりません。
実際の書籍ではほとんどがそれに相当すると思います。
もしも問題になる場合には-I eucで元通りの動作になります。

• upmendex の優位性は「ICU が使える」だけ？

mendex は「英語+日本語」のみ。
upmendex は多言語(ラテン文字圏ほぼ全部、CJK全部、ギリシャ文字、キリル文字)
「だけ」と簡単に言うほど小さい差では無いような。

• バージョン番号を v2.6f → 日付に変更して区別すべき

これは同意します。
ただしmendexはこれ以上更新することも想定しづらく、バージョン番号 v3.0 位にしようかと思います。

[t-tk]

• それによって実際の書籍の索引はどのくらい変わるのか？

手元の「改訂第7版 LeTeX2ε 美文書作成入門」の索引を眺めてみたら、
今回の非互換が影響を及ぼす可能性のある項目(同音異義語の項目)はゼロでした。

[aminophen]

今回の変更で「森鷗外」のようなJIS第1,2水準でカバー出来ない例がデフォルトで使えるようになります。入出力コードの変更だけでは、それは実現できません。

これは，「pTeX の内部コードは将来もずっと UTF-8 にはしない」という命題と同じだと思っています。pTeX が内部 UTF-8 化する時が仮に来ないのであれば，mendex だけ内部 UTF-8 デフォルトになってもあまり問題解決にはならない気がする点を気にしています。

それによって実際の書籍の索引はどのくらい変わるのか？

upmendex の優位性は「ICU が使える」だけ？

この二件については少し理解しました。

[aminophen]

誤解のないように書いておくと，私としては特に「mendex のデフォルト内部 UTF-8 化」に反対はしませんが，積極的賛成するほどの理由は持っていないところです。

[t-tk]

mendex だけ内部 UTF-8 デフォルトになってもあまり問題解決にはならない

うーん。今ひとつピンとこないです。pLaTeXの範囲でも有意義なケースは考えられます。
例えば、otfパッケージのotf-hangul.dfuのようなものと組み合わると、こんなこともできます。
(もちろん、upmendexやupLaTeXでも出来ますが)

\documentclass[autodetect-engine]{jsarticle}
\usepackage[multi]{otf}
\input{otf-hangul.dfu}
\usepackage{makeidx}
\makeindex
\begin{document}
서울\index{ソウル@서울}
\printindex
\end{document}

以下、雑談モードです。
その一方、「いつまであるいはどこまでpTeX系のメンテナンスを今後やるべきなのか?」という疑問は持っています。
そもそも upTeX系の開発動機が「pTeX系で出来ることを全てUnicode(UTF-8)で出来るようにする」というものでした。
それがほぼ全て実現した現在、pTeX系の「レガシーエンコーディングであるがゆえの苦労している部分」や「シガラミを抱えているがゆえの苦労している部分」を補うための開発って価値があるのかと。
その例がpTeXの日本語ファイル名 #45 とか、pTeXの標準フォント texjporg/platex#73 とかですね。

[aminophen]

なるほど，pLaTeX でも確かにそういう例は書けますね。

---

いつまであるいはどこまでpTeX系のメンテナンスを今後やるべきなのか?

以下の二件の事実があります。

• 最新アンケートによると，日本語ユーザの 6 割がまだ pLaTeX を使っている。
• okumacro.dtx: Add more macros for zenkaku-dash jsclasses#47 (文字コードが縮退しているかどうか)や [okumacro] 圏点のずれ jsclasses#60 (comment) (\kcatcode の範囲の違いで，control word に使える文字が違う)のように，どうしても「pLaTeX では通るけど upLaTeX では通らない例」が出てしまう。

一件目から，「pLaTeX 自体をなくす」「pLaTeX を unsupported / obsolete にする」はまだまだ先のような気がします。さらに，二件目から「platex を uplatex のシンボリックリンクにする」もどこに影響が出るかわからないので，調べた方が良いでしょう。pTeX 系をずっとサポートするのは手間ですが，現状見捨てることはできないので苦しんでいます。どちらかというと， #32 を決着させる方が先でしょうね…。

さらに私個人の意見ですが，

「pLaTeX の挙動を凍結し，何も改善・変更しない。ただ，LaTeX や babel など upstream の変更が pLaTeX を致命的に壊す可能性は残るので，upstream を監視しつづけて，壊れた時だけ pLaTeX を直す」

というメンテナンスは面白味がなくツマラナイと思っています。労力の心配よりも，「どうせメンテナンスするなら，改善あり・変更ありで底上げしていく」という方が，私はモチベーションが上がります。

[t-tk]

• 最新アンケート

これは初めて知りました。私の予想よりupLaTeXが善戦しています!!
ただ、twitterを使わない人はもう少し保守的な方に傾いているように思います。

どうしても「pLaTeX では通るけど upLaTeX では通らない例」が出てしまう。

それが、p(La)TeX→up(La)TeX を両方サポートする場合の実装コストだったりp(La)TeX→up(La)TeXの移行コストになるのは分かります。
しかし、完全に解決の手段が無い訳ではなく、移行時期には仕方ないかと思います。(移行するという史観が入っていますが…)
例えば、perl4とperl5の差、ruby1.8とruby1.9の差、python2とpython3の差と比べたらずっと小さい差異に思えます。(convbkmk.rb はruby1.8とruby1.9以降の両方動くようにするため苦労しました。)
その非互換が障害ではないと思います。
それより、実績とか安心感とか参考書の充実とか、そういうところが大きいのではないかと思います。

「pLaTeX 自体をなくす」「pLaTeX を unsupported / obsolete にする」

私もそこまでは想定できて/していません。
実際、p(La)TeXとup(La)TeXの開発・メンテナンスのコストは、私の想像では、ざっくり

• p(La)TeXとup(La)TeXの共通部分
  • ただし、差分はあるのでテストは二度手間
• p(La)TeXの固有部分
• up(La)TeXの固有部分

と分けると「共通部分」が莫大で、「固有部分」は小さいのではないかと思います。(いつも有り難うございます)
p(La)TeXのサポートを凍結したとしてもup(La)TeXをサポートしようとするとメンテナンスコストはあまり小さくならないような気がします。
そこで「テストは二度手間」が重荷で耐え切れなくなったら方針を考えないといけないことになるかもしれません。
しかし、pTeXの日本語ファイル名 #45 みたいな項目は、純粋にpTeXの固有部分だし複雑で大変な割にupTeXで解決済みなことだし、頑張り甲斐がないという思いがよぎります。
私が後ろ向きな考えになっているのは、そのような開発項目です。

「どうせメンテナンスするなら，改善あり・変更ありで底上げしていく」という方が，私はモチベーションが上がります。

モチベーションは本当に大事だと思います。
フリーソフトで経済的な報酬なしなので、「やり甲斐」が無いと続けられません。

ところで、

• バージョン番号を v2.6f → 日付に変更して区別すべき

現状は "version 2.6f [14-Aug-2009]" と日付入りでした。
それに倣って"version 3.0 [??-May-2018]" にしようと思います。

[abenori]

例えば、perl4とperl5の差、ruby1.8とruby1.9の差、python2とpython3の差と比べたらずっと小さい差異に思えます。

LaTeXの利用者のコンピュータスキルのレベルはPerlやRuby，Pythonなどよりも平均的に低いと思うので，こういう比較は危険な気がします．とはいえ，差が非常に小さいという事実は正しいと思うので，

その非互換が障害ではないと思います。

は同感ですが．

[t-tk]

TeX Live svn にコミットしました。 r47721, r47722

[t-tk]

皆様、コメント、ご協力ありがとうございました。
あと、ドキュメントの更新が残っていますが
issueは「mendex v3.0 向け pdf の更新」texjporg/mendex-doc#7 に移してここは閉じます。