アカウント名:
パスワード:
X Window System 上での日本語 (多国語) 入力には、XIM という標準が存在します。 (Project HEKE では IIIMF はステだそうですが、IIIMF を推進している人たち [Sun だとか Li18nux だとか] にはその問題点を伝えたのでしょうか。 将来にその問題点が改善される見込みは?) しかし、コンソール上で日本語を使いたいと思ったとき、 各々のソフトウェアが Canna/Wnn といった各々のプロトコルの API をそれぞれ実装して対処している、というのが現状です。この方法だと、
IIIMF はじつは試してみたことがあるんですが、コンパイルエラーの山で、それをとりあえず消すためにいろいろと小手先の対応をしてやっとの思いでバイナリを作ったらこんどは segfault するので、もう手が付けられなくなって投げ出した、という過去があります。
いまはもうちょっとましになっているのかもしれませんが、Sun という大きな後ろ盾を持っていながらこの品質ではなあ、と思ったことです。
が、ロケール非依存、Unicode 使用、というのは世の人々に対するウケがいいですから (Yudit の作者の Gaspar Shinai さんも気に入ってました。Yudit が kinput2 をサポートするのに XIM をサポートしないのは、XIM がロケール依存だからだそうです)、たぶん広まることでしょう。文句を言う、というよりは、未完成のソフトウェアには欠陥があるのが当然なのだから、どんどんバグレポートを出してあげるというスタンスでやるのがいいのではと思います。とくに、XIM とか IIIMF って分かってる人が少なそうですので (ぼくもさっぱり分かりません)、分かってる人が指摘しないとだれも指摘しないで終わってしまう恐れがあります。
政治力云々ですが、ぼくも Unicode Consortium に文句をつけたりしていると、そういうことを感じたりもします。Unicode の場合は政治力同士の力のせめぎあいや対立、という側面が強いですが、IIIMF はどうなんでしょうか。Sun だけがやっているので、政治的対立を生むような対抗勢力が存在しないような気がするのですが。
Sun という大きな後ろ盾を持っていながらこの品質ではなあ、と思ったことです。
もともと Sun の社内製品ですから,Solaris 上でしか動作確認されていないだろうし,Solaris 独自のライブラリやソース公開できない他製品に依存していたかもしれないし,移植性という意味ではそれほど期待しない方がいいでしょう。
だいたい,移植性を考慮し出すと,X のソースみたいな #ifdef の嵐になるものです :-)
が、ロケール非依存、Unicode 使用、というのは世の人々に対するウケがいいですから (Yudit の作者の Gaspar Shinai さんも気に入ってました。Yudit が kinput2 をサポートするのに XIM をサポートしないのは、XIM がロケール依存だからだそうです)、たぶん広まることでしょう。
XIM が検討されていたのは10年くらいは前のことです。 そのころはまだ Unicode も正式な仕様としては出てなかったし, ロケールに依存しないで国際化プログラムを組もうとすれば, Compound Text や ISO-2022-JP みたいなエンコーディングを 直接いじらざるを得なかったし, 全てのプログラムの文字列処理にそこまでやらせるのは, かなり無理があったものです。 (xterm の議論 [srad.jp]を見る限りでは,今でも まだそこまで要求するのは無理そうですが。)
マルチリンガルったって, 当時は mule だってあったかどうか (Nemacs はあったかな) くらいの 時代ですからね。
まあ,いまは Unicode も無視できないし, サーバ/クライアント・モデルで, どのプログラムが どこまでロケールに依存すべきか, という話もあるし,いつまでも昔のしがらみを引きずることも ないでしょう。いい方式があったらぜひとも提案してください。
でも,Yudit が XIM を使わないのは, 単に自分で何もかもコントロールしたいからじゃないの。 kinput2 がばりばり Unicode 対応したという話も聞かないし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
コンソール上での日本語入力 (スコア:2, 興味深い)
X Window System 上での日本語 (多国語) 入力には、XIM という標準が存在します。 (Project HEKE では IIIMF はステだそうですが、IIIMF を推進している人たち [Sun だとか Li18nux だとか] にはその問題点を伝えたのでしょうか。 将来にその問題点が改善される見込みは?) しかし、コンソール上で日本語を使いたいと思ったとき、 各々のソフトウェアが Canna/Wnn といった各々のプロトコルの API をそれぞれ実装して対処している、というのが現状です。この方法だと、
Re:コンソール上での日本語入力 (スコア:2, 参考になる)
#あとまぁ、ある偉い人にLinuxの世界も政治力だよと言われてやる気を無くしたという面があります。
コンソールで各国の入力システムを統合して扱うライブラリとしては、turbolinuxのunicon(の関連ページ) [linux.or.jp]があったと思います。
んで、これからは多少問題があるにして
IIIMF (スコア:1)
IIIMF はじつは試してみたことがあるんですが、コンパイルエラーの山で、それをとりあえず消すためにいろいろと小手先の対応をしてやっとの思いでバイナリを作ったらこんどは segfault するので、もう手が付けられなくなって投げ出した、という過去があります。
いまはもうちょっとましになっているのかもしれませんが、Sun という大きな後ろ盾を持っていながらこの品質ではなあ、と思ったことです。
が、ロケール非依存、Unicode 使用、というのは世の人々に対するウケがいいですから (Yudit の作者の Gaspar Shinai さんも気に入ってました。Yudit が kinput2 をサポートするのに XIM をサポートしないのは、XIM がロケール依存だからだそうです)、たぶん広まることでしょう。文句を言う、というよりは、未完成のソフトウェアには欠陥があるのが当然なのだから、どんどんバグレポートを出してあげるというスタンスでやるのがいいのではと思います。とくに、XIM とか IIIMF って分かってる人が少なそうですので (ぼくもさっぱり分かりません)、分かってる人が指摘しないとだれも指摘しないで終わってしまう恐れがあります。
政治力云々ですが、ぼくも Unicode Consortium に文句をつけたりしていると、そういうことを感じたりもします。Unicode の場合は政治力同士の力のせめぎあいや対立、という側面が強いですが、IIIMF はどうなんでしょうか。Sun だけがやっているので、政治的対立を生むような対抗勢力が存在しないような気がするのですが。
Re:IIIMF (スコア:2)
もともと Sun の社内製品ですから,Solaris 上でしか動作確認されていないだろうし,Solaris 独自のライブラリやソース公開できない他製品に依存していたかもしれないし,移植性という意味ではそれほど期待しない方がいいでしょう。
だいたい,移植性を考慮し出すと,X のソースみたいな #ifdef の嵐になるものです :-)
XIM が検討されていたのは10年くらいは前のことです。 そのころはまだ Unicode も正式な仕様としては出てなかったし, ロケールに依存しないで国際化プログラムを組もうとすれば, Compound Text や ISO-2022-JP みたいなエンコーディングを 直接いじらざるを得なかったし, 全てのプログラムの文字列処理にそこまでやらせるのは, かなり無理があったものです。 (xterm の議論 [srad.jp]を見る限りでは,今でも まだそこまで要求するのは無理そうですが。)
マルチリンガルったって, 当時は mule だってあったかどうか (Nemacs はあったかな) くらいの 時代ですからね。
まあ,いまは Unicode も無視できないし, サーバ/クライアント・モデルで, どのプログラムが どこまでロケールに依存すべきか, という話もあるし,いつまでも昔のしがらみを引きずることも ないでしょう。いい方式があったらぜひとも提案してください。
でも,Yudit が XIM を使わないのは, 単に自分で何もかもコントロールしたいからじゃないの。 kinput2 がばりばり Unicode 対応したという話も聞かないし。