[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]

[OSASK 2870] Re: Fullset EUC

  こんにちは、川合です。


I.Tak. さんは 2002/01/03 01:23:12 の「[OSASK 2869] Re: Fullset E
UC」で書きました：

>>  僕の認識では、EUCというのは確かに「GLにG0、GRにG1を呼び出して
>>おき、シングルシフトでGRにG2かG3を一文字だけ呼び出すという仕様」
>>なんですが、一般的にはG0は94文字集合であるという保証はありません
>>し、G1が94x94の文字集合であるという保証もありません。
>　G1はまさにそのとおりですが、G0は94^n集合だけだそうです。0x20の
>空白が使えない、というのが主な理由になるようです。

  はい、G0の制限については存じております。でも94x94や94x94x94が
来る可能性もあるので、やっぱり94文字集合であると決め付けるわけに
はいかないでしょう。

>　また、シングルシフトはLとRを区別しないのが今の仕様だそうですが、
>私の計算はGR専用です。むむう。

  ありゃりゃ・・・ちゃんとANDしてマスクしてくださいね（笑）。

>　ところで94(or 96)文字集合にはやっぱり128文字分の空間を与えるん
>ですか。これってGL:GR=JIS X 0201みたいな特殊な場合にしか効かない
>配置じゃありませんか？（これだけ最適化とは(^^;）

  いや・・・その・・・。

  実は、G0が1バイト文字でG1が複数バイト文字と指定されたら、こん
な風に動いてくれることが僕の理想なんです。

  0x20〜0x7eの文字：これは問題ない。普通にbase0を加える。

  0x00〜0x1fの文字：これもbase0を加えてしまう。
  0x7f, 0xffの文字：これもbase0を加えてしまう。
  0x80〜0xa0の文字：これもbase0を加えてしまう（もちろんシングル
                    シフトのコードは除く）。

  G0に複数バイト文字が指定された時は、これらの文字に遭遇した時の
挙動を定義しないでいいです（アプリ高速においては、暴走してもいい
です）。・・・そんな訳で、G0が1バイト文字かつG1が複数バイト文字
の場合、与えられる文字空間は128文字以上です（まあ256文字と言って
もいいでしょう）。

  また、たとえば日本語EUCのシングルシフトでG2が呼び出されたあと
に0x80〜0xa0など「来てはいけない」文字が来てしまったとしても、そ
こは何事もなかったかのようにbase2を加えるようにして欲しいんです
。

  こんなEUCの規定を超えるような文字についての取り決めはけしから
んと思うかもしれませんが、グラフィックキャラクターを使ったテキス
トというものが存在して、そして以上のようなたわいもない配慮をする
だけでこれらを救えるのですから、安いものです。・・・これは過去の
資産に救いの手をさしのべるためのものであり、新たにこれを前提にし
たテキストが増えてほしいというわけではありません。

  まあでもこんな細かい仕様を設定しなくても、この手のテキストはア
プリが自分で変換するってことにしてもいいような気もしますね。マイ
ナーなものは自分でやれと（そんなに大変じゃないんだし）。・・・と
いうことで、上記仕様のうち面倒なものは実装しないでいいです。

>>  これらは仕様であって、利用されないと思われるうちは、未実装であ
>>ってかまいません。
>　現実に即した最適化というわけですね。

  最適化というよりは、開発時間の短縮ってやつかもしれません（笑）
。ばれないのなら、徹底的に手を抜いてもよい、と（笑）。

>>  たとえば、こんな仕様はどうでしょう？
>>    cmd(0x00ec), opt, len, ptr_src, ptr_dst, base0, base1, base2, base3
>>ここでoptの下位16bitを0x0003にさせることにして、これはUniversal
>>EUCを意味するということにします（0x0002はSimple EUC）。そして、
>　下位二ビットとは……いつかどこかの他人の空似(^^;;;
>　シンプルEUCが取り分けてあるのは最適化のためなんでしょうか？
>確かにレジスタに余裕ができますけど。
>    下位二ビット=G2使用ビット:G3使用ビット
>みたいな意味ではないのでしょうか。

  違います。

  0x0000 : リザーブ
  0x0001 : Shift JIS
  0x0002 : Simple EUC
  0x0003 : Universal EUC
  0x0004以降 : 他国の標準的コードや将来の拡張性のためのリザーブ

  Simple EUCがUniversal EUCと分けてあるのは、OSASK ver.1.9との互
換性のためです。・・・でも、I.Tak.さんの使用bit制もなかなかいい
案だと思います。問題はその2bitをどこに割り振るか、ですが・・・。

  僕としては下位16bitは手をつけて欲しくないので、上位16bitをいじ
ることになります。そうなると、たとえば、bit24-25を使えばいいとい
うことになるでしょう。ここまではいいです。でも、ver.1.9において
はSimple EUCは上位16bitを0にするという仕様だったので、G1が2バイ
ト文字であると認識されません。これはまずいです。

  やっぱり互換性のためには、分ける方がいいんじゃないでしょうか？
僕のセンスとしては、わずか数十バイトで互換性が維持できるなら、悪
くない代償です（これが重荷になるようなら、ぐいぐい01仕様に移行す
る時にSimple EUCをなくせばいいんですし）。使用ビットをつけるかど
うかはお任せしますが、別に無くても問題はないと思います（それより
も手付かずの8bitを将来のためにキープしておく方がいいのではないか
と）。

>>>　ちなみにKS C 5601は番号不足で1997年にKS X 1001になったそうです。
>>  KS C 5601の後ろの空きに文字を割り当てたのかな？？？
>　あ、これは JIS C → JIS X と同じ移転があったということです。

  はあ、なるほど。ようするに仕様名称が変わっただけで、仕様内容に
変化はないということですね。

>それから、Unicode2.0ではすでにハングルの全文字収録および移転ができて
>いるそうです。完成形ハングルを20%しか含まない文字集合の韓国標準化には
>反対があったとか、あちらでも問題は多いようで。

  まあ、それはそうでしょう。OSASKの文字コードは有り余っています
から、TRON文字コードや全ての組み合わせの完成型ハングルなどを取り
込んでいきたいです。10万文字や20万文字なんて、仕様全体の1%ほどで
しかありませんから。日本語の補助漢字や第４水準もいつか入れてあげ
たいですし。

>>  ・・・とりあえず上の仕様にしてoptを0x00440003に限定すれば、I.T
>>ak.さんのルーチンはほとんどそのまま使えそうです。それでよければ
>>OSASK ver.2.1に組み込みましょうか？
>　せっかく一ヶ月もあるし、もっといじります。

  そういうことなら、楽しみに待ちます。


  それでは。

--
    川合 秀実(KAWAI Hidemi)
川合堂社長 / OSASK計画総指揮 / カーネル開発班
E-mail:kawai !Atmark! imasy.org
Homepage http://www.imasy.org/~kawai/