gnu-devels-jp
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I can't convert Texinfo-4.2's Texinfo source files to Info with Emac


From: Yoshinori K. Okuji
Subject: Re: I can't convert Texinfo-4.2's Texinfo source files to Info with Emacs.
Date: Mon, 27 May 2002 02:41:40 +0900
User-agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryōmae) APEL/10.3 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI)

At Mon, 27 May 2002 01:13:42 +0900 (JST),
Koji Arai wrote:
> おそらくご存知であろうし、望んでいるものとは違うのでしょうが、
> 以下に国際化ならぬ L10N な makeinfo があります。久しぶりに見
> て texinfo-4.2 にもついていってるようなので驚きました。日本
> 語化 texinfo.tex などもここで長い事メンテナンスされているよ
> うですね。
> 
>   http://www.fsci.fuk.kindai.ac.jp/~kakuto/soft.html

そうですね。GNUjdocでだけ使えればいいなら、これで十分ですね。いっその
こと、こいつをGNUjdocにバンドルしちゃえば済むわけですが、きっとRMSは気
に入らないでしょうねえ。

> 以下は試したことないですが、wchar_t 化ということで対応の仕方
> がよりまっとうかもしれません。
> 
>   http://www02.u-page.so-net.ne.jp/xa2/fukusaka/linux/

こっちの中身は見たことがないんですが、考えようによっては、日本語パッチ
より悪いと思います。というのも、カラム幅を計算するのに必要なwcwidthが
POSIXじゃないからです。これはUNIX98には入ってますが、すべての環境で利
用できると言うことはできません。

address@hidden@includeした
address@hidden
指定されているとき、ちゃんと振る舞うことが期待されているのか。
@documentencodingは一度しか指定できない、あるいは、同じエンコーディン
グでないと許されない、のようなルールがあれば気にしなくて済みますが、今
のところそういう取り決めはないように見えます。その場合、wchar_tはロカー
ル依存なので、とても使い物にはならないでしょう。

あと、LC_CTYPEをプログラム中で勝手に変更すると、gettextに影響するので
マズいのでは?もちろん上記のプログラムのように、ユーザが使っている
LC_CTYPEが、Texinfoで書かれたマニュアルのエンコーディングと一致しなけれ
ばならない、というのはめちゃくちゃな仮定です。

だから、Texinfoがnon-ASCIIに(まともに)対応したいなら、libcに頼らず、自
前で文字コード絡みのライブラリを用意しなければいかんと思うのです。

# 以前 Ulrich Drepper が提案していたような、ロカールオブジェクトを個別
# に指定できる関数群がlibcに実装されるのが常識となればいいんですが。

おくじ



reply via email to

[Prev in Thread] Current Thread [Next in Thread]