From: Martin Duerst <duerst@...>
Date: 2007-12-24T14:11:22+09:00
Subject: [ruby-dev:32697] Re: ISO-2022-JP output for transcode

成瀬さん、中田さん、こんにちは。

最後まで色々提案をしていただいてどうもありがとうございます。

At 13:04 07/12/24, Nobuyoshi Nakada wrote:
>なかだです。
>n
>At Mon, 24 Dec 2007 10:10:28 +0900,
>NARUSE, Yui wrote in [ruby-dev:32695]:
>> transcode を ISO-2022-JP の出力に対応させるパッチを書いてみました。同様
>> に preprocessor で入力にも対応できますし、ISO-2022-JP 以外の ISO/IEC
>> 2022 シリーズにも対応できるようになっています。
>
>できれば、transcode_data_japanese.cのほうにお願いしたいです。

これは自動的に作成しているので、余り好ましくないです。でも
(下のようにたいてありますように) 未だ変更する予定なので、
こちらでもいいです。

>> Martinさんの考えている方向とは違っているかもしれませんが、

確かにそうですね。

>>とりあえずクリ
>> スマスリリースに入れる程度の品質は出ると思いますがいかがでしょう。

リリースにいれていいですが、明日とか明後日当たりで HEAD でまだ取り出し、
違う方針でよかったらいいですよ。

>ギリギリですが、間に合えばこういう風にしたいと思っています。
>
>* transcode_data_*.cをenc/trans/に移動させる。先ほどenc/trans/の
>  下もenc.mkで処理できるようにしました。

この移動はこれでいいです。以前にもそういう方向で話しましたよね。

>  # transcode_data_one_byte.cという名前はわかりにくいので、
>  # japanese.cと同じ伝でいえばeuropean.cかなぁと思ったりしますが。

こちらでもそう思いましたが、iso-8859-6 はアラビア語で、iso-8859-8
はヘブライ語で、iso-8859-11 はタイ語で、どちらともヨーロッパと
縁が薄いです。しばらくそのままいいではないでしょうか。

>* MAX_TRANSCODERSの制限をなくす
>  # というか、このパッチだとオーバーしてませんか?

外してもいいですが、余り大きな変更はしない方がいいと思います。

>* transcode_data_*.cを拡張ライブラリ形式にする。
>  必要な構造体とプロトタイプをヘッダに入れて、各transcoderでは
>  Init関数を追加することになります。

こちらでは次のように考えました:
- transcoder の登録を transcode.c に残す。
- 登録の際、ファイル名も登録する。
  (例:
       register_transcoder("ISO-8859-1",  "UTF-8", &rb_from_ISO_8859_1, 2, 0);
   の変わり
       register_transcoder("ISO-8859-1",  "UTF-8", &rb_from_ISO_8859_1, 2, 0, "transcode_data_one_byte");
- transcoder が呼ばれたら、データのファイルをロードする。

Ruby の動的ロードをまだ余り分かりませんので、この方向でうまくいくかどうか
分かりませんが。でもこれだとファイルを増やさなくてよいという特長があります。
第三者が文字コード変換を追加したいときには何かのところから同じくregister
すればいいですが、これは後で考えていいです。


>  # ちょっとMartin先生の方針がわからないので、これは間に合わない
>  # かも。

方針は上記の通りです。中田さんのスピードだったら間に合う可能性が
あるかもしれません。

宜しくお願いします。     Martin.


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp