点字出力を使うとATOKでMicrosoft Wordに文字入力できない
nishimoto nishimoto ATOK 2013 がリリースされたので、この不具合について再度検証したいと思います。
nishimoto 以下の組み合わせを確認しました。
Microsoft IME ではときどき候補文字、未変換文字、確定文字の通知ができない、Word がクラッシュする、という問題があるようです。
ATOK 2013 ではこのチケットで報告した不具合がやはり起こりました。
もう少し調べてみますが、この問題に特化した対策をするか、本家の inputMethods に完全に移行するか、選択を迫られそうです。
日本語版の文字入力拡張 nvdajpime はキーイベントの低レベルフックを使っているので、将来のソフトウェアキーボードへの対応などを考えると、よりユニバーサルな方法で実装した方がよいという考えもあります。
本家 inputMethods の課題は以下の通りです：
音声出力と点字出力で文字説明の情報を使い分けるべきという提案も検討します。
作業は下記のブランチで進めます：
lp:~nishimotz/nvdajp/ti30252
関連しそうなチケット：
nishimoto nvdajpime の初期化と終了を取り除いて ti30252 rev 4534 としてプッシュしました。
確認したところ ATOK 2013 は TSF に対応しているので Windows 8 + Word 2013 + ATOK 2013 は inputMethods 実装で動きます。
ただし候補リストのウィンドウクラスの違いのためか Microsoft IME のように候補リストが詳細読みされません。
いずれにせよ nvdajpime を直すのではなく inputMethods に必要な改良を加える、という方向でしばらく作業してみます。
nishimoto まだテストコードの段階ですが、ブランチ ti30252 rev 4539 までの作業で ATOK 2013 の候補ウィンドウと辞書ウィンドウ（はてなキーワード電子辞典）が開いたときにビープが鳴るようになりました。
作業環境は Windows 8 64ビットと、メモ帳および Word 2013 です。
Microsoft IME のように MSAA のオブジェクトの子要素をたどれば候補アイテムを取り出せたのですが、ATOK の候補ウィンドウは子要素がないので、別の方法で情報を取り出す必要があります。
他の作業として NVDAHelper/remote/{ime.cpp,tsf.cpp} にログ出力を入れて挙動を追ったのですが Windows 8 と ATOK 2013 の組み合わせでは未確定文字列も候補単語も TSF の OnEndEdit でしか取り出せない状況です。
Microsoft IME と同様に MSAA の Overlay Class で ATOK 候補ウィンドウから候補文字列を取り出して詳細読みを出力できればいいのですが。。
nishimoto ATOK 2013 はテキストサービス(TSF)の有効・無効の切替ができます（Windowsの再起動が必要）。
いままでテキストサービス有効の場合の検証をしていたので、テキストサービス無効での状況を確認したところ、やはり入力文字が重複したり勝手に確定してしまう、という不具合が確認されました。
Word 2013 を起動して、一度 Microsoft IME で変換作業をしてから、ATOK 2013 に切り替えると、ATOK 2013 は正常に読み上げできました。（確実ではありませんが）
ATOK 2013 はテキストサービス有効で使わないと Windows 8 スタート画面やストアアプリに対応できません。
nishimoto ATOK はテキストサービス無効で使っていただく、という前提で ti30252 ブランチの作業を進めました。
スナップショット jpime130221 https://dl.dropbox.com/u/62564469/nvda_snapshot_jpime130221.exe
スペースキーまたは変換キーを押して最初に表示される候補を、ウィンドウが開かなくても詳細読みするようになりました。
実際には NVDA から未変換文字のキーエコーと第一候補を区別できないので、ぜんぶ詳細読みで通知しています。 ただし候補ウィンドウが開いていないときは、「ひらがな」と「英字」だけ文字属性の説明を省略する特別な詳細読みモードを使うようにしました。 ですので、普通のキーエコーと区別がつかないと思います。
また、第一候補がひらがなの場合には文字列の差分で判定ができないため、やむをえずキーフックで仮想キーコードのチェックをしています。
この実装は Windows 8 と Microsoft IME では安定して動いています。
Windows 8 64bit + ATOK 2013 (テキストサービス無効) + Word 2013 （32ビット）+ KGS ドライバー（BM46に接続）では、入力文字が勝手に確定する不具合は起こっていません。ただし、スペースキーを押したときの動作がときどき不確実です。
ti30252 ブランチとしての目的はほぼ達成できたのですが、IME サポートの実装を完全に入れ替えたので、例えば文節区切りの通知ができないなど、デメリットもあります。
また、本家チケット 3005 で .NET アプリケーションでの不具合が指摘されています。（日本語チームでも「やむメール」の本文入力で音声・点字ともに遅延するという報告があります）
http://www.nvda-project.org/ticket/3005
一方で、このブランチに移行することで、再現性の高いクラッシュを防げるようになる可能性もあります。
NVDA日本語チームでは、2013.1jp でこのブランチへの移行をするか、もうしばらく改良を続けるか、議論していただく予定です。
nishimoto スナップショットjpime130222 https://dl.dropbox.com/u/62564469/nvda_snapshot_jpime130222.exe
以下の改良を行いました。
第一候補は独自のウィンドウを持たない情報なので、時間がたつと表示が消えます。 NVDA ではウィンドウに直接対応しない情報は、「メッセージ」という扱いになり、点字ディスプレイに表示し続けることができないためです。 候補ウィンドウが開いたあとの表示はウィンドウのレビューと同じ扱いなので、時間がたっても消えません。
なお、詳細読みの内容を点字ディスプレイに最適化する作業は下記のチケット #30309 で扱います。 http://sourceforge.jp/ticket/browse.php?group_id=4221&tid=30309
ソースコード lp:~nishimotz/nvdajp/ti30252 rev 4552
nishimoto 以下のチケットが本件の作業に関連すると思われます。
チケット #29531 文字説明の点字ディスプレイ出力 http://sourceforge.jp/ticket/browse.php?group_id=4221&tid=29531
チケット #29976 日本語入力の確定結果が点字ディスプレイに表示されない http://sourceforge.jp/ticket/browse.php?group_id=4221&tid=29976
チケット #30310 点字ディスプレイに不要な「無題メモ帳複数行 編集可能」が出力される http://sourceforge.jp/ticket/browse.php?group_id=4221&tid=30310
nishimoto スナップショットjpime130222について以下のご指摘をいただきました。
（１）ワードで入力するときにレビューモードで改行すると、前の列の点字が残る
Windows XP SP3 ワード２０１０での具体的な状況： 「具体的な 状況」を変換、決定して、エンターキーで改行。「ぐたいてきな じょーきょー」と、点字で表示されています。 下の行に移っていて、本来ならカーソルがブリンクしているだけが分かりやすいのですが。
これを回避するために改行して、まだ前行の点字が残っているとき、スペースを1回叩き、左矢印キーでもとにもどると前行の点字は消えて、カーソルブリンクだけになります。 （全行が残っていると、改行ができているのか確認できず不安になります。）
（２）行頭にスペースの空白を入れたときに点字表示で行頭の空白が確認できない
（同じく Windows XP SP3 ワード２０１０での状況） 単語を打って決定し、ホームキーで行頭に戻って、スペースキーを何回か押すと、画面では単語が右に移動していきますが、点字は動きません。 常に点字は左端から始まっているので実際の画面のレイアウトが確認できません。
（３）ATOK で8文字を超える入力のフィードバックがない
Windows7 32bit ATOK 2011でメモ帳で文字入力する際、８文字程度を超えると音声のフィードバックがなくなり、確認できない状態になる。 MS-IMEでは問題ない。
直接（３）と関係あるかわかりませんが NVDAObjects.behaviors.CandidateItem.getFormattedCandidateName に入れたログ出力で、ときどき候補文字列が文字化けしています。
nishimoto 先ほどの（３）ATOK で8文字を超える入力のフィードバックがない に関連しそうなので、以下、補足します。
現在のjpimeの実装では、ATOKで未変換文字が長くなったときに「推測候補」のウィンドウが出ると、 未変換文字と候補文字列が混在してNVDAに届いてしまうため、 うまく動作しない可能性があります。
ATOKプロパティ「入力・変換」「設定項目(Y)」「推測変換」から 「推測候補の自動表示」グループ「自動表示(A)」コンボボックス「しない」 にすることを推奨します。
なお、上記はテキストサービス無効での状況です。
Windows 8とATOK 2013の組み合わせではテキストサービス有効がデフォルトになったようですが、 現状ではATOKをテキストサービス無効にして開発・テストをしています。
nishimoto スナップショットjpime130223 https://dl.dropbox.com/u/62564469/nvda_snapshot_jpime130223.exe
「１えん」「１ぱーせんと」「いよいよほんばん」などを変換して「１円」「１パーセント」「いよいよ本番」などの第一候補が表示されるときに、余分な文字説明をしないように変更しました。
nishimoto スナップショットjpime130223について、以下のご報告をいただいています。
アプリケーションの立ち上げ直後に日本語入力を開始するときの「半角全角キー」に対するフィードバックがない。 もう１度押すと「変換停止」になり、その先は半角全角キーを押してもちゃんと読んでいる。
nishimoto アプリケーション起動直後の半角全角キーが通知されない現象は jpmin130219b (ti30482) でも起きています。
ATOKの推測候補を無視する処理は、下記のような実装を試したのですが、変換キーを押す、スペースで候補選択、エンターで決定、という操作をすると、直後の未変換文字を読まなくなる、という不具合が出ているので、コミットしないでもう少し検討します。
Screen Reader NVDA Japanese
Fork=== modified file 'source/NVDAHelper.py'
--- source/NVDAHelper.py 2013-02-16 08:06:00 +0000
+++ source/NVDAHelper.py 2013-02-25 08:52:34 +0000
@@ -216,6 +216,13 @@
candidateStrings=candidatesString.split('\n')
import speech
from NVDAObjects.inputComposition import InputComposition, CandidateList, CandidateItem
+ #nvdajp begin
+ from NVDAObjects import inputComposition
+ import win32con
+ log.info("lastKeyCode %x" % inputComposition.lastKeyCode)
+ if not inputComposition.lastKeyCode in (win32con.VK_SPACE, win32con.VK_CONVERT):
+ return
+ #nvdajp end
focus=api.getFocusObject()
if not (0<=selectionIndex<len(candidateStrings)):
if isinstance(focus,CandidateItem):
nishimoto 上記の実装に、フォーカスを親オブジェクトに戻す制御を追加したらうまくいったようです。
lp:~nishimotz/nvdajp/ti30252 rev 4556
nishimoto スナップショット jpime130225 https://dl.dropbox.com/u/62564469/nvda_snapshot_jpime130225.exe
ATOKの推測候補が表示されたときに、推測候補の通知をせず、その後も未変換文字がキーエコーされるようにしました。
この実装では、ユーザーがATOKのキー割り当てを変更した場合はうまく動かないと思います。 推測候補かどうか、また、第一候補が表示されたかどうかを判断するために、スペースキーまたは変換キーが押されたかどうかのチェックをしているからです。 もっとよい実装方法を思いついたら改善させてください。
なお、ここまでの作業は本家のC++の実装をまったく変更せず Python のコーディングだけで対応できましたが、 文節移動の通知と、アプリケーション起動直後の半角全角キーの不具合については、Python の処理だけで解決できない可能性があります。
nishimoto スナップショット jpime130227 https://dl.dropbox.com/u/62564469/nvda_snapshot_jpime130227.exe
アプリケーション起動直後に半角全角キーを押したときに IME open の通知をしない不具合を修正しました。
C++ 側で変数の初期値をひとつだけ修正しています。何も悪い影響は出ないと思うのですが、何か別の不具合が出ていたらお知らせください。
nishimoto スナップショット jpime130301 https://dl.dropbox.com/u/62564469/nvda_snapshot_jpime130301.exe
ATOK をテキストサービス無効で使っているときに、変換結果に含まれる複数の文節のうち、選択された文節を詳細読みするようにしました。
まだ開発途上なのでいろいろログ出力をしています。
いまのところ Windows 8 (64bit) + ATOK 2013 + Word 2013 (32bit) でテストしています。
文節移動はShift+左矢印、Shift+右矢印を想定した実装になっています。
nishimoto スナップショット jpime130301 が以下の環境で特に不具合なく動作することを確認しました。
テキストサービス有効の場合は文節選択を通知できませんが、これは従来のNVDA日本語版でも実現できていません。
なお Windows 8 (64bit) + Microsoft Word 2013 (32bit) + Microsoft IME の環境では NVDA 2012.3.1jp よりも jpime130301 のほうが適切に動作します。
なお、設定「入力メソッド設定」の「候補リストの自動通知」をチェックありにすると、候補ウィンドウが開いたときに候補リストの内容をすべて読み上げます。数字キーで候補選択も可能になります。NVDA日本語版ではこの設定のデフォルトを無効にしたいと思います。
いままでの日本語版と仕様が変わった点は以下の通りです。
このふたつはNVDA本家版 2012.3 で、すでにこのように実装されています。 変換モードの通知については、Python 側で動作を変えられるかどうか調べましたが、時間がかかりそうなので保留しています。 本家の実装はキーを押したことに対する通知ではなく、モードが切り替わったというIMEからのイベントに対して通知を行っており C++ 側でイベントを生成しています。
本家版と日本語版の違いを減らしていくことで、独自実装に起因するバグを解決することがこのチケットの趣旨だったこともあり、もうしばらく jpime の動作確認（特に点字出力）、テストの御報告を待って、作業完了とさせていただきます。
具体的には、テスト用のログ出力やビープ音の削除、ドキュメントの更新、jpmain へのマージ（2013.1jp への採用）、このチケットのクローズ、残った作業の別チケット化、を行う予定です。
なお、Windows 7 32bit + Word 2010 + ATOK 2011 の組み合わせで 全角半角 や Alt+全角半角 を押しても漢字変換モードにならない、というご報告をいただいています。 一度 Shift+Ctrl で IME を MS-IME 2010 にして、もう一度 Shift+Ctrl で ATOK 2011 に戻すと Alt+半角全角 は機能するとのことです。 こちらの環境で再現できていないため、このチケットをクローズするときに別途チケット化させていただきます。
nishimoto NVDAと関係ないのですが、アプリケーションの起動直後に半角全角キーでATOKが有効にならず、Shift+CtrlでいったんほかのIMEに切り替えて再びATOKに戻すと有効になる、という現象が下記の環境で起きています。
この現象はNVDAの問題なのか、NVDAとは無関係にATOKとWindowsとアプリケーションの組み合わせで起こる問題なのか、もうすこし情報収集が必要と思います。
nishimoto NVDA日本語版では 2011.3j 以降で「フォーカスの変化を追跡する自動フォーカスモード」のデフォルトを無効にしてきました。 これは日本語IMEサポートの不具合を回避するためです。
チケット #25680 IMEの日本語入力をESCで取り消すとIEのエディットボックスの入力モードも同時に解除される
しかし、実装方法を変えたので、このデフォルトを本家と同じく有効に戻すことを検討したほうがよさそうです。
ブログ記事「NVDA を使っていて文字入力ができないとき」 http://yuuka-k.blog.so-net.ne.jp/2013-02-20
nishimoto lp:~nishimotz/nvdajp/ti30252 rev 4544 を jpmain にマージしました。
前回のスナップショットからの更新は以下の通りです。
なお、開発に使っている環境で、アプリケーションの起動直後に半角全角キーでATOKが有効にならず、Shift+CtrlでいったんほかのIMEに切り替えて再びATOKに戻すと有効になる、という現象が、メモ帳や Microsoft Word でも起こることに気づきました。
いままでの nvdajpime のコードは無効になっていますが、まだ削除されずに残っている部分があります。
今後は jpdev スナップショットでテストを続けますが、このチケットはもうしばらく未完了のまま作業します。
nishimoto 本件は完了として、ATOK関連の不具合は別のチケットで検討します。
NVDA 2012.3.1jp リリース候補版 + Windows xp sp3 + Microsoft Word 2003 + ATOK 2012 + KGS 点字ディスプレイで、入力文字が重複したり勝手に確定してしまう、という不具合が確認されました。
Word 2010 および ATOK 2011 の組み合わせでも同様の不具合が報告されています。
点字出力を「なし」にするとこの問題は発生しません。また、Microsoft IME を使うことでこの問題を回避できます。
なお NVDA日本語版の文字入力サポートを無効にして、本家版の東アジア言語文字入力を有効にすると、この問題が起こらないことを確認しています。
NVDA日本語版の説明から、以下、引用します。
4.6.10. 日本語版の文字入力拡張 「日本語版の文字入力拡張(NVDAの再起動が必要)」は初期状態でチェックありになっています。 無効にするにはこの設定をチェックなしにしてNVDAを起動しなおしてください。 なお NVDA 2012.3 の「東アジア言語文字入力」の処理の一部は NVDA 日本語版の処理で置きかえられています。 本家の処理を有効にするには、レジストリエディターで下記の値に 1 を設定してください。 キーの名前 \HKEY_CURRENT_USER\Software\nvdajp 値の名前 InputMethodsMode 値のタイプ DWORDこの問題への対応は 2013.1 以降の日本語版で行います。ご了承ください。