[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-devel:14397] Re: groff Japanese support breaks PS output for latin2
groff 1.17.2 base でいろいろいじってみました。
http://people.debian.org/~ukai/groff/
今 1.17.2-1.ukai.1 が最新です。
jgroff patch から euc べったりなコーディングをできるだけ
分離するようにしたつもりです。
日本語manualは化けずに見ることができてます。
% LANG=ja_JP.eucJP; export LANG
% zcat /usr/share/man/ja/man8/dselect.8.gz |
groff -mandoc -Tps > /tmp/dselect.ps
% gv /tmp/dselect.ps
で 日本語ps もだいたいできてるみたいです。
At Fri, 13 Jul 2001 23:32:59 +0900,
Tomohiro KUBOTA wrote:
> 私は、個人的には、国際化への展望が持てない日本語パッチは
> upstream 送りにするべきじゃないし、送っても受け入れてもらえ
> なくて当然だと思っています。たとえば、新たにアラビア語サポートを
> 書こうと思ったけど日本語パッチのせいでとても面倒なことになって
> いる、というような状況を生むようなことがあってはまずいです。
> 鵜飼さんの書かれた、
>
> > あと hard coding されている禁則処理まわりも .cflags を nippon.tmac に
> > いれるくらいは やっておきたいところですね。
>
> ということも、このへんに関連するんじゃないかな、と私は解釈
> しています。
これは簡単にできました。結局 euc-jp.tmac を作ってそこで
.cflags 256 ,:;>}
.cflags 256 、。，．・：；？！）〕］｝」』】ぁぃぅぇぉっゃゅょー
.cflags 256 ァィゥェォッャュョ
.cflags 512 （〔［｛「『【
.hc -
みたいにすることでいけてるようです。
それから、
> > 例えば
> > .x-encoding EUC-JP
> > すると 以後 EUC-JPで扱うようになるとか。
は、roff的システムでは駄目なことがわかりました。
# 少なくとも今の groff の実装ではかなり無理がある
roffでは、入力ファイルは以下のようなパイプラインで
ながれていくことになっています。
groff
入力 -[A]-> preproc (eqn, tbl など)
-[B]-> troff
-[C]-> gro<device> (grottyなど)
-[D]-> stdout / $PAGER
で、.encoding というrequestなどを新設しても これが有効なのは
troff だけです。
1) preproc群で有効にするには一筋縄ではいきそうにありません。
2) gro<device> へ渡るときには、roff request などは既に処理されており
.encoding を見て判断ということはできません
まず、2)の方はおそらくそんなに無理はなくて、たぶん
x encoding <encoding名>
とかいうシーケンスを渡すようにすれば なんとかなるような気がしています。
ただ、問題は 1) の方で、これはこの方法ではうまくいきません。
# まぁ無理矢理見るようにすればなんとかなるのかもしれませんが。
それから troff にしても .encoding というリクエストを実行するタイミングと
入力するファイルをtokenizeするタイミングの問題があるので、やはり
roff文書に encodingを request の形式で書くのはよさそうではありませんね。
今は上記の各プロセスで
init_encoding_handler();
つまり
setlocale(LC_ALL, "");
new_encoding_handler(nl_langinfo(CODESET));
するという安直な方法で逃げてます。
# よって LANG=ja_JP.eucJP だと EUC-JP mode で動く
コマンドライン引数に対応するのもそんなには難しくありませんが
どうするのがベストなのかは いまいち確信がありません。
ちなみに、上記のコードから想像がつくかもしれませんが、encoding_handler
を切りかえる方法にしたので、ascii8なencoding(ISO-8859-1?)と
EUC-JP以外にも対応するのは、そんなに難しくはないだろうと思っています。
ただオプション文字のあまりがもうほとんどないので long option で
対応するしかないかも… (--encoding EUC-JP とか)
もっとちゃんとやるのなら
* どのタイミングで誰が encoding を判断/決定するのか?
* 上のパイプラインの [A]/[B]/[C]/[D] それぞれで使われるエンコーディングは
なんなのか
あたりをはっきりと決めないといけませんね。
なお、xditview の対応はまだです。
> にしても、形式的にはどんなエンコーディングにも対応できるけれども
> 今のところ ISO-8859-1 と EUC-JP しか実装されていない、という形に
> なっていて、国際化への展望が見えますよね。
今回の refactoring で src/libs/libgroff/encoding.cc をいじれば
以前のパッチよりは他のエンコーディングにも対応しやすいように
なっていると思います。
--
鵜飼文敏