日本語入力で文節移動後の候補読み上げ
nishimoto nishimoto nvda-japanese-users 688 にて関連するご指摘をいただきました。
nishimoto x86 だけですが、ImmGetCompositionString から値を取り出すテストコードを書きました。
lp:~nishimotz/nvdajp/betterInput/ rev 4309 (miscdep 83 が必要）
もう少し仕様を整理する必要があります。
また、いままでアドホックに行ってきた変更とだんだん整合しなくなってきたので、見直しが必要です。
nishimoto IME関連の更新に取り掛かっています。
lp:~nishimotz/nvdajp/betterInput rev 4322
キーフックや API コールをなるべく Python で行う、使われていないパラメータやコードを削除する、といった作業をしています。
64ビットの実装にはまだ手を付けていませんが、コードを変更するたびに動作確認はしています。
未確定状態の複数文節については、既存のスクリーンリーダーでは読み上げ方をカスタマイズできるとのことですが、当面は「選択された文節を詳細読みする」という仕様ですすめます。
以下のチケットも考慮したいと思います。
nishimoto チェンジセット lp:~nishimotz/nvdajp/betterInput rev 4321 までは Microsoft Word 2010 （32ビット）の未変換文字が読み上げできています。
チェンジセット lp:~nishimotz/nvdajp/betterInput rev 4322 から未変換文字のキーエコーができていないので、この4322の変更が32ビットアプリのTSF対応を壊しています。
nishimoto チェンジセット lp:~nishimotz/nvdajp/betterInput rev 4324 で 4322 のリバースマージをして元に戻しました。
nishimoto チェンジセット lp:~nishimotz/nvdajp/betterInput rev 4335 までの作業で、以下のようなアプリに関する改良のめどが立ちました。
Microsoft Word 2010 (x86) は TSF のイベントしか使えておらず、プリエディット文字列そのものしか取れていません。
いったん開発スナップショットにマージして評価してみたいと思います。
いまの実装では、キーエコーのために文字列の差分を取っています。この処理は最初は C++ で実装されていましたが、今は Python 側で行っています。
ImmGetCompositionString の GCS_DELTASTART を使えば、文字列の差分を取らなくてもよくなります。テストコードはちゃんと動いています。しかし、同じような情報が TSF だけで取得できるか分かりません。
また、文字列を詳細読みするかどうかを判断するために、プリエディット文字列の変化だけでは情報が足りないため、キーフックで仮想キーコードを取得して、これらを併用して判断しています。TSF の ITfKeystrokeMgr を使えば仮想キーコードは取得できそうですが、実装をやりなおすべきかどうかわかりません。
他にも TSF には有用そうなインタフェースがあるのですが、テストコードがハングアップすることもあり、試行錯誤の状況です。
nishimoto 本家の inputMethods ブランチへの情報提供をわかりやすくするために、日本語入力の改良は nvdajp のメインブランチで行うことにしました。
チェンジセット lp:nvdajp 4251 までの作業で、不具合はいろいろあるものの、方針は整理できました。
jpdev120625 は ATOK で変換操作の直後に最初の1文字しか読まない、という現象が報告されています。
これは、変換操作時に ATOK がキャレットをコンポジションの先頭に移動するため、キャレット移動時の処理で1文字読みになっていました。 ちなみに Microsoft IME では変換操作時にキャレットはコンポジションの末尾に置かれます。
さらに ATOK はコンポジションで文節を移動するとキャレットを選択文節の左端に動かすようです。
文節移動、およびキャレット（カーソル）移動時の挙動をどのような仕様にすればよいか、少なくとも Microsoft IME と ATOK の両方に配慮しながら検討する必要があります。
nishimoto チェンジセット lp:nvdajp 4255 までの作業で、64ビットアプリにおける IMM のサポートを改善しました。
Python 側のコールバックメソッドについては32ビットと64ビットの処理を統合しました。
いくつかの環境で、キーエコーなどの読み上げが重複する不具合が残っています。
細かい挙動の調整は Python だけで行なえるようになり、 C++ 側を修正する必要は、ほとんどなくなったと思います。
ATOK で複数文節の変換を行なったときも、読み上げが欠落しないようにしたかわりに、文字単位のカーソル移動の読み上げはうまく動いていません。
矢印キーで文節を左右に移動すると、キャレットの位置に関わらず、選択された文節（文節属性が取得できない場合は、文字列の書き換わった部分）を詳細読みする仕様になっています。
IMM と TSF を扱うためには DLL を使うしか方法がありません。MSAA は NVDAObject として Python で実装できます。
IMM, TSF だけではできない処理のためにキーフックも併用しているのですが、キーフックの処理は Python に移しました。
nishimoto nishimoto このチケットのタスクとすこしずれているのですが、下記のコミットについて。
lp:nvdajp 4331
修正のひとつは、TSF アプリケーション（Microsoft Word, ワードパッド）で、未変換文字と変換直後の第一候補が同じ文字列であるときに（「も」を変換して第一候補が「も」になるような場合）第一候補の詳細読みが正しく行なわれるようにしました。これは 2012.2.1jp では問題ありませんが、いろいろ修正を加えているうちに壊れていたようです。
もうひとつは、候補の詳細読みが重複して音声エンジンに送られる現象の回避です。音声のしゃべり始めで途切れるような雑音が発生しにくくなることと、点字ディスプレイに詳細読み候補が送信されるときの安定性が改善すると思います。
nishimoto IMEサポートの実装を変更し、IMM系のAPIについては文節選択の処理を追加しました。
このチケットはクローズして、残った不具合は新しいチケットで扱います。
Screen Reader NVDA Japanese
Fork
nvda-japanese-users 655 にて以下のご報告をいただきました。
（引用ここから）
NVDA2012.1j をWindows XPで使っていて、 ２番目の文節変換中に１番目の文節から読み上げてしまう現象がありました。
環境１）NVDA2012.1j＋Windows XP＋Microsoft IME スタンダード2003＋メモ帳
「つぎのきかい」と入力し、スペースキーを押すと、 「次の機会」と表示され、「ツギノ ジ ヒラガナ ノヤマノ ノ キカイノ キ アウノ カイ」と読み上げる。 右矢印キーを押して、２番目の文節に移動してから、スペースキーを押すと、 ２番目の文節だけでなく、１番目の文節から以下のように読み上げる。 「ツギノ ジ ヒラガナ ノヤマノ ノ キカイノ キ キカイノ カイ」
環境２）NVDA2012.1j＋Windows VISTA＋Microsoft Office IME 2010＋メモ帳
環境３）NVDA2012.1j＋Windows 7＋Microsoft IME 10.1＋メモ帳
２番目の文節に移動してから、スペースキーを押すと、 「キカイノ キ キカイノ カイ 候補2」 と読み上げます。
（引用ここまで）
Windows 7 sp1 (x64) + Microsoft IME の環境で再現しました。
IMEからの文節単位の情報取得が不完全なためにこの現象が発生します。今後改善したいと思います。