心機一転

いろいろあって、微妙にSLから離れていたのですが、心機一転、またがんばります。

ということで、ブログのデザインも変えてみました。実は、エヴァ好きなんですよ、恥ずかしながら。映画も封切りだし。

そういえば、SL始めたばかりの右も左もわからなかったころ、たまたまNakama というSIMに迷い込んだところ、巨大なエヴァのオブジェがあってびっくりしました。あれから9カ月経つんですねぇ。

再変換と文脈変換のこと

最近、何度かこのブログに書いてますが、せっかく対応したので再変換とか文脈変換とかについてもう一度解説します。SL でその場入力を試すときに、一緒にやってみてください。

再変換

もう確定しちゃっている部分とか、そもそも自分が入力したわけじゃない文章 (Notecard など) とかを、未確定状態に戻して、漢字を選び直すことができます。未確定に戻したい部分を選択しておいてもいいし、特に選択しなければ文字カーソル (カレット) 近所が適当に選ばれます。具体的な操作は、カナ漢字変換によって違いますが、代表は次の通り。(どれも、キー操作をカスタマイズしていない場合です。)

Windows + MS-IME (普通の日本語入力) の場合

「変換」キーだけ。(普段「スペース」で変換している人も、再変換は「変換」と書かれたキーを押してください。)

Windows + ATOK の場合

「シフト」+「変換」。

Windows + Japanist の場合

「変換」。

MacOS + ことえりの場合

「かな」を二回。マウスのダブルクリックのような感じで、ハタハタっと押す。

MacOS + ATOK の場合

「コントロール」+「シフト」+「Y」。

ことえりだと、英単語を再変換するとカタカナになったり、英字でローマ字書きの部分で再変換するとそれを読みとして普通の変換に突入したりするみたいですが、その他のかな漢字変換では、英字に対する再変換は無効みたいです。

文脈変換

入力しているときに、前後の文章を手がかりにして、より適切な漢字を選ぶ機能。「適切」と言っても、場面によっては相変わらず変な漢字が出ることもあります。要は辞書次第。再変換と違って、はっきりと「文脈変換された」ことがわかる場面は少ないと思います。特別な操作はなく、普通に変換していると、有効ならば有効になります。

