Path: titcca!nttlab!nttyrl!morisaki
From: morisaki@nttyrl.ntt.jp (Masato Morisaki)
Newsgroups: fj.kanji
Subject: Re: RE:Shift-JIS vs EUC (Re: Kanji code of OSF/1)
Message-ID: < 15061@nttyrl.ntt.jp> 
Date: 13 Jun 90 17:07:32 GMT
References: < 43013@wsserva.sm.sony.co.jp> 
Distribution: fj
Organization: Advanced Information Systems lab., NTT, Yokosuka, Japan
Lines: 101

In article < 43013@wsserva.sm.sony.co.jp> ,
	michael@sm.sony.co.jp (Michael Knight) says:
>  	COMPOUND_TEXT そのものについてはどういう意見をお持ちですか？

現時点における一番まともな解だと思っています。
最低、ＣＴではすべてのベンダーが了解しているわけですし、コードその
ものも、しっかりベースのあるものです。ＣＳそのものは、表そのものが
議論されているのですから、いまは危険ですね。考え方の方向は賛成ですけど、
先取りは危険です。いま、ＣＳに手をだすのは、おっちょこちょいか、無責任な
人でしょう。

ＣＴに、＋α　をいれるのはかってですが （ＣＳ等）、これをうたい文句に
するベンダーはきらいです。
ほんとは、現状のＣＴだけに限定してほしいのですが、まあそれは他社との
差別化ですがら、かってでしょう。

が、わたしが社のコードに関する ultimate の権限があれば、
ＣＴだけをつかわせるという通達をだすでしょうね。

>  	台湾人は X 上で漢字を使えないですよね。
>  	ISO2022 は確かに大事な規格ですが ISO に加盟していない人々を
>  	犠牲にすることになります。

これは、純然たる政治の問題です。中国を代表しているのが大陸ですからね。
某？？？のベラ・チャン副所長さんも CT については問題にしていません
ですよ。
はなしは、それますが、入江さんも、ballot のとき Replay-Resent-To:
のヘッダをつけた mail を出すだけでなく、ご意見をのべられてはいかがです？

> >  下での投票の時、JIS 関係で 8bit 目の議論で両方を投票したのは！
> >  ベンダーのエゴですな。。）
>  	これってもしかして XLFD を提案したくせに
>  	-*-screen-medium-r-normal--10-100-75-75-m-100-jisx0208-kanji11
>  	なんて言う font を載せて堂々と売ってる会社の人のことですか？

そうです。

>  	そもそも JIS は何故 (J なんかを定義しているのでしょうね。

歴史ですよ。１９７０年代後半に designation の登録作業があって、いままでの
JIS code set を登録しただけだとおもいます。もう少しいえば、ASCII と
JIS の違いの部分は、その前の時代に各国対応に定義可能というのが ISO で
きまっていたからです。$ は通貨記号ですから、当然 yen になるわけです。
自国文化をきちんと反映したためですね。わたしは悪いとはおもいませんが。

こっからは余談：

なにも、US がベストだと信奉する必要はないですし、日本の SC2 委員のかた
がたは、どっかの独善家や翻訳作業屋さんたちと異なって、きちんとした
ポリシーをもってここ２０年、コードの問題に取り組んでこられていると
思います。１３年まえを考えてごらんなさい。あのときに、学術的な目的
で国語研の方が調査された漢字の頻度をもとに作成された某コード表のように、
いまでは通用しないコード表を選ばず、きちんとしたポリシーをもって作成さ
れた漢字表ができたことを。
いまでも国語審議会の方針が変更されても、ちょっとした手直しで通用できて
いるわけですよ。

まだ、文節カナ漢字変換の技術すらなかって、いかに漢字をいれるかを
議論されているときに、そのベースとなる漢字表が１０年以上もつかえる
という（たんにエンコーディングの議論だけですむという）。こういうの
が定義されたのは、驚異ではありませんか？
わたしは、当時、２度ほど、まったくことなる漢字表の変換表を手作業で作成
しましたが、これは大変な作業ですよ。１字ごとコードブックをめくって
探すわけですからね。しまいには、コードだけをダンプすると何が書いて
いるかよめるようになりますよ。
これが漢字プリンター、ディスプレイが普及するまえに標準ができたため、
この変換という苦労が、ベンダーのマシンがかわるたびにやらなくてすむ。
このことは、ユーザにとってどれほどいいことか。。
もし、あの時代にＪＩＳの漢字ができていなかったら、ほれプリンター
にだすときはあのコードで、などなど、きっと、かな漢字変換の技術など
もう１０年以上遅れていたことでしょうね。

エンコーディングの議論もまったく同じだと思います。いろんな思い付きを
採用するのでなく、栗林さんがいわれるように１９９０代以降を考えて
気にいる／いらない、あるいはサポートする能力がある／ないは別として、
１つ方式を全ベンダーが採用していかないと危険ですね。また、横やりを
いれたり、自己の利害を他の陰にかくれて押し込むというのは、すきでは
ありませんね。自己の利害追求だと堂々と論陣をはればいいのですがね。

どこの社でもそうだと思いますが、きちんとコードについて知識を持ち合わせ、
理解されている上層部の方はすくないとおもいますが、いかがでしょう。
わたしの知るかぎりコードについて、しっかりしたポリシーを早い時期に
社内で統一化した JEF は偉いですね。やはり日本の日の丸コンンピュータを
進めるという上の意気込みがあったからでしょう。
state less にするために、8 bit 目に 1 と 0 を立てるという方式は
JEF がオリジナルなのですよ。（いまでもそうかな？）
DEC code は 10 とすると JEF になってしまうから 11 ということを考えだし
た（おろかな。。。）のです。
カナの導入のために、single shift Right を用いるというのは DEC ですがね。
（なお、（）で「おろかな。。。。」とかきましたが、
　この当時の xxx の人はしっかりした考えをもっておられましたよ。
　ある意味では、dumb terminal 相手の encoding としてはよくできた方だと
　おもってました。VMS のようなミニコンの上で自然言語処理の研究ができた
　のですから。keypad editor というスクリーン・エディダつかえたのですから。）
　
− 以上は、DEC 漢字が作成される過程を外野から関係していた老人
   のたわごとですがね。 −

>   Hideo Irie (Michael Knight)	michael@sm.sony.co.jp

森崎