nishimoto nishimoto nishimoto オフトピックかも知れませんが、詳細読みテーブルの複数エントリについて台湾チームに質問しました。
現在単語のレビュー（テンキー５）で使う、と言われたので、半信半疑でソースを読み直しました。
speech.py の def _speakSpellingGen() の中で、characterProcessing.getCharacterDescription() が返すリストを受け取ったあとの処理です。
ということで、気づかなかったのですが、マルチバイト文字のための「単語単位の詳細読み」が実装されていました。
以下のような調査、検討が必要です：
nishimoto 追加の情報をいただきました。
どうやら中国語ユーザーは「現在の単語のレビュー」コマンドを「短い詳細読み（説明が１種類だけ）」として、「現在の文字のレビュー」コマンドを「長い詳細読み（説明を複数並べて提示する）」として使っているようです。
そういわれてみると英語における「現在の単語のレビュー」と「現在の文字のレビュー」と実装に一貫性があるように思われます。
別チケットに移すべきでしょうが、日本からこの機能について何らかのフィードバックが必要かどうか、議論をさせてください。
nishimoto NVDAが単語の区切りはどこで処理しているのか調べました。
以下、inputMethods ブランチにて、ソースを追いかけた手順をキーワードで示すと：
たどり着いたのは Uniscribe という Windows API でした。
メモ帳で単語単位のカーソル移動に CTRL-左矢印 CTRL-右矢印 が使えるのですが、どうやら NVDA でレビューカーソルを単語単位で移動したり、現在単語を読み上げる処理も、このメモ帳の挙動と対応しているようです。
日本語については、「句読点だけは直前の文字と繋がってひとつの単語となる。それ以外は１文字が１つの単語となる」ようです。
こ / ん / に / ち / は、 / 今 / 日 / は / 晴 / 天 / で / す。
話を戻すと、仮に中国語繁体字で「文字レビュー」と「単語レビュー」の境界区切りがほとんど同じなのだとしたら、中国語ではこれらの操作が実質的に「長い詳細読み」と「短い詳細読み」の操作として使われている可能性があります。
余談ですが、Firefox のキャレットブラウズや、IE9 のカーソルブラウズで単語単位ジャンプをすると、Uniscribe と違う挙動をします。Firefox は句読点区切りを単位にした移動になり、IE9 では「ひとかたまりのカタカナ文字列」を単語にみなす挙動をします。またワードパッドでは IE9 と同じような挙動になります。
nishimoto 本家の inputMethods リビジョン 5236 スナップショットに、アドオン版 JTalk を追加して作ったポータブル環境を zip したものを下記 Dropbox に置きました。
https://dl.dropbox.com/u/62564469/nvda-im5236-jtalk.zip
開発は Windows 7 を対象にしており、Windows XP は「詳細なテキストサービス」をすべてのプログラムに拡張すれば動くのではないか、とされています。
本家が nvda-dev-asia メーリングリストを開設して、西本がメンバーとして登録されました。
いまフィードバックを返すべく検証を進めています。
日本語点字対応をマージした日本語スナップショットにも取り掛かりたいと思います。
今のところ気づいたこと：
nishimoto 先ほどの本家の inputMethods リビジョン 5236 スナップショット評価の続きです。
Windows 7 sp1 x64 + メモ帳だけですが、以下のとおり補足します。
Microsoft IME 系において、プリエディットから変換操作を行った状態（コンポジションが出ていて候補ウィンドウが出ていない状態）で、文節が複数あるときに、文節の移動を正しく読み上げていない。
nishimoto nvda-dev-asia にて Sogou Pinyin が動かないという報告がありました。
中国語（簡体字）圏で広く使われているIMEのようです。
http://en.wikipedia.org/wiki/Sogou_Pinyin
日本語 Windows にむりやり入れてみましたが、やはり IMM32 で情報を取る必要がありそうで、jpdev120625 はある程度読み上げました。
一方で inputMethods ブランチが IMM32 サポートを追加するにはどうしたらいいか、すこし眺めてみました。
SetWindowsHookEx() で WH_GETMESSAGE をフックして、 WM_IME_COMPOSITION メッセージが来るタイミングで ImmGetCompositionString() を呼ぶようにすれば、jpdev120625 と同じ実装になります。
すでに nvdaHelper/remote/typedCharacter.cpp で WH_GETMESSAGE をフックしているようなので、手を入れるならここがいいかも知れません。
nishimoto 本家の inputMethods スナップショットが5237, 5240と更新されました。
5240 のダウンロード http://nvda.sourceforge.net/snapshots/inputMethods/nvda_snapshot_inputMethods-5240.exe
nishimoto inputMethods 5242 のコメントによると、以下の仕様が実装されたようです：
nishimoto inputMethods 5242 の評価の依頼がありました。
nishimoto 引き続き inputMethods 5245 の評価の依頼がありました。
http://www.nvda-project.org/snapshots/
5245 のダウンロード http://nvda.sourceforge.net/snapshots/inputMethods/nvda_snapshot_inputMethods-5245.exe
読み上げの冗長なところを調整したので、特に Windows 7 で致命的な不具合がないかを確認してほしい、とのことです。
nishimoto inputMethods 5245 に JTalk アドオン（最新版）を追加した「ポータブル版環境」を下記に置きます。
https://dl.dropbox.com/u/62564469/nvda-im5245j-portable.zip
Windows 7 sp1 で確認したところ、以下のような状況です。おおまかに言えば、まだ MSAA と TSF だけが使われていて IMM の実装が取り入れられていないようです。
（１）Microsoft IME と Internet Explorer 9 （MSNの検索ボックス）, ワードパッド、メモ帳で確認。
IME ON/OFF は通知されない。
IME が ON のときに、入力が始まると Composeと通知する。
例えば k と押すと「compose ケー」と通知する。
プリエディットでカーソルを左右に移動すると、カーソル位置の１文字を読む。
変換キーを押したとき、最初の候補は詳細読みしない。
コンポジションでカーソルを左右に移動すると、カーソル位置の１文字を読む。
複数文節を変換したときコンポジションで文節選択が移動するが、このときは「クウギョー」と通知される。
Microsoft IME の候補ウィンドウが開いたときには、候補は以下のように通知される。
Esc を押して変換操作を終了すると Done と通知する。
（２）ATOK 2012
プリエディット文字列はキーエコーされる。候補は文字列をそのまま通知しており、詳細読みではない。
（３）Google 日本語入力
プリエディット文字列をキーエコーしない。候補は通知しない。
（４）ログの確認
ログにIMEが切り替わったタイミングで inputLangChange のイベントが記録される。
「Google 日本語入力」という IME の名前がマルチバイトであるためか、エラーになっている。
stdout に出力されているというワーニングがでている。
WARNING - stdout (12:29:53): inputLangChange: layoutString Microsoft IME WARNING - stdout (12:29:53): already input method name WARNING - stdout (12:34:41): inputLangChange: layoutString ATOK 2012 WARNING - stdout (12:34:41): already input method name WARNING - stdout (12:36:53): inputLangChange: layoutString E0220411 WARNING - stdout (12:36:53): stringCode E0220411, input method name Google 譌･譛ｬ隱槫・蜉・
nishimoto inputMethods 5270 に JTalk アドオン（最新版）を追加した「ポータブル版環境」を下記に置きます。
https://dl.dropbox.com/u/62564469/nvda-im5270j-portable.zip
評価は改めて書きます。
nishimoto さきほど nvda-dev-asia に Windows XP での動作確認の結果を投稿しました。
以下、英語のままでご容赦ください。
Operating system: Japanese Windows XP Pro SP3. Both TSF emuration and TSF extention options are disabled. Input methods: Microsoft IME Standard 2002 Ver 8.1 (IMEJP81) ATOK 2012 by Just System Corp. (ATOK25W) (ATOK is a commercial product. It is popular among the screen reader users in Japan, because it makes fewer conversion errors. The default setting of ATOK is used.) Applications: Wordpad, Notepad, Internet Explorer 8. NVDA: portable inputMethods 5270 with JTalk add-on 120713 http://en.sourceforge.jp/projects/nvdajp/releases/56419/note Keyboard: US layout. Braille display: none. (1) ALT-tilde (IME enable/disable toggles) are not reported. (2) With Notepad and Microsoft IME, all of the operations are reported. example (typed character, followed by the reported message): k: ke e a: ka w: da bu ryu a: wa space: ka wa space: candidate list "ka wa" two "ka wa" as in "ka wa no hi" enter: ka wa ka wa comments: In example as above, "ka wa" was converted to "皮" (skin). "ka wa" can also be converted to "川" (river). The last message "ka wa ka wa" should be once. At the first press of space key, converted string is shown in-line. At the second press of space key, candidate list window is shown and second item is selected. At the press of enter key, candidate window closes. Most of Japanese screen reader uses character discriptions at the first press of space key, not only for candidate windows. The message at the second press of space key should be translated. In this case, the description has the duplication, so we should add parentheses to avoid it. (3) With Wordpad and Microsoft IME, some messages are duplicated, and the second press of space key produces wrong message. example (typed character, followed by the reported message): k: ke e ke e a: ka w: ka da bu ryu a: wa space: ka wa space: candidate list "ka wa" one sentakunashi "ka wa" as in "ka wa no se n" enter: (nothing reported) comments: At the second press of space key, candidate list window is shown and second item is selected, however, first item (which is not selected) is repored. In the message avobe, "sentakunashi" is "not selected" in Japanese. (4) With Internet Explorer 8 and Microsoft IME, search box of bing.com or MSN Japan gives worse experience. http://www.bing.com/ http://jp.msn.com/?ocid=iehp With IME enabled, the press of alphabet keys occurs duplication of reports frequently. Sometimes the content of the web site is reporeted, instead of the key itself. (5) With Wordpad or Notepad and ATOK 2012, sometimes the duplications of reports occurs. Correct item within candidate list is reported. When the candidate window is open, the press of enter key reports nothing. Evaluation on Windows 7 is not finished.
nishimoto inputMethods ブランチ 5278 がリリースされました。
インストーラーのURL http://nvda.sourceforge.net/snapshots/inputMethods/nvda_snapshot_inputMethods-5278.exe
JTalk アドオンを組み込んだポータブル版 zip ファイル https://dl.dropbox.com/u/62564469/nvda-im5278j-portable.zip
中国語の Chang Jie IME との互換性の改善、候補リストのナビゲーション対応などが行なわれています。
nishimoto inputMethods ブランチ 5285 がリリースされました。
インストーラーのURL
http://nvda.sourceforge.net/snapshots/inputMethods/nvda_snapshot_inputMethods-5285.exe
Windows XP での安定性が改善されています。
nishimoto inputMethods ブランチ 5287 がリリースされました。
インストーラーのURL
http://nvda.sourceforge.net/snapshots/inputMethods/nvda_snapshot_inputMethods-5287.exe
例によって JTalk アドオンを組み込んだもの
https://dl.dropbox.com/u/62564469/nvda-im5287j-portable.zip
新しく追加された入力コンポジション設定(Input Composition Settings)に 「候補ウィンドウが開いたときにすべての候補を読み上げる」オプションがついて、 これがデフォルトで有効になりました。 詳細読みをするわけではないので、「１：かわ、２：かわ、３：かわ」のような読み上げになり、 日本語IMEでは有用ではありません。
もうひとつ、 「変換前の文字列の変化を通知する」(report changes to the reading string) というオプションがあり、これもデフォルトで有効です。 これがどんな効果を持つのか、引き続き調査します。
気になることをもうひとつ挙げると、Windows XP のメモ帳（TSFエミュレーションなし）で、 Microsoft IME プリエディットの読み上げが動かなくなったようです。 （もういちどテストしてから報告したいと思います）
さきほど、最初の件だけ、後述のメールを台湾チームに送りました。
いずれにせよ、オプションが増えたので、 日本語環境におけるテストは以前よりも手間がかかるものになりつつあります。
I started to evaluate input methods 5287 on Windows XP sp3. Option "Automatically report all available candidates" is not useful for Japanese environment, because all items are reported as same pronunciation with current implementation.
nishimoto inputMethods ブランチ 5288 がリリースされました。
インストーラーのURL
http://nvda.sourceforge.net/snapshots/inputMethods/nvda_snapshot_inputMethods-5288.exe
ポータブル環境に JTalk アドオンを組み込んで zip アーカイブしたもの
https://dl.dropbox.com/u/62564469/nvda-im5288j-portable.zip
5287 からの変更は main ブランチをマージしたことだけで、 IME 関連の変更はありません。
nishimoto Windows 7 sp1 x64 で inputMethods 5288 ポータブル版を起動すると直後にエラー音が出ます。
ログを見ると下記のエラーが出ています。
ERROR - unhandled exception (19:42:36): Traceback (most recent call last): File "_ctypes/callbacks.c", line 314, in 'calling callback function' File "NVDAHelper.pyc", line 229, in nvdaControllerInternal_inputLangChangeNotify AttributeError: 'NoneType' object has no attribute 'sleepMode' INFO - core.main (19:42:37): NVDA initialized INFO - config.save (19:42:38): Configuration saved WARNING - stdout (19:42:41): inputLangChange: layoutString Microsoft IME WARNING - stdout (19:42:41): already input method name
nishimoto 起動エラーのほかにも気になる挙動が見つかったので nvda-dev-asia に下記を投稿しました。
Operating systems: (a) Japanese Windows XP sp3. Both TSF emulation and TSF extension options are disabled. (b) Japanese Windows XP sp3. TSF emulation enabled. (c) Japanese Windows 7 sp1 x64. Input method: Microsoft IME. NVDA: portable inputMethods 5288 with JTalk add-on 120713 http://en.sourceforge.jp/projects/nvdajp/releases/56419/note Input Composition Settings: Auto Report option is disabled in all cases. Keyboard: US layout. Braille display: none. Issue 1: At the launch of NVDA, an error occurs as follows: (begin quote) ERROR - unhandled exception (19:42:36): Traceback (most recent call last): File "_ctypes/callbacks.c", line 314, in 'calling callback function' File "NVDAHelper.pyc", line 229, in nvdaControllerInternal_inputLangChangeNotify AttributeError: 'NoneType' object has no attribute 'sleepMode' INFO - core.main (19:42:37): NVDA initialized INFO - config.save (19:42:38): Configuration saved WARNING - stdout (19:42:41): inputLangChange: layoutString Microsoft IME WARNING - stdout (19:42:41): already input method name (end quote) It does not occur with (a) Windows XP sp3 TSF emulation disabled. It occurs with (b) Windows XP sp3 TSF emulation enabled, and (c) Windows 7 sp1 x64. Issue 2: Within (a) Japanese Windows XP sp3 TSF emulation disabled, Notepad does not report pre-edit strings of input method at all, even if "Report changes to the reading string" option is enabled. Issue 3: Within all versions of Windows (except the case of issue 2), the string is not reported correctly in some cases. If the last character of pre-edit string is not Kanji but Kana (Hiragana) character, the last character is dropped at the first translation operation (pressing space key) and cancellation of the translation (pressing escape key). Example: yorokobi (joy in Japanese) is first shown as four Kana characters: よ ろ こ び then translated into a Kanji character and a Kana character: 喜 び typed character or key, followed by the reported message: y o r o k o b i : Y yo R ro K ko B bi (よろこび) space: ki (喜) escape: yoroko (よろこ) Note: In both cases, the last Kana character (bi び) is missing. The Kanji character is pronounced incorrectly because the following character is missing. This can be confirmed using speech viewer. The displayed characters are not dropped.
nishimoto 本家の inputMethods ブランチが 2012.3 にマージされそうなので、一連の作業を nvdajp と共存させるための準備を始めます。
lp:~nishimotz/nvdajp/jpInputMethods
日本語版のベースは jpdev120827 (nvdajp 5307) で、本家のベースは inputMethods 5289 です。
まずは「本家のIMEサポート」と「NVDA日本語版のIMEサポート」を切り替えられるようにして、つぎに、それぞれのよい部分を取捨選択したいと思います。
現在は source/NVDAObjects/IAccessible/init.py:408 に本家の mscandui の無効化だけを追加しています。
jpInputMethods 5290 の状況：
nishimoto 本家 inputMethods rev 5292 で、日本語の入力モードの読み上げに対応しました。
（コメントによると nvdajp のコードを利用した、とのこと）
確認したところ、「日本語変換」「変換停止」のタイミングでモードを通知する nvdajp の実装ではなく、 Microsoft IME の「入力モード」を切り替えたときに、切り替わったモードを通知する実装になっていました。
マウス操作でしか確認していませんが、日本語キーボードを使えば Ctrl + 変換, N, 上下矢印 で操作したときに読み上げできると思います。
参考：Microsoft IME キー操作一覧 (Microsoft Office IME 2010 の場合）
nishimoto 本家が inputMethods ブランチを main にマージしました。
nvda/main: Rev 5381: Support for Asian character Input
本チケットの概要「本家のinputMethodsブランチ検討」を「本家inputMethods実装の日本語対応」と改めます。
なお、8月21日に報告した変換候補の最後の１文字が欠落する（「喜び」と変換したときに「び」が欠落する）現象は inputMethods rev 5292 では直っていません。
nishimoto オーストラリアと台湾の関係者に以下をご連絡しました。
I just tested the InputMethods 5292 with JTalk addon. I confirmed as follows: 1. The startup error problem is resolved. 2. Regarding my reports on rev 5288 last week, dropping of last Hiragana character still occurs. 3. Reporting Japanese input mode (inputMethods Rev 5292) works when the input mode is changed. Tested with Windows 7 and Microsoft IME Japanese. However, the requested functionality in Japan is to report the current input mode, without switching it. 4. As inputMethods enhancement is merged into main branch, NVDA Japanese team may release our localization in which the user can switch the enhancement of main branch and Japanese implementation of IME support we have been developed, as a interim solution.
nishimoto 本家 inputMethods の入力モード読み上げの動作を、日本語キーボードで確認しました。
Windows 7 と Microsoft IME では無変換キーを押すたびに「ひらがな ローマ字」「カタカナ ローマ字」などモードが切り替わって、その切り替わったモードが通知されるようになっていました。
Shift-Ctrl キーで IME の種類や言語を切り替えると、切り替わった IME の名前が読み上げされます。
ちなみに「半角全角キー」については何も通知されません。どうやら中国語にはこれに相当するキー操作はないようです。。
nishimoto 以下のコミットで、inputMethods 拡張が jpInputMethods ブランチから nvdajp にマージされました。
lp:nvdajp 4309
「日本語設定」「日本語版の文字入力拡張」がデフォルトで有効になっています。
このとき、本家の拡張の一部の処理が無効になります。
ただし、確定文字列の読み上げについては本家の処理を無効にしていないので、確定文字列は重複して読み上げられています。
「日本語設定」「日本語入力で確定文字列を読み上げる」をチェックなしにすると、本家の確定文字列読み上げだけが有効になります。
いくつかの環境で動作確認をして、どちらの処理を残すか、検討したいと思います。
また、長期的には、本家の「入力メソッド」対応を日本語で快適に使えるように改良していく必要があります。
nishimoto 以下のコミットで、「確定文字列の読み上げ」は inputMethods 側の処理を常に利用することにしました。
lp:nvdajp 4313
「日本語設定」「日本語入力で確定文字列を読み上げる」は設定項目そのものを削除しました。
確認したところ inputMethods の確定文字列の読み上げは (Windows XP sp3, Windows 7 sp1) x (notepad, wordpad) x (Microsoft IME, ATOK 2012) のそれぞれの組み合わせについて、不具合なく動いています。
なお、確定文字列の読み上げをオフにしたい、という要望にはこたえることができなくなりました。本家の実装には確定文字列を無効にするオプションがないためです。
こういう要望があった場合は、本家の実装に対するパッチ作成や修正提案をしていく予定です。
nishimoto 中国語対応の開発メンバーに下記のようにメールしました。
Japanese team is developing 2012.3jp, which includes both inputMethods enhancement and JP enhancement. JP enhancement is not only input method support, but also includes Japanese speech and braille support, character review functions, and so on.
As I have been tested so far, inputMethods enhancement is better, regarding application compatibility. I will make effort to improve inputMethods enhancement rather than maintaining JP input support. However we can not throw away our input support code right now.
One thing I should mention is that NVDA should have some sort of 'writing system settings' or 'language dependent configurations', other than input composition settings. We are developing a feature that the user can configure how to report the difference of scripts, such as half shape, full shape, Hiragana, Katakana, and so on. This is similar to the uppercase character notifications, however there are too many configurable items for voice setting dialog.
It must be also mentioned that NVDAJP should turn off the 'auto report candidates' checkbox as default, becauce this is writing system dependent.
nishimoto 以下のコミットで、日本語版の入力サポートが有効の場合に、inputMethods 実装の変換候補の読み上げをさせないようにしました。
lp:nvdajp 4317
nishimoto inputMethods が main にマージされて、私が書いたコードの一部が翻訳対象になりました。
翻訳チームで 'hiragana' の説明を求められたので下記のメールを書きました。
As already explained, some messages are from inputMethods work. 'hiragana' and 'katakana' are the names of script types for Japanese writing system. Japanese language has four types of scripts: Latin alphabet, hiragana, katakana, and Kanji. Last one is similar to Hanzi in Chinese and Hanja in Korean. Kanji has thousands of characters, so Japanese input method can transliterate typed Latin characters into hiragana or katakana, followed by the selection of candidates which contain Kanji characters. Other messages found in latest file, such as 'hiragana roman' and 'katakana roman', show the combination of script name and transliteration mode for Japanese input. 'katakana roman' shows typed Latin characters are converted into Japanese 'katakana' characters on-the-fly. At the present, inputMethods enhancement does not work correctly with Japanese environment, so I am trying to fix it.
nishimoto 変換したときに文字が欠落する現象の詳細がちょっとつかめたので、関係者に下記を連絡しました。
スクリーンリーダーNVDA日本語版
ForkRegarding the problem I have been reporting, I am wondering the
calculatedInsertedChars() in inputComposition.py is working correctly
with Japanese translation usages.
Here I use Latin characters for explanation.
if the reading string is "ABCDEFG" and translated string is "ABCXYZG",
reported string should be "ABCXYZG" considering the naturalness of
Japanese translation mannar.
However, the calculatedInsertedChars() returns "XYZ", so the
announcement is insufficient for this case.
Related code and logs are as follows:
(quote 1: added message for this test)
C:\work\nvda\jpmain>bzr diff
=== modified file 'source/NVDAObjects/inputComposition.py'
--- source/NVDAObjects/inputComposition.py 2012-08-31 01:44:41 +0000
+++ source/NVDAObjects/inputComposition.py 2012-09-02 07:00:03 +0000
@@ -9,6 +9,7 @@
from textInfos.offsets import OffsetsTextInfo
def calculateInsertedChars(oldComp,newComp):
+ print "oldComp %s newComp %s"%(oldComp,newComp)
oldLen=len(oldComp)
newLen=len(newComp)
minLen=min(oldLen,newLen)
@@ -28,6 +29,7 @@
diffEnd=newLen+backIndex
diffEnd=max(diffEnd,diffStart+(newLen-oldLen))
print "diffStart %d, diffEnd %d"%(diffStart,diffEnd)
+ print "calculateInsertedChars %s" % newComp[diffStart:diffEnd]
return newComp[diffStart:diffEnd]
class InputCompositionTextInfo(OffsetsTextInfo):
(end of quote 1)
(quote 2: log file, with Japanese characters are replaced to the Laten
characters)
WARNING - stdout (16:07:26):
oldComp ABCDEFGHJLMN newComp ABXEFYIZL
WARNING - stdout (16:07:26):
oldLen 12, newLen 9, minLen 9
WARNING - stdout (16:07:26):
checking start: index 0, new A, old A
WARNING - stdout (16:07:26):
checking start: index 1, new I, old I
WARNING - stdout (16:07:26):
checking start: index 2, new X, old C
WARNING - stdout (16:07:26):
checking end: index 9, backIndex -1, new L, old L
WARNING - stdout (16:07:26):
checking end: index 8, backIndex -2, new Z, old K
WARNING - stdout (16:07:26):
diffStart 2, diffEnd 8
WARNING - stdout (16:07:26):
calculateInsertedChars XEFYIZ
(end of quote 2)
(quote 3: original log file)
WARNING - stdout (16:07:26):
oldComp あのおおきなかわのながれ newComp あの大きな川の流れ
WARNING - stdout (16:07:26):
oldLen 12, newLen 9, minLen 9
WARNING - stdout (16:07:26):
checking start: index 0, new あ, old あ
WARNING - stdout (16:07:26):
checking start: index 1, new の, old の
WARNING - stdout (16:07:26):
checking start: index 2, new 大, old お
WARNING - stdout (16:07:26):
checking end: index 9, backIndex -1, new れ, old れ
WARNING - stdout (16:07:26):
checking end: index 8, backIndex -2, new 流, old が
WARNING - stdout (16:07:26):
diffStart 2, diffEnd 8
WARNING - stdout (16:07:26):
calculateInsertedChars 大きな川の流
(end of quote 3)
nishimoto 設計上の問題点が見えてきたので nvda-dev-asia に下記を投稿しました。
(1)
I think a message should be translated as follows.
=== modified file 'source/NVDAObjects/IAccessible/mscandui.py'
--- source/NVDAObjects/IAccessible/mscandui.py 2012-08-16 01:05:05 +0000
+++ source/NVDAObjects/IAccessible/mscandui.py 2012-09-02 14:56:46 +0000
@@ -47,7 +47,7 @@
return super(BaseCandidateItem,self).name
word=super(BaseCandidateItem,self).name
# Translators: the formatted name of an input
composition candidate item.
- return u"{number} {word}".format(number=number,word=word)
+ return _("{number} {word}").format(number=number,word=word)
def _get_description(self):
return
self.getSymbolDescriptions(super(BaseCandidateItem,self).name)
(2)
Regarding the problem I am reporting since August 21th, I would like
to give some information.
I first thought calculatedInsertedChars() in inputComposition.py is doubtful.
Now I believe it is the matter of requirement definitions.
I wrote to translation list last night that Input methods have state
transition model as follows:
(1) initial state
(2) editing reading string (on the spot)
(3) candidate selection (composition window)
Basically it is true, however, regarding Japanese input methods, the
third state should be separated as follows:
(2) editing reading string (on the spot), before translation key pressed
(3a) composition string (on the spot), after translation key pressed
(3b) candidate selection (candidate window pop up), translation key
pressed twice
Current implementation uses
nvdaControllerInternal_inputCompositionUpdate() to report changes at
both state 2 and 3a.
However, to report changes of Japanese reading string correctly,
calculateInsertedChars() should be used only at state 2, and
behavior.CandidateItem.getSymbolDescriptions() should be used at both
state 3a and state 3b.
nishimoto jpdev120831 について、以下の報告をいただきました。
本家 inputMethods 拡張の TSF 関連の処理が動いているため、特に Windows XP では TSF の設定の影響を受ける可能性があります。
（１） 例えばワード２００３で単語を入力するときに 「あめ」と入力すると、 点字で「よー ワード文書 doc conposition 編集可能 あめ」 ワードパッドでは 「ドキュメント ワードパッド conposition あめ」 と出る。点字表示が遅くなり、読みにくい。
（２） コントロールパネルの地域と言語のオプションから 「複合文字や右から左方向に書く言語（タイ語を含む）のファイルをインストールする」に、チェックをし、 「東アジア言語のファイルをインストールする」にチェックを入れてみました。 これが良かったのか、関係ないのか、よくわかりませんが、とにかく、上記のワードやワードパッドの不具合は直り、以前と同じように点字が表示されるようになりました。
（３） insertキーがNVDAキーとして働かない、という不具合が発生しているが、確実に再現されるわけではないようです。
nishimoto jpdev120831 の公開を中止しました。
本家の翻訳MLに下記を投稿しました。
1.
Regarding "{number} {word}" message, Japanese translation of this should be "{word}", i.e. the number should not be announced.
This is because people who cannot see the display only use arrow keys and enter key to select the candidate of Japanese language.
I understand it is not good solution for people who sometimes want to use Japanese and sometimes Chinese.
Other than message translation, its behavior should be configured depending on languages.
2.
Regarding Joseph's comment, I agree that the announcement of input composition should be different depending on the input method currently used.
For example, automatic candidate report is enabled by default, however, it should not be enabled for some cases including all of Japanese input methods.
後半は韓国語チーム Joseph さんの発言へのコメントです。
nishimoto 本家チケットの指摘ですが inputMethods 拡張の影響で「不必要な通知が多くなった」という問題への対処が行なわれています。
nishimoto ユーザー設定で本家の IMM/TSF サポートを無効化したいのですが、NVDAHelper の初期化の処理を制御することが困難であるため、以下のコミットで完全に無効にしました。
lp:nvdajp 4328
nishimoto レジストリの nvdajp というグループに InputMethodsMode という値を設定し、1以上の値を指定すると、本家の IMM/TSF サポートが有効になるようにしました。
本家の東アジア言語拡張を使うためには、「日本語設定」で日本語入力拡張を無効にして、さらに InputMethodsMode を 1 にして、NVDA 日本語版を再起動してください。
lp:nvdajp 4333
\HKEY_CURRENT_USER\Software\nvdajp -> InputMethodsMode REG_DWORD 0
nishimoto Windows XP sp3 のメモ帳（TSFエミュレーションなし）で lp:nvdajp 4349 をテストして以下の現象を確認しました。
nishimoto 下記のコミットで「東アジア拡張」を無効化する方法を変更して、コールバックの入口で何もしないでリターンさせるようにしました。
lp:nvdajp 4353
Windows XP sp3 のメモ帳、Word 2003 において、Microsoft IME 2002 および ATOK 2012 の動作が改善されました。
ただし Word 2003 と Microsoft Natural Input 2003 の組み合わせで、候補ウィンドウが開いたときに第一候補を読み上げない、確定したときに「なめらか読み」と１文字ごとの「音訓読み」が連続して起きる、という現象を確認しています。
nishimoto NVDA 本家 main 5480 で、日本語IMEのやりかたでオン、オフを行なったときに（英語キーボードでは ALT チルダ）"IME opened" "IME closed" と通知するようになりました。
現状では翻訳は（日本語であることを想定できないので「日本語変換」ではなく）「文字変換」「変換停止」としています。
本家のこのバージョンでは（東京での台湾チームとの議論および韓国語チームの要望などを踏まえて）いくつかオプションが追加されました。
残念ながら「日本語チームが取り組んできた日本語入力対応」に相当する機能は、オプションをどう組み合わせても現状では実現できません。
これに関して Michael Curran さんは下記のように nvda-asia-dev でコメントをしており、各国語向けの派生版でカスタマイズされることを容認する立場になっています。
In the future it may be possible to save settings for each input method, though I'm not sure yet if this is even possible. For now the goal is to make sure that everything is configurable so that it is possible to configure NVDA to be the most efficient with various input methods. This means that Local organizations or distributors may wish to work out what settings are suitable for what input methods and provide this information to the local users.
nishimoto チケット2687 に関する提案を nvda-dev-asia 宛に書きました。
http://www.nvda-project.org/ticket/2687
Regarding ticket 2687, I reproduced that the duplications of messages such as
for Korean Microsoft IME (with Alt-Shift key to switching language) and Chinese New ChangJie (with Shift key for switching half-shape and full-shape).
However, for Japanese input methods, IMEOpenStatusUpdate(), which is introduced by rev 5479, can not be ignored.
Is it possible to treat IMEOpenStatusUpdate() callback to report the input mode such as "Alpha numeric input" or "Native input", rather than just reporting "IME opened" or "IME closed"?
I mean that notification will be duplicated for some systems including Korean input and Chinese New ChangJie adobe mentioned, message filtering procedure to avoid the duplication is also necessary.
I believe it will be also useful for Japanese input method users, because notification of input mode is more useful than just the notification of "IME opened".
nishimoto チケット2687について本家 main 5514 で対応が行なわれました。
入力ロケール識別子（キーボードレイアウト）が日本語のときだけ IMEOpenStatusUpdate() が使われるように変更されています。
具体的には GetKeyboardLayout() の返す値の下位８ビットが 0x11 かどうかを判定しています。 「実装したものはユニバーサルに動かなくてはならない」という原則の例外ですね。。
私のコメントは採用されませんでしたが、実装が単純な方針が選ばれたということでしょうか。。
日本語の Windows 7 x64 でIMEを日本語、中国語、韓国語などで使い分けてみましたが、問題解決にはなっているようです。
nishimoto ユーザーガイドの翻訳 (本家 main 5477 まで) を行なったので、共有します。
「コンポジション」「プレコンポジション」の訳語を検討したのですが、正確に訳語を使い分けることが難しいので、カタカナ表記に改めました。
reading string には「読み文字」という訳語を当てています。
これらの訳語にあわせてNVDAメニューの翻訳も更新しました。
なおNVDA日本語版は現在のところ、ユーザーガイドで説明されている本家の東アジア言語拡張ではなく、nvdajp 独自の日本語入力サポートを使っています。
+++ 入力メソッド設定 +++
設定メニューから入力メソッド設定のダイアログを開くことができます。 これは IME またはテキストサービスに対応したアジア言語の文字入力を NVDA が通知するための設定です。 入力メソッドは種類によって対応している機能や通知する情報が違います。入力メソッドごとに最適な使い勝手にするために、この設定を変更する必要があることをご理解ください。
このオプションは既定値で有効です。候補リストが表示されたり更新されたりしたときに、全ての候補を読み上げる機能です。 これは漢字の字形要素を使う中国語入力システム(New ChangJie, Boshiami)で有用です。すべての候補文字を音声で確認し、数字キーで選択できるからです。 しかし発音を使う中国語入力システム(New Phonetic)では、このオプションは無効にしたほうがよいでしょう。なぜなら全ての文字が同じように読み上げられてしまうからです。このような場合は、候補を矢印キーで選択して、詳細説明を聞いてください。
このオプションは既定値で有効です。NVDAが変換候補を通知するタイミングを、候補リストが表示されたとき、または、候補が選択されたときの、どちらにするかを変更できます。 この設定は、矢印キーで候補選択をする入力メソッド(中国語 New Phoneticなど)では有効にしてください。しかし、入力メソッドによっては、この設定を無効にしたほうが効率的に入力できます。 このオプションが無効のときにも、レビューカーソルは選択された候補の位置にあるので、オブジェクトナビゲーションやレビューの操作によって、選択中の候補や前後の候補を確認できます。
このオプションは既定値で有効です。NVDAが候補の通知で各文字の説明を使うかどうかを変更できます。これは、候補が選択された場合と、候補リストが表示されて自動的に通知される場合の両方についての設定です。 ただし、中国語などの言語では、このオプションとは無関係に、候補の通知で複数の用例を使う文字説明が使われます。 このオプションは韓国語や日本語の入力メソッドにおいて役立ちます。
入力メソッドによっては読み文字(プレコンポジション文字)が存在します。例えば中国語の New Phonetic や New ChangJie などです。 このオプションは NVDA が読み文字の入力を通知するかどうかを制御します。 このオプションは既定値で有効です。 中国語の ChangJie など旧式の入力メソッドでは、プレコンポジション文字を管理するために、読み文字を使わず、コンポジション領域を使います。コンポジションの通知の設定については次の項目を参照してください。
多くの入力メソッドでは、読み文字やプレコンポジション文字から変換された表意文字を、一時的にコンポジション領域に追加し、それから文書に挿入します。 このオプションはコンポジションに追加された文字をNVDAが通知をするかどうかを変更できます。 このオプションは既定値で有効です。
nishimoto 本家の IMM/TSF サポートが有効になる互換モード（lp:nvdajp 4333 で導入）の動作の不具合を lp:nvdajp 4372 で修正しました。
具体的には、Microsoft IME の候補の読み上げで「候補2」の部分をさらに詳細読みしようとする問題が発生していました。
本家の東アジア言語拡張を使うためには、「日本語設定」で日本語入力拡張を無効にして、さらに regedit で InputMethodsMode を 1 にして、NVDA 日本語版を再起動してください。
\HKEY_CURRENT_USER\Software\nvdajp -> InputMethodsMode REG_DWORD 1
なお、本家 main 5537 までをマージしていますが、本家での日本語入力についての改良は、半角全角キーによるモード切替の通知ができるようになったことだけです。
nishimoto 2012.3beta1 が公開されて「東アジア文字入力対応」のことが本家から告知されはじめたので、以下の情報提供が必要になっています。
本家版 2012.3beta1 での日本語入力は以下の状況です。
本家の 2012.3 リリースまでに本家にフィードバックできること、翻訳で対応できることがあるか、検討します。
解決できない問題については、本家のチケットとして登録する必要がありそうです。
日本語チームからの情報提供とあわせて、本家のドキュメントやリリースノートにどのように記載してもらうかも課題です。
nishimoto 本家チケット2730を登録しました。
nishimoto 本家版で「詳細読みに冗長な部分がある」（「川：かわのせんがわ」） の問題を解決するためには、中国語と同様に辞書を
のようにカッコで囲んで "%s as in %s" のフォーマットが使われないようにする必要があります。
nishimoto 以下の作業について説明します。
lp:~nvdajp/nvdajp/jp2012.3 rev 5601
jptools ディレクトリは JTalk 関連ファイルのうち、直接 NVDA の実行時に使わないツールを移動させたものです。
updateCharDesc.py は新しく #29872 で導入した symbols.dic から従来形式の characterDescriptions.dic を生成するツールです。
本家の文字説明辞書の仕様にあわせて、すべての説明を () で囲んでいます。
NVDA日本語版でなくても実用的に使えるように、カタカナと半角は区別がつくようにしています。
また、今後の管理を容易にするために、Unicode の文字コードでソートされています。
このツールで作成したファイルは本家翻訳チーム Subversion の changeset 5904 でコミットされました。
https://www.assembla.com/code/screenReaderTranslations/subversion/changesets/5904
nishimoto 本家の韓国語の担当者から東アジア言語における「単語単位の読み上げ」について以下のチケットが上がりました。
http://www.nvda-project.org/ticket/2754
この件で以前調べていたことを nvda-dev-asia に下記のように報告しました。
Regarding Japanese language, Uniscribe-based word boundary detection seems not working properly.
Ctrl-left or right within Notepad, which seems to use uniscribe, moves caret by one character, with only exceptions of punctuation symbols. Every ideographic character of Japanese language is treated as a word.
Microsoft Word, Internet Explorer, and Mozilla Firefox use their own algorithms for detecting word boundary for Japanese language.
Wordpad treats adjacent phonetic (kana) characters as a word.
Firefox uses punctuation symbols as the boundaries of word (or phrase).
Microsoft Word detects words of Japanese language as linguistic definitions. It seems to have dictionary and text processing engine for this purpose.
Currently, there are no request regarding word review from Japanese language users, because the function itself is unfamiliar to us.
nishimoto NVDA 本家 2012.3 系列の最新スナップショットでは「詳細読みに冗長な部分がある」（「川：かわのせん がわ」）にならないように、charcterDescriptions.dic のすべての項目にカッコがついています。
これとは関係なく、カッコを入力して変換すると「記号読み上げレベル」の影響を受けて読んだり読まなかったりする問題があるので、本家チケットに下記を登録しました。
nishimoto nishimoto NVDA日本語版でのIME実装の移行は jpime スナップショット、チケット #30252 で検討しています。
このチケットでは #30252 の作業を本家版にフィードバックすることについて引き続き検討します。
これは本家 2013.1 には間に合いそうにないので、マイルストーンを変更します。
まず「かわの」の第一候補「川の」が「川」しか読まない問題について calculateInsertedChars() 関連の報告をしました。
http://www.nvda-project.org/ticket/2730#comment:1
この他に jpime スナップショットの実装を踏まえて以下の提案を検討します。
nishimoto #30252 の作業についてのコメントです。
VK_SPACE または VK_CONVERT が押されたときには calculateInsertedChars() の結果を無視するような実装で問題がないので、calculateInsertedChars() を書き換える必要はないことに気づきました。
それから、文節区切りの変更や文節選択の移動は jpime130224 ではサポートできていません。
C++ の実装に手を入れて（ImmGetCompositionString() を GCS_COMPATTR で実行して）情報をとり出す必要がありそうです。
nishimoto nishimoto 本家 2730 にコメントがついています：
http://community.nvda-project.org/ticket/2730#comment:2
他の件の影響もあるので、本家版での日本語IMEの不具合について改めて整理するべきか。。
nishimoto 私が本家 2730 に書いた説明が不十分だったと思えてきたので、補足説明すべきことを整理してみます。
関連チケット #34110 複数文節の日本語変換をした直後にすべての文節を通知する仕様の検討
関連することを過去にまとめた日本語と英語の資料：
nishimoto さっき書いたことを英語にして、下記のように書きました。
チケット #31358 日本語入力(TSF)で文節ごとの候補の読み上げ の成果も含めて本家にフィードバックしないといけないですね。。
At the time of previous writing, I didn't explain the consecutive clause conversion of Japanese input method.
Technically, we should obtain information regarding TF_DA_ATTR_INFO (for TSF) or GCS_COMPATTR (for IMM32) from Japanese input method editor.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms629063%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/cc195099.aspx
Just after pressing space key and first candidate appears, the results may differ depending on the configurations or previous usage of the system.
If all the characters are 'target_converted' characters (we also say that characters are converted as single clause), the user want to hear the explanations for all of the characters as the feedback of conversion.
If some characters are 'target_converted' and other characters are just 'converted' (we say that characters are converted as multiple clauses), the user should know what portion is 'target' (or 'selected'), because we must use left/right arrow keys to choose the 'target' portion and press space key to select alternatives for the target portion.
In Japan, implementations regarding this differs among screen readers:
Anyway, it is not just the matter of string comparisons. If the last portion of characters are omitted just because they are same as input characters, the user may misunderstand as the result is separated into multiple clauses and only the first portion is marked as 'target clause'.
NVDA-JP has been worked around GCS_COMPATTR and we added TF_DA_ATTR_INFO support since 2014.3jp, so we should contribute regarding this.
本家の inputMethods ブランチが動き出しました。
http://bzr.nvaccess.org/nvda/inputMethods
リビジョン 5232 では、MSAA で候補リストのウィンドウから情報を取得する処理が実装され、 NVDAJP のコードからアイディアを借りつつ大幅に書き直した、 日本語IMEではテストしてないけど動くのではないか、 とコメントされています。
日本語IMEは "primary candidate list, list （選択中の単語） 画像 2 （選択候補文字の詳細読み）" のように候補を読むことが確認できました。
Windows XP sp3 と MS IME 2002 はワードパッドで候補を読み上げました。メモ帳で候補を読み上げるためには「詳細なテキストサービス」をすべてのプログラムに拡張する設定が必要でした。
リビジョン 5233 では TSF と IMM がサポートされ、プリエディット文字列の読み上げが動きました。いまのところ Windows 7 x64 上で、32ビットの AsstEd, Word 2010 および 64ビットのメモ帳、ワードパッドのすべてが動いています。文字列の差分がちゃんと取れています。
候補の文節移動の読み上げはまだ不完全です。
また、日本語に固有の問題として、候補が2文字以上のときに詳細読みをしない、という不具合があります。
これは MSAA などで取得する候補文字列を文字に分解せずに詳細読みテーブルを探索しているためで、おそらく中国語はこの仕様でよいのでしょうが。。
これについて mick さんにパッチを提案したところ、「中国語の詳細読みテーブルには複数のエントリがある。日本語では必要ない？」と逆に教えていただきました。
台湾チームにこのあたりの動作について教えてもらおうと思って連絡をとったところです。
いずれにせよ、このスピードで開発が進んでいることに驚いています。