以前、
　花が
　時間を
　紙を
　苦肉の
という例を紹介しました (それぞれ、行末にカーソルを置いて「さく」と入れて変換する) が、かな漢字変換によっては、入力している場所の後も参照します。これは、新規に入力しているときではなくて、途中に挿入するときに有効です。例えば、
　一髪
　迫る
　として
　怪々
　希林
などをNotecardで用意しておいて、それぞれの「前」に、「きき」と入れて変換すると、面白いかもしれません。(結果は、かな漢字変換ソフトや、辞書の状態によって異なります。

1.18.2.0対応「日本語その場入力」アップロードしました。

日本語その場入力 1.18.2.0 対応版 (20070819版) を、アップロードしました。

Windows用

IME-20070819-Win32.zip

Macintosh用

IME-20070819-Mac.zip

MacOS用は、ユニバーサルバイナリになっていますので、IntelでもPowerPCでも使えるはずです。

お試し下さい。

1.18.2.0対応「日本語その場入力」の予告

日本語その場入力の1.18.2.0対応版は、今日も、準備できませんでした。もう少しかかります。できれば、明日まとめちゃいたいのですが…。

ということで、予告です。

• MacOS版とWindows版の両方を配布します。MacOS版は、Universal Binaryになる予定です。
• 機能的には、日本語再変換と文脈変換に、全面的に対応しました。WindowsでもMacOSでも、かな漢字変換側が対応していれば、使えるはずです。
• コードのクリンナップを始めています。デバッグ用コードは、大分削除していますが、まだ少し残っています。

また、バグもいろいろと修正しています。

• 「かな漢字変換側の入力モードの初期値の設定 (全角・半角など)」が無視される場合があったのを直したつもり。
• 他人のプロフィールの「メモ」に日本語入力できなくなってしまう件を修正。
• フォーカスが移動するタイミングで文字を確定させるように、逃げのコードを入れてみました。変な副作用がでないか少々心配ですが…。
• パスワード欄は、日本語入力を自動offするように変更。
• Windows 中国語入力で、「読み」が微妙に変な位置に出ていたのを修正。変換候補のフォントがおかしくなることがある点も修正。
• 未確定文字列につく下線の、色の濃さとか太さとかを調整。

なかなか厳しい

なんだかんだで、いろいろ厳しいです。このごろ。

ボイス対応の日本語入力を期待しているみなさん、ごめんなさい。

Mac版でも文脈

ということで、Mac版のビューアでも、再変換とか文脈変換とかの対応ができたような気がします。ただ、ことえりだと、再変換はできても、文脈は見てないみたいですね。これは基本的にはかな漢字変換側の機能なので、ビューアがいくらがんばっても、かな漢字変換が対応していないことには、なんともなりません。宣伝などを見る限り、egbridgeが激しく文脈を見るみたいです。

私はATOKで試していますが、それなりに文脈を見ている感じがします。(ただし、ウィンドウズ版の場合と同様、デフォルトでは文脈を見ないように設定されているようなので、自分で設定を変更しないと有効になりません。これはなぜなんでしょうか。有効にすると、何か悪影響があるのでしょうか。

現在、パッチを配る準備中です。しばらくお待ちください。

TSMに文句を言うシリーズ第二弾

TSM Document Accessというのは、要はInput Methodなどのテキストサービスが、アプリケーションが管理している文書ファイルの内容にアクセスするための仕組み。日本語入力という点では、これを使うと再変換とか文脈依存変換とかの高度なことが実現できる。英語圏でも、これを使うと、自動スペルチェックと修正候補の提示、みたいな機能を、アプリケーションと独立に外付けで実現できる。日本語の再変換とか英語の自動スペルチェックとかは、昔から、ワープロソフトの機能としては存在していたわけで、TSMの意義は、再変換とかスペルチェックとか自体にあるのではなく、そういう機能をアプリケーションから切り離す点にある。

マイクロソフトは、たぶんアップルよりも早くから、再変換のための標準APIとかスペルチェッカのAPIとかを作ってたけれど、仕様を見ればわかる通り、それは「日本語入力で再変換をするためのAPI」だったり、「ワープロでスペルチェックを行うためのAPI」だったりした。汎用性皆無。再変換のAPI (IMR_RECONVERTSTRING) は、再変換以外の用途に使うことは、ほとんど考えられない。アップルのTSMが偉いのは、用途を限定しないように注意して設計されているフシがある点。もっとも、TSM DAとほぼ同時期にマイクロソフトも、TSFという、仕組みだけじゃなくて名前までよく似たAPIセットを作っているので、特別にアップルが先進的というわけではないけれど。

と、TSMをほめたけど、TSM DAには、一カ所サイテーな部分がある。それは、TSM DAはアプリケーションが文書の内部表現をUTF-16で持つことを大前提にしている点。TSM DAでは、テキストプロセッサがアプリケーションの内部にある文書ファイルへのランダムアクセスを可能にするためのインターフェースを定義しているのだが、これがどれも「文書の先頭から数えて、UTF-16で表現されているとしたら××バイト目」という位置指定なんですよ。「文書の内容がUTF-16でベタベタっと並んでいるメモリの先頭アドレスを教えるから、あとは勝手にやって」なんていうAPIまである。(これは、オプションで、サポートしなくてもいい。そのことは、しつこいくらい書いてあるけど。) このインターフェースは、実際に、文書ファイルを UTF-16 で記録しているアプリには有利。でも、そうじゃないアプリは、TSM DA のインターフェースのところで、いちいち、UTF-16との間で変換をしなくちゃいけない。データそのものの変換はしかたないとして、「位置指定」まで毎回変換。しかも、この位置指定は、文字単位での整列が保証されていない。サロゲートペアの後ろ (low surrogate) だけ、とか、そういう位置指定ができる。

でね、SL Viewer って、内部は UTF-8 と UTF-32 でできてるんですよ。UTF-16は使わない。

あー。

TSMのドキュメントわかりにくいよ

TSMの仕様書を読みました。

極めて難解。

いや、別に内容が特別難しいということではありません。わかってしまえば、割と普通。ただ、説明がサイテー。最初のうちは、何がなんだかさっぱりわからない。まさか、この世に Win32 API Document よりもデキの悪い API 仕様書が存在するとは思いませんでした。世の中広い。

で、思ったこと。このTSMの仕様書では、document という言葉が、3通りの、まったく異なる意味で使われているのが不必要に難解にしている原因。

• まず、アプリケーションが内部的に保持する、ユーザに編集させるテキストデータのことを document と呼んでいる。まぁ、これは普通の用法。
• 次に、TSM Documentというモノがあって、これのことも単に document と呼ぶのです。TSM Document というのは、MacOS が内部的に確保する一種の作業用メモリで、アプリケーションからは直接アクセスできない。こういうモノを document と呼ぶ用法は、私は TSM 以外では見たことがありません。TSM の仕様書では、アプリケーションのテキストデータも、TSM Document も、両方とも単に a document とか the document とか書いてあるので、読者はどちらの意味なのか正しく見極める必要があるのです。もう、紛らわしくてしょうがない。
• 最後に、MacOSの各種の仕様書のことも document と呼んでいる。この用法もまぁ普通ですが、すでに十分紛らわしいところに、さらに別の意味の document が登場するので、もう泣きそうです。

で、このうえ、ですね。

私は、日本語入力の「再変換」に対応しようと思ってこの仕様書を読んだわけですが、そこで必要になる TSM Document Access というメカニズム、ここに登場する document は、実に、TSM Document のことじゃなくて、アプリケーションのテキストデータのことなんですよ。つまり“TSM Document”Access じゃなくて、TSM “Document Access”なんです。苦労した結果やっとわかったことは、TSM Document Access という仕組みには、TSM Document が、まったく登場しないんです。TSM Document Access は、TSM Document と、まったく関係ない。だから、ここだけ読む分には、まったく紛らわしくないのですが。でも、そのことに気づくまでにずいぶん時間がかかっちゃいましたよ。

はー。

たぶん、この仕様書を書いた人には、そんなことは自明で、こんなことで読者が混乱するなんて予想もしてないんでしょうねぇ…。

Linux版で日本語入力できるようになりました

以前から書いているLinux版のSecond Life Viewerで日本語入力できるようにする件ですが、先日リリースされた1.18.1(2)に、予定通りSDL 1.2.12の実行時ライブラリ (libSDL-1.2.so.0) がバンドルされるようになりました。

つまり、ファイルの入れ換えとかパッチあててコンパイルとかは不要で、そのままで、日本語入力ができるようになりました。

ただ、何人かの方から個人的に問い合わせを受けていますが、環境によって、うまく日本語入力できない場合があるようです。すべてのケースに関して調査できていませんが、環境変数の設定によって解決する場合が多いようです。

うまく日本語入力できない場合には、以下の点について確認してみてください。

• 現状のSL Viewerの日本語入力は、XIM専用です。より現代的な仕組みには対応していません。環境変数GTK_IM_MODULEの値は、 GTK_IM_MODULE='xim' と設定してください。
• 環境変数XMODIFIERSの@imパラメタに、使用するXIMサーバの名前を設定してください。具体的な名前は、使用するInput Methodのドキュメントで確認してください。また、この設定は、大文字・小文字を区別するので注意してください。たとえば、SCIMならば"SCIM" (注: 大文字) ですし、uimならば"uim" (注: 小文字) です。私はSCIM-Anthyを使っているので、 XMODIFIERS='@im=SCIM' と設定しています。
• 一部のIMは、環境変数LANGの値も見るようです。IMの仕様と、ディストリビューションとの組み合わせによって、有効なロケールは違うと思いますが、上の二つをチェックして、まだだめならば、 LANG=ja_JP.UTF8 を試してみてください。

※ なお「電源ケーブルはコンセントに差し込まれていますか?」レベルですが、XIMサーバが起動していることも確認してください。

TSM Document Access

MacOSで、再変換とか文脈依存変換とかに対応するためには、Text Services Manager Reference の Carbon Events for TSM Document Access のところを読めばいいらしい。

いあ、もちろん読むだけじゃだめですが…。

文脈依存変換

文脈依存変換なるものが、一部で流行っているようです。

皆が使うアリキタリの例ですが、たとえばあらかじめファイルに、

花が
時間を
紙を
苦肉の

などと入力してあるものを、テキストエディタなどで開き、「さく」という読みを入れて変換した場合、「花が」の後だと「咲く」に、「時間を」の後だと「割く」に、という感じで、前後関係 （この例は前だけですけど) に応じて最適な漢字が自動的に選択される、という機能です。「はながさく」と入れて変換すれば、もちろん「花が咲く」になって当然なのですが、文脈依存変換は「花が」の部分をIMEで入力したんじゃなくても効くというのが特徴です。

実用性は少々疑問ですが、デモを見せると「おーっ」と言ってもらえます。

これは、もちろんIMEの機能なのですが、有効にするためにはアプリ側にも対応が必要です。まだ、この機能に対応したアプリはほとんどないため、存在自体があまり知られていないようです。

が、実は以前紹介したその場入力パッチには、文脈依存変換への対応が仕込んであります。Windows XP の MS-IME を使って、ノートカード等で試してみてください。

MS-IMEを使って、と、わざわざ書いたのには理由があります。実は、ATOK など、他の IME は、IME 側が対応していないようなのです。最新の ATOK でも試してみましたが、そもそも IMR_DOCUMENTFEED が来ません。ということで、どうも私は、MS-IME 専用機能
を作ってしまったようです…。

強制確定

日本語入力で未確定文字列がある時にマウスで別の場所をクリックすると、普通は、文字列が強制確定します。これを実装しようとしてたんですが、どうも難しいみたいです。

イベントが、まずマウスでクリックされたほうのコントロールに行くのですが、そこから、未確定文字列があるほうに最初に制御がわたるonFocusLostが呼ばれた時点では、もうフォーカスが移ってしまっていて、確定文字列を受け取れる状態ではなくなっているのです。

困ってます。あきらめちゃおうかな…。