「TRON、やっとお上に認められる」記事へのコメント

国産技術ならなんでもOKではないけど

[hctom (8713)]

ほかのトピックで「日本の政府もほかの国に倣ってLinuxを導入したらどうか」的な発言が出てましたが、いっそのこと超漢字のようなTRON系OSを導入してみてはどうだろうか。

いいじゃねえか、どっかの国がいつぞみたく文句言ってきたら
「われわれはもっとも優れたものを導入しただけだ」
って

Re:国産技術ならなんでもOKではないけど

[Anonymous Coward]

ＴＲＯＮ

なんとかうちの学校のシステムをWindowsから移行したいと思って
いるのですが、OpenOfficeなどを見ても、日本語を扱うと満足に
表示できず（ポイントの指定が反映されない、全角文字が重なるなど）
まだ完全に移行するにはデスクトップの環境が良くないですね。
インストール時に認識できたディスプレイが次のバージョンで認識
できなくなっていたりということもあって、初心者にはまだ難しい
レベルですし。この点ではWindowsのほうが遥かにフレンドリー。

超漢字にも手を出そうかと考えていますが（やっぱり扱える漢字の
確実さが重要ですから

Re:国産技術ならなんでもOKではないけど

[kubota (64)]

Unicodeを使われると、生徒の名前や住所すら満足に表示できませんからね。

Windows も Macintosh も、すでに内部は Unicode で動いてますよ。

ちなみに、Unicode の漢字統合ですが、JIS も同様な統合 (包摂) の規準を持っています。「Unicode では漢字が化ける」のは、実際のフォントを作る際に、その統合された字形の範囲の中から具体的にどの字形を採用するか、というのが国ごとに違ってくるから。ですので、Unicode を使っていても、日本語のフォントを使っている限りは、従来の Shi

Re:国産技術ならなんでもOKではないけど

[Anonymous Coward]

坂村氏はUnicode批判のきゅうせんぽうだったんですが、 あきらかにUnicodeのspecを読んでいないレベルの批判 だったので文字コードの専門家からはほとんど相手に されませんでした。

はしご高がUnicodeでは表示できないなどと言ってました。

ExtensionA/B

[Anonymous Coward]

が導入される前の時期なら、はしご高と普通の高を区別できないので正解かと思いますが。
たしかUnicode3.0が確定する前の話だったと思いますが。
ところで、日本で「文字コードの専門家」ってだ

Re:ExtensionA/B

[Anonymous Coward]

> Extension A/B また、そーゆー見てきたようなウソを書く。

U+9AD8が高
U+9AD9がはしご高
とコードポイントがわりあてられています。 Unicode V2.0 7-409ページを見てください。

当然のことながらJIS X0208では「高」と「はしご高」は 包摂されているという立場ですから、JIS X0208にマップ したら区別できなくなります。ですから、坂村氏の主張は Unicod

たしかに

[Anonymous Coward]

昔のUnicodeでもありますね。とはいえ、土吉とか考えると本質的な問題は残っている気がします。
ここらへんの包摂基準はどこで線引きしているんでしょう？
個人的には、こういうのは全部異体字識別bitを割り振ってもらった方が、異体字テーブルがいらなくて良いように思いますが。（竜と龍とか言う人もいるでしょうが）
とりあえず、第３、第４水準という

Re:たしかに

[alp (1425)]

第三、第四水準が X-0213 のことなら、Unicode 3.2 で漢字は全部収録されています。蹴飛ばされたのは、半濁点付きかな「か゜」などと、a e の合字に Diacritics が着いた文字だけですが、この辺は合成で表現できるのでコード的には OK。実装は別。

＃slashcode の動きが変だぞ。aelig が入らん。

合字

[Pooh (4850)]

すでにTRONネタでないので参加していいものやら。 Unicodeで合字と一文字の二つがある場合、どちらかに統一されているのでしょうか？とくにラテン文字。「が」と「か＋”」っとかウムラウトとかを検索するためのコードをいちいち想定して書くのは、あらゆる言語に通じた人でないと無理ではないかと。Performanceも落ちそう。

Re:合字 (オフトピック)

[alp (1425)]

TRON の話から脱線ですが、統一されていません。というより、分解すると同じものになるのに包摂していないラテン文字がかなりあるので、統一しようがないです。この辺の扱いは、アプリケーションの考え方依存だと思うけど、互換分解結果を持って包摂基準にするなどの割り切りをすれば、検索コード想定云々の問題は回避できるかも。どちらにせよ、言語とは別問題でしょう。