Re: [Mlterm-dev-ja] --without-map-table

[Araki K. <ara...@us...>]

	荒木です:-)

	Subject: [Mlterm-dev-ja] --without-map-table
	From: Tomohiro KUBOTA <ku...@de...>
	Message-ID: <200...@tm...>
	Date: Mon, 10 Feb 2003 15:21:59 +0900 (JST)

> ところで、文字集合変換に自前でテーブルを持ってる理由って
> 何でしたっけ? (iconv とか libiconv を使わない理由?)
> もし自前でテーブルを持たなくても良くなれば、iconv を
> サポートするOSでは、機能を維持したままバイナリサイズを
> 劇的に小さくすることができるはずじゃないかな、と思って。
> (iconv をサポートしていなくても、libiconv を使う手もあるし)。
> これだけサイズが違えば、メモリの小さなマシンでの使い心地が
> だいぶ違ってくると思うのですが、Unicode 系との相互運用に
> 問題が生じるとなると、さすがに Debian パッケージで
> --without-map-table とかを指定するつもりになれないんです。

        iconv の中にも、Unicode の変換テーブルは含まれているわけですから、
        iconv を使おうが、mkf 使おうがメモリ消費量はそれほど変わらんと思い
        ます。そもそも、mlterm を動かせるようなまともな OS では、実行時に
        Unicode の変換テーブルにアクセスしなければ、基本的にメモリ上にロー
        ドされてくることはないかと...

        ただ、ディスク消費量がかなり変わってくるというのと、メモリ消費量に
        ついても、mlterm と同時に、iconv を使う他のアプリケーションを実行
        するなら、mlterm でも iconv 使ったほうが効率よさそう。

        それはともかく、自前で文字コード処理エンジン持ってる理由は、iconv
        を使いたくなかったから、というそれだけのことです。
        今から、iconv 使う場合、mkf の層で wrapping してやることになると思
        いますが、それもそれで面倒なんですよねぇ。まして、mlterm/xwindow
        の層で直接 iconv 使うとなると、もっと面倒。
        まぁ、結局のところ大した理由はないんですが。

	では
--
Araki Ken
ara...@us...