そこで、Linux/BSD のコンソールそのものあるいは GNU screen
などが、日本語などの変換エンジンと交信できるための統一的な
API があればいいなと思うのですが、そのようなプロジェクトって、
あったりしないでしょうか?
uum/canuum/skkfep みたいなアプローチでもいいのですが、
これだと、システム側の設定やユーザのドットファイルによる設定になじまないし、その上で走っているアプリケーションの実行中に動的に切り替えることができません。
やはり、標準 API が存在し、そしてその API が生き残るためには世界標準 (デファクトスタンダードでもいいです) でなければならず、そのためには「日本語のための規格」であってはならないと思います。
コンソール上での日本語入力 (スコア:2, 興味深い)
X Window System 上での日本語 (多国語) 入力には、XIM という標準が存在します。 (Project HEKE では IIIMF はステだそうですが、IIIMF を推進している人たち [Sun だとか Li18nux だとか] にはその問題点を伝えたのでしょうか。 将来にその問題点が改善される見込みは?) しかし、コンソール上で日本語を使いたいと思ったとき、 各々のソフトウェアが Canna/Wnn といった各々のプロトコルの API をそれぞれ実装して対処している、というのが現状です。この方法だと、
そこで、Linux/BSD のコンソールそのものあるいは GNU screen などが、日本語などの変換エンジンと交信できるための統一的な API があればいいなと思うのですが、そのようなプロジェクトって、 あったりしないでしょうか?
uum/canuum/skkfep みたいなアプローチでもいいのですが、 これだと、システム側の設定やユーザのドットファイルによる設定になじまないし、その上で走っているアプリケーションの実行中に動的に切り替えることができません。 やはり、標準 API が存在し、そしてその API が生き残るためには世界標準 (デファクトスタンダードでもいいです) でなければならず、そのためには「日本語のための規格」であってはならないと思います。
とかいいながら、ぼくは XIM のプロトコルでさえろくに理解してなかったりする...
Re:コンソール上での日本語入力 (スコア:2, 参考になる)
#あとまぁ、ある偉い人にLinuxの世界も政治力だよと言われてやる気を無くしたという面があります。
コンソールで各国の入力システムを統合して扱うライブラリとしては、turbolinuxのunicon(の関連ページ) [linux.or.jp]があったと思います。
んで、これからは多少問題があるにしてもgtk+-immoduleとIIIMFがデファクトスタンダードになっていくと思われます。(欠点はそれぞれgtk+でしか使えないということと、入力システムとしてどうかなぁという設計)
私個人としても各国の言語の固有の問題について調査/整理をして、そのような理想になるべく近い入力システムを設計しようとして仕様書を少しずつ書いてはいるのですが、いつ動くかはわからない超長期プロジェクトになりそうなので期待しないでくださいまし。
Project Hekeとしての目標はそれらの問題に対しては目をつぶって、できるだけ日本語の入力をうまく処理することにしぼっています。
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 対応したという話も聞かないし。
一つの解法として (スコア:2, 参考になる)
えせかんな [netfort.gr.jp]という物があります. これは基本的に日本語対応ですが, VJE等をCannaサーバに見せかけることにより, XIMに対応していない(例えばkinputプロトコル専用の場合等)プログラムでも市販の日本語フロントエンドが使えます.
まあCannaのAPIが多国語対応として良いかどうかは別問題ですが(けど中文版Cannaってのもあるんだよね), 過渡的な対処方法の例にはなるのではと思います.
GIMP (Generl Input Method Protocol) (スコア:1)
GIMP という名前は置いておいて (スコア:1)
readline ライブラリのようなものの上に実装されると嬉しいと思われ。
# mishimaは本田透先生を熱烈に応援しています
多スクリプト入力はどのレイヤーがいい? (スコア:2, 参考になる)
なぜ? readline ライブラリだと、それを用いたアプリケーションでしか日本語を入力できないですよ。世界中のすべてのコンソールアプリを readline (のようなもの) 対応に書き換えないといけなくなります。(実際に GNU readline を使おうとするとライセンス問題が発生しそうですが)。
ぼくは、コンソールそのものが変換機能 (をプラグインできるためのインターフェース) を持つのがいいと思っています。GNU screen だとか uum/canuum/skkfep とかでも「すべてのソフトウェアで日本語 (中国語、韓国語、...) を」は実現できますが、ログインした後にそれらを起動しないといけないのが不満が残るところです。ただ、どうせ別の目的で GNU screen を起動するんだ、という人の場合は、ついでに日本語変換もサポートしてくれたら嬉しいことでしょう。また日本語表示はできるけど日本語変換はできないリモート環境での利用においても、screen/uum/canuum/skkfep 的なアプローチは有効です。
というわけで、コンソールそのものを基本とし、GNU screen のようなレイヤーにも補助的に変換機能 (のプラグインへのインターフェース) を備えるといろんな場合に対応できて、いいんじゃないかと思います。
ところで、「思われ」というのはどういうニュアンスの言葉なんでしょうか。
Re:多スクリプト入力はどのレイヤーがいい? (スコア:3, 興味深い)
GNU screen の場合、相手が console だったり仮想端末だったりリアル端末 だったりするので、screen 自身で完結した機能をもった方がいいだろうなと 私は思っています。なので ああいうパッチ [daionet.gr.jp] を書きました。
screen に generic な front end をしこめるような 方法を以前から妄想はしてるんですが、なかなか実現に至りません。 一応 layer という概念が screen にはあるので、がんばれば できそうだなあという見通しだけはあるんですが...
あと、あのパッチはかなり ad-hoc な実装なので、 今後は期待しない方がいいです。私も最近はほとんどつかってませんし。
knok
Re:多スクリプト入力はどのレイヤーがいい? (スコア:1)
というか今の今まで screen というコマンドの存在を忘れていた。
実際、自分の頭の中に最初あったのはまず、
「VT100 with XIM」みたいな形で端末の規格の中にそれを押し込めてしまうものだったけど、
これにはちょっと無理がある。
その後「cursesライブラリ上に実装する方がよかろ」と思ったが、
それだと範囲が広すぎるのでは?との思いから readline に至ったわけなんだけど。
> ところで、「思われ」というのはどういうニュアンスの言葉なんでしょうか。
「思われる」「思われます」ですな。
# mishimaは本田透先生を熱烈に応援しています
Re:コンソール上での日本語入力 (スコア:1)
確か GNU screen には Onew のインターフェースがあったような記憶が仄かにあります (ローカルパッチの類かも。使い手ではないので良く知りません _o_;)。
Re:コンソール上での日本語入力 (スコア:1)
onew (スコア:1)
onew そのものの tar.gz (ずいぶん昔のものっぽいから tar.Z でもいいけど) がどこを探しても見つからないし、onew を統合していると言われている jvim-canna の tar.gz を調べてみたところ onew 由来らしきソースファイルがひとつあるだけでドキュメントさえもないのでよくわからないのですが、onew は日本語専用っぽい気がします。日本語専用のものが GNU のソフトウェアに統合されるということは、ありえないと思います。
GNU screen + onew は、ローカルパッチとしては、存在するみたいですね。
Re:onew (スコア:1)
README.ONEWを見た限りでは、日本語に特化したもののようです。
Re:onew (スコア:0)
Re:コンソール上での日本語入力 (スコア:1)
>日本語などの変換エンジンと交信できるための統一的な API
PocketBSD(に限る必要は全く無いが)方面には
MGL2 [sakura.ne.jp]という画面環境が有り、こいつ用のimのAPIってーかが存在します。
既にimcannnaとかimskkとかimkazeとか(^^;が有ります。
>これだと、システム側の設定やユーザのドットファイルによる設定になじまないし
MGL2は馴染んでいるような気がします。
#あーゆーのを以って馴染んでると呼んで良いんですよねえ?
>その上で走っているアプリケーションの実行中に動的に切り替えることができません。
で、MGL2のために、
imProxy [nifty.ne.jp]なんてものを作ったことが有ったりします(^^;
なんかかなりインチキくさいですし、色々不備も有りますが、
いちおうまがりなりにも「動的に切り替える」ことが出来ます。
proxy(代理)オブジェクトのノリっす。必要になったら必要な本物のimを起動して処理を丸投げするってわけね。
こんなんじゃ…だめですかねやっぱり?(^^;;;;;
Re:コンソール上での日本語入力 (スコア:1)
また、バックエンドの側の視点というのも忘れてはいけません。たとえば日本語の場合、各個人のデータは他のユーザから保護されないといけないし、変換エンジンはそのデータに対してトランザクション的なアクセスが必要だったり、独特のパターンで高速なアクセスが必要だったりします。また、それらのデータは入力を行うソフトだけではなくて、辞書を操作するユーティリティがアクセスすることも考えておかないといけません。
セキュリティ保護の枠組みとかは自分で持つのはかなり無理があるので、Anthyの場合はUnixのパーミッションのモデルとかsshなどに頼るようにしています。
オフトピながら (スコア:1)
国と言語は一対一対応ではないので、「多国語」よりも「多言語」の方がよいと思われ。
それを言うなら (スコア:1)
言語と文字 (スクリプト) も一般的には一対一対応ではないので、「多言語」よりも「多スクリプト」のほうが良いです。でもやっぱり入力モードは言語別のほうがいいから「多言語」のほうがいいかも。