kubotaの日記： groff 日本語パッチ

佐野さん情報。日本語パッチをあてた groff が、ps、dvi、html などのデバイスに対して EUC 判別を有効にしてしまっているものだから、1 バイト文字言語な人が困ってしまうというもの。

というか、groff って、最初の設計からしておかしいんだよね。ps、dvi、html などの「デバイス」になぜ ascii、latin1 などが並列で来るんだ？要するに、最初の設計では、latin1 な世界の外のことは考えていなかったわけだ。設計の段階からおかしいものを、それを無理やり日本語化あるいは国際化しようとしても、どこかにひずみが出てしまう。

といっても広く普及してるし、なんとかごまかしつつ使わないといけない。というわけで、新デバイス tty を導入して ascii、latin1、(そして nippon、Debian 拡張の ascii8) を廃止し、エンコーディング用に別オプションをつけるのが正しい姿。テキスト処理プログラムだからデフォルトでは LC_CTYPE に従わないといけないが、でも groff は man pages のフォーマッティングに広く使われていて、man pages のソースは LC_CTYPE によって変化しない固定的なものだから、ソース自身がエンコーディングを指定できるメカニズム (emacs の -*- coding: hogehoge; -*- みたいなの) も必要。それから入力と出力でエンコーディングが違うかもしれない。

という議論が、このあたりから始まっていたのだが、だいぶ昔のことだけどぜんぜん放置したままだ。。。

長い議論なので、まとめておくと、

• tty デバイスを導入、ascii、ascii8、latin1、nippon デバイスを廃止。
• troff コアは、UTF-8 化する。
• groff に、入力エンコーディングを指定するオプションおよび出力エンコーディングを指定するオプションを追加する。
• 入力エンコーディングは、次のようにして定まる。
  • コマンドオプションの指定があれば、最も優先される。
  • roff ソース自身の指定が、次に考慮される。
  • どちらもなければ、LC_CTYPE ロケールで決められる。
  • それもなければ、Latin-1。
• tty の出力エンコーディングは、次のようにして定まる。
  • コマンドオプションの指定があれば、最も優先される。
  • LC_CTYPE ロケールが次に考慮される。
  • どちらもなければ、Latin-1。
• 入出力エンコーディングと UTF-8 との変換は、専用のプリプロセッサおよびポストプロセッサが受け持つ。
• 言語ごとのタイプセット規則は、別途考える。
• どの範囲の UTF-8 文字が最終的に出力に使えるか、は、ポストプロセッサしか知らない情報であるが、troff コアにとっても必要な情報である。これはマクロで提供される（らしい）。

といった感じです。わたくしはプリプロセッサ/ポストプロセッサを作るって言ったんですけど、はやく作らなきゃ。

ところでわたくしは troff コアについてはほとんど理解していないので、協力したい方は大歓迎です。Groff メーリングリストまで。

ところで、最初に書いた問題はとりあえず、EUC 判別は nippon デバイスの場合しか行わないことにするという ad-hoc な解決法を考えています。日本語サポートという点では後退になるけど、まあこの際、上記の大改造を待っているわけにもいかないし。