Ticket #28859

本家inputMethods実装の日本語対応

Open Date: 2012-06-27 18:43 Last Update: 2015-01-08 18:20

Reporter:
Owner:
(None)
Status:
Open
Component:
MileStone:
(None)
Priority:
5 - Medium
Severity:
5 - Medium
Resolution:
None
File:
None

Details

本家の 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 さんにパッチを提案したところ、「中国語の詳細読みテーブルには複数のエントリがある。日本語では必要ない?」と逆に教えていただきました。

台湾チームにこのあたりの動作について教えてもらおうと思って連絡をとったところです。

いずれにせよ、このスピードで開発が進んでいることに驚いています。

Ticket History (3/58 Histories)

2012-06-27 18:43 Updated by: nishimoto
  • New Ticket "本家のinputMethodsブランチ検討" created
2012-06-27 18:46 Updated by: nishimoto
  • Details Updated
2012-06-28 00:16 Updated by: nishimoto
Comment

オフトピックかも知れませんが、詳細読みテーブルの複数エントリについて台湾チームに質問しました。

現在単語のレビュー(テンキー5)で使う、と言われたので、半信半疑でソースを読み直しました。

speech.py の def _speakSpellingGen() の中で、characterProcessing.getCharacterDescription() が返すリストを受け取ったあとの処理です。

  • 入力が1文字の場合:その文字のすべての詳細読みエントリを、読点記号(ユニコード3001)で結合して出力する
  • 入力が2文字以上の場合:その入力を構成するすべての文字について、詳細読みリストの先頭のエントリーを、順番に出力する

ということで、気づかなかったのですが、マルチバイト文字のための「単語単位の詳細読み」が実装されていました。

以下のような調査、検討が必要です:

  • 中国語では単語の区切りはどこで処理しているのか
  • 単語単位の詳細読みレビューを日本語でどう処理するべきか、どう使えるのか
  • 日本語チームで今まで検討してきた「短い詳細読み」「長い詳細読み」の導入とどう整合するのか
  • IMEの候補の詳細読みについて、日本語チームがどのように対応していくか
2012-06-28 10:59 Updated by: nishimoto
Comment

追加の情報をいただきました。

どうやら中国語ユーザーは「現在の単語のレビュー」コマンドを「短い詳細読み(説明が1種類だけ)」として、「現在の文字のレビュー」コマンドを「長い詳細読み(説明を複数並べて提示する)」として使っているようです。

そういわれてみると英語における「現在の単語のレビュー」と「現在の文字のレビュー」と実装に一貫性があるように思われます。

別チケットに移すべきでしょうが、日本からこの機能について何らかのフィードバックが必要かどうか、議論をさせてください。

2012-06-28 22:51 Updated by: nishimoto
Comment

NVDAが単語の区切りはどこで処理しているのか調べました。

以下、inputMethods ブランチにて、ソースを追いかけた手順をキーワードで示すと:

  • source/globalCommands.py script_review_currentWord() -> textInfos.expand(UNIT_WORD)
  • source/textInfos/offsets.py -> _getWordOffsets() -> NVDAHelper.localLib.calculateWordOffsets()
  • nvdaHelper/local/textUtil.cpp -> ScriptItemize(), ScriptBreak(), SCRIPT_LOGATTR fWordStop

たどり着いたのは Uniscribe という Windows API でした。

メモ帳で単語単位のカーソル移動に CTRL-左矢印 CTRL-右矢印 が使えるのですが、どうやら NVDA でレビューカーソルを単語単位で移動したり、現在単語を読み上げる処理も、このメモ帳の挙動と対応しているようです。

日本語については、「句読点だけは直前の文字と繋がってひとつの単語となる。それ以外は1文字が1つの単語となる」ようです。

こ / ん / に / ち / は、 / 今 / 日 / は / 晴 / 天 / で / す。

話を戻すと、仮に中国語繁体字で「文字レビュー」と「単語レビュー」の境界区切りがほとんど同じなのだとしたら、中国語ではこれらの操作が実質的に「長い詳細読み」と「短い詳細読み」の操作として使われている可能性があります。

余談ですが、Firefox のキャレットブラウズや、IE9 のカーソルブラウズで単語単位ジャンプをすると、Uniscribe と違う挙動をします。Firefox は句読点区切りを単位にした移動になり、IE9 では「ひとかたまりのカタカナ文字列」を単語にみなす挙動をします。またワードパッドでは IE9 と同じような挙動になります。

2012-06-29 15:34 Updated by: nishimoto
Comment

本家の inputMethods リビジョン 5236 スナップショットに、アドオン版 JTalk を追加して作ったポータブル環境を zip したものを下記 Dropbox に置きました。

https://dl.dropbox.com/u/62564469/nvda-im5236-jtalk.zip

開発は Windows 7 を対象にしており、Windows XP は「詳細なテキストサービス」をすべてのプログラムに拡張すれば動くのではないか、とされています。

本家が nvda-dev-asia メーリングリストを開設して、西本がメンバーとして登録されました。

いまフィードバックを返すべく検証を進めています。

日本語点字対応をマージした日本語スナップショットにも取り掛かりたいと思います。

今のところ気づいたこと:

  • 動作は安定している。IE で msn の検索キーワード入力においても正しく動く。
  • IME の「日本語変換」「変換停止」に相当するイベントの通知はない。
  • プリエディット文字列の差分は正しく読み上げできている。
  • プリエディット状態から変換キーを押して、最初の候補文字列が表示されるときに、詳細読みにならない。
  • 冗長な通知内容がある(New Candidate List, Primary Candidate List など候補ウィンドウの名前を通知している)
  • 日本語ロケールの修正で歩み寄るべき箇所がある。"ニチ as in ニチヨービノ ニチ" となっている部分は、"as in" のテンプレートをロケールで「の」と翻訳して、詳細読み辞書を「ニチヨービノ ニチ」から「ニチヨービ」のように修正すれば、実装はユニバーサルになる。as in に相当する部分を辞書から取り除くほうがキレイな実装のような気がする。このチケットのいままでのコメントで書いた「複数の詳細候補」は「日本語では使ってない」と答えてしまったが、今後なにかうまい使い方を提案すべきかも。
  • 漢字の詳細読みと、かな文字のフォネティック読みを区別して制御する方法は、もし取り入れてもらうとしたら、新しい仕様を提案する必要がある。
  • nvdajp の実装と同じく、候補文字列らしき音声出力が始まって、直後にいったんキャンセルされて、再び出力される、という現象がときどきある。おそらく TSF と IMM のイベントの重複と思われる。
2012-06-29 17:27 Updated by: nishimoto
Comment

先ほどの本家の inputMethods リビジョン 5236 スナップショット評価の続きです。

Windows 7 sp1 x64 + メモ帳だけですが、以下のとおり補足します。

  • Microsoft IME と Microsoft Office IME 2010 の挙動は基本的に同じ。
  • Google 日本語 IME は、プリエディット、コンポジション、候補、どれも読み上げしない。
  • ATOK 2012 の「テキストサービスを使用しない」モードでは、プリエディット、コンポジション、候補、どれも読み上げしない。
  • ATOK 2012 の「テキストサービスを使用する」モードでは、プリエディットとコンポジションは読み上げる。候補は読み上げない。

Microsoft IME 系において、プリエディットから変換操作を行った状態(コンポジションが出ていて候補ウィンドウが出ていない状態)で、文節が複数あるときに、文節の移動を正しく読み上げていない。

2012-07-03 17:21 Updated by: nishimoto
Comment

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 をフックしているようなので、手を入れるならここがいいかも知れません。

2012-07-11 19:43 Updated by: nishimoto
Comment

本家の inputMethods スナップショットが5237, 5240と更新されました。

5240 のダウンロード http://nvda.sourceforge.net/snapshots/inputMethods/nvda_snapshot_inputMethods-5240.exe

2012-07-11 20:34 Updated by: nishimoto
Comment

inputMethods 5242 のコメントによると、以下の仕様が実装されたようです:

  • 詳細読み辞書でカッコ () で囲まれた用例は「なんとかの なんとか」にようにフォーマットせず、そのまま使う。中国語の詳細読み辞書がすでにそのようになっているため。
2012-07-11 21:42 Updated by: nishimoto
Comment

inputMethods 5242 の評価の依頼がありました。

2012-07-12 23:21 Updated by: nishimoto
Comment

引き続き inputMethods 5245 の評価の依頼がありました。

http://www.nvda-project.org/snapshots/

5245 のダウンロード http://nvda.sourceforge.net/snapshots/inputMethods/nvda_snapshot_inputMethods-5245.exe

読み上げの冗長なところを調整したので、特に Windows 7 で致命的な不具合がないかを確認してほしい、とのことです。

2012-07-13 13:15 Updated by: nishimoto
Comment

inputMethods 5245 に JTalk アドオン(最新版)を追加した「ポータブル版環境」を下記に置きます。

https://dl.dropbox.com/u/62564469/nvda-im5245j-portable.zip

Windows 7 sp1 で確認したところ、以下のような状況です。おおまかに言えば、まだ MSAA と TSF だけが使われていて IMM の実装が取り入れられていないようです。

(1)Microsoft IME と Internet Explorer 9 (MSNの検索ボックス), ワードパッド、メモ帳で確認。

IME ON/OFF は通知されない。

IME が ON のときに、入力が始まると Composeと通知する。

例えば k と押すと「compose ケー」と通知する。

プリエディットでカーソルを左右に移動すると、カーソル位置の1文字を読む。

変換キーを押したとき、最初の候補は詳細読みしない。

コンポジションでカーソルを左右に移動すると、カーソル位置の1文字を読む。

複数文節を変換したときコンポジションで文節選択が移動するが、このときは「クウギョー」と通知される。

Microsoft IME の候補ウィンドウが開いたときには、候補は以下のように通知される。

  • Candidate リスト
  • 日本語 1 日 as in ニチヨービノ ニチ, 本 as in モトノ ホン, 語 as in カタルノ ゴ

Esc を押して変換操作を終了すると Done と通知する。

(2)ATOK 2012

プリエディット文字列はキーエコーされる。候補は文字列をそのまま通知しており、詳細読みではない。

(3)Google 日本語入力

プリエディット文字列をキーエコーしない。候補は通知しない。

(4)ログの確認

ログに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 譌・譛ャ隱槫・蜉・
2012-08-08 17:10 Updated by: nishimoto
Comment

inputMethods 5270 に JTalk アドオン(最新版)を追加した「ポータブル版環境」を下記に置きます。

https://dl.dropbox.com/u/62564469/nvda-im5270j-portable.zip

評価は改めて書きます。

2012-08-08 19:26 Updated by: nishimoto
Comment

さきほど 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.
2012-08-13 19:25 Updated by: nishimoto
Comment

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 との互換性の改善、候補リストのナビゲーション対応などが行なわれています。

2012-08-16 07:58 Updated by: nishimoto
Comment

inputMethods ブランチ 5285 がリリースされました。

インストーラーのURL

http://nvda.sourceforge.net/snapshots/inputMethods/nvda_snapshot_inputMethods-5285.exe

Windows XP での安定性が改善されています。

2012-08-18 09:23 Updated by: nishimoto
Comment

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)に 「候補ウィンドウが開いたときにすべての候補を読み上げる」オプションがついて、 これがデフォルトで有効になりました。 詳細読みをするわけではないので、「1:かわ、2:かわ、3:かわ」のような読み上げになり、 日本語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.
2012-08-21 19:39 Updated by: nishimoto
Comment

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 関連の変更はありません。

2012-08-21 19:44 Updated by: nishimoto
Comment

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
2012-08-21 22:14 Updated by: nishimoto
Comment

起動エラーのほかにも気になる挙動が見つかったので 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.
2012-08-27 18:54 Updated by: nishimoto
Comment

本家の 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 の状況:

  • 本家の不具合で、起動直後にエラー音が出る。
  • 日本語設定「日本語入力対応」が有効:プリエディット文字列など、多くの処理で本家の処理と日本語版の処理が重複している状態
  • 日本語設定「日本語入力対応」が無効:本家の処理だけが有効になり、「変換モードの通知」「変換操作直後の詳細読み」などができない。
2012-08-29 11:15 Updated by: nishimoto
Comment

本家 inputMethods rev 5292 で、日本語の入力モードの読み上げに対応しました。

(コメントによると nvdajp のコードを利用した、とのこと)

確認したところ、「日本語変換」「変換停止」のタイミングでモードを通知する nvdajp の実装ではなく、 Microsoft IME の「入力モード」を切り替えたときに、切り替わったモードを通知する実装になっていました。

マウス操作でしか確認していませんが、日本語キーボードを使えば Ctrl + 変換, N, 上下矢印 で操作したときに読み上げできると思います。

参考:Microsoft IME キー操作一覧 (Microsoft Office IME 2010 の場合)

http://office.microsoft.com/ja-jp/support/HA101864594.aspx

2012-08-29 11:43 Updated by: nishimoto
  • Summary Updated
Comment

本家が inputMethods ブランチを main にマージしました。

nvda/main: Rev 5381: Support for Asian character Input

本チケットの概要「本家のinputMethodsブランチ検討」を「本家inputMethods実装の日本語対応」と改めます。

なお、8月21日に報告した変換候補の最後の1文字が欠落する(「喜び」と変換したときに「び」が欠落する)現象は inputMethods rev 5292 では直っていません。

2012-08-29 12:17 Updated by: nishimoto
Comment

オーストラリアと台湾の関係者に以下をご連絡しました。

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.
2012-08-29 22:02 Updated by: nishimoto
Comment

本家 inputMethods の入力モード読み上げの動作を、日本語キーボードで確認しました。

Windows 7 と Microsoft IME では無変換キーを押すたびに「ひらがな ローマ字」「カタカナ ローマ字」などモードが切り替わって、その切り替わったモードが通知されるようになっていました。

Shift-Ctrl キーで IME の種類や言語を切り替えると、切り替わった IME の名前が読み上げされます。

ちなみに「半角全角キー」については何も通知されません。どうやら中国語にはこれに相当するキー操作はないようです。。

2012-08-30 14:52 Updated by: nishimoto
Comment

以下のコミットで、inputMethods 拡張が jpInputMethods ブランチから nvdajp にマージされました。

lp:nvdajp 4309

「日本語設定」「日本語版の文字入力拡張」がデフォルトで有効になっています。

このとき、本家の拡張の一部の処理が無効になります。

ただし、確定文字列の読み上げについては本家の処理を無効にしていないので、確定文字列は重複して読み上げられています。

「日本語設定」「日本語入力で確定文字列を読み上げる」をチェックなしにすると、本家の確定文字列読み上げだけが有効になります。

いくつかの環境で動作確認をして、どちらの処理を残すか、検討したいと思います。

また、長期的には、本家の「入力メソッド」対応を日本語で快適に使えるように改良していく必要があります。

2012-08-30 16:52 Updated by: nishimoto
Comment

以下のコミットで、「確定文字列の読み上げ」は inputMethods 側の処理を常に利用することにしました。

lp:nvdajp 4313

「日本語設定」「日本語入力で確定文字列を読み上げる」は設定項目そのものを削除しました。

確認したところ inputMethods の確定文字列の読み上げは (Windows XP sp3, Windows 7 sp1) x (notepad, wordpad) x (Microsoft IME, ATOK 2012) のそれぞれの組み合わせについて、不具合なく動いています。

なお、確定文字列の読み上げをオフにしたい、という要望にはこたえることができなくなりました。本家の実装には確定文字列を無効にするオプションがないためです。

こういう要望があった場合は、本家の実装に対するパッチ作成や修正提案をしていく予定です。

2012-08-31 09:53 Updated by: nishimoto
Comment

中国語対応の開発メンバーに下記のようにメールしました。

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.

2012-08-31 11:16 Updated by: nishimoto
Comment

以下のコミットで、日本語版の入力サポートが有効の場合に、inputMethods 実装の変換候補の読み上げをさせないようにしました。

lp:nvdajp 4317

2012-09-01 10:05 Updated by: nishimoto
Comment

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.
2012-09-02 21:05 Updated by: nishimoto
Comment

変換したときに文字が欠落する現象の詳細がちょっとつかめたので、関係者に下記を連絡しました。

Regarding 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)

2012-09-03 00:28 Updated by: nishimoto
Comment

設計上の問題点が見えてきたので 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.

2012-09-03 20:24 Updated by: nishimoto
Comment

jpdev120831 について、以下の報告をいただきました。

本家 inputMethods 拡張の TSF 関連の処理が動いているため、特に Windows XP では TSF の設定の影響を受ける可能性があります。

(1) 例えばワード2003で単語を入力するときに 「あめ」と入力すると、 点字で「よー ワード文書 doc conposition 編集可能 あめ」 ワードパッドでは 「ドキュメント ワードパッド conposition あめ」 と出る。点字表示が遅くなり、読みにくい。

(2) コントロールパネルの地域と言語のオプションから 「複合文字や右から左方向に書く言語(タイ語を含む)のファイルをインストールする」に、チェックをし、 「東アジア言語のファイルをインストールする」にチェックを入れてみました。 これが良かったのか、関係ないのか、よくわかりませんが、とにかく、上記のワードやワードパッドの不具合は直り、以前と同じように点字が表示されるようになりました。

(3) insertキーがNVDAキーとして働かない、という不具合が発生しているが、確実に再現されるわけではないようです。

2012-09-04 10:59 Updated by: nishimoto
Comment

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 さんの発言へのコメントです。

2012-09-05 14:38 Updated by: nishimoto
Comment

本家チケットの指摘ですが inputMethods 拡張の影響で「不必要な通知が多くなった」という問題への対処が行なわれています。

http://www.nvda-project.org/ticket/2639#comment:2

2012-09-05 22:56 Updated by: nishimoto
Comment

ユーザー設定で本家の IMM/TSF サポートを無効化したいのですが、NVDAHelper の初期化の処理を制御することが困難であるため、以下のコミットで完全に無効にしました。

lp:nvdajp 4328

2012-09-06 10:40 Updated by: nishimoto
Comment

レジストリの nvdajp というグループに InputMethodsMode という値を設定し、1以上の値を指定すると、本家の IMM/TSF サポートが有効になるようにしました。

本家の東アジア言語拡張を使うためには、「日本語設定」で日本語入力拡張を無効にして、さらに InputMethodsMode を 1 にして、NVDA 日本語版を再起動してください。

lp:nvdajp 4333

\HKEY_CURRENT_USER\Software\nvdajp -> InputMethodsMode REG_DWORD 0
2012-09-11 01:20 Updated by: nishimoto
Comment

Windows XP sp3 のメモ帳(TSFエミュレーションなし)で lp:nvdajp 4349 をテストして以下の現象を確認しました。

  • 複数のIMEをCTRL+SHIFTで切り替えるとき、通知されるIMEの名前が実際にアクティブなものと1つずれる
  • 候補ウィンドウが表示されて次候補に切り替えるたびに「空行」という余分な音声を読み上げる
2012-09-11 12:12 Updated by: nishimoto
Comment

下記のコミットで「東アジア拡張」を無効化する方法を変更して、コールバックの入口で何もしないでリターンさせるようにしました。

lp:nvdajp 4353

Windows XP sp3 のメモ帳、Word 2003 において、Microsoft IME 2002 および ATOK 2012 の動作が改善されました。

ただし Word 2003 と Microsoft Natural Input 2003 の組み合わせで、候補ウィンドウが開いたときに第一候補を読み上げない、確定したときに「なめらか読み」と1文字ごとの「音訓読み」が連続して起きる、という現象を確認しています。

2012-09-25 11:07 Updated by: nishimoto
Comment

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.

2012-09-28 09:38 Updated by: nishimoto
Comment

チケット2687 に関する提案を nvda-dev-asia 宛に書きました。

http://www.nvda-project.org/ticket/2687

Regarding ticket 2687, I reproduced that the duplications of messages such as

  • Alpha numeric input, IME closed
  • IME opened, Native input

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".

2012-10-03 11:18 Updated by: nishimoto
Comment

チケット2687について本家 main 5514 で対応が行なわれました。

入力ロケール識別子(キーボードレイアウト)が日本語のときだけ IMEOpenStatusUpdate() が使われるように変更されています。

具体的には GetKeyboardLayout() の返す値の下位8ビットが 0x11 かどうかを判定しています。 「実装したものはユニバーサルに動かなくてはならない」という原則の例外ですね。。

私のコメントは採用されませんでしたが、実装が単純な方針が選ばれたということでしょうか。。

日本語の Windows 7 x64 でIMEを日本語、中国語、韓国語などで使い分けてみましたが、問題解決にはなっているようです。

2012-10-06 19:08 Updated by: nishimoto
Comment

ユーザーガイドの翻訳 (本家 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が通知をするかどうかを変更できます。 このオプションは既定値で有効です。

2012-10-12 00:34 Updated by: nishimoto
Comment

本家の 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 までをマージしていますが、本家での日本語入力についての改良は、半角全角キーによるモード切替の通知ができるようになったことだけです。

2012-10-17 19:26 Updated by: nishimoto
Comment

2012.3beta1 が公開されて「東アジア文字入力対応」のことが本家から告知されはじめたので、以下の情報提供が必要になっています。

  • 本家版(および日本語版の InputMethodsMode 1 互換モード)における日本語入力の対応状況
  • 日本語版の日本語入力サポートと本家版の違い

本家版 2012.3beta1 での日本語入力は以下の状況です。

  • 「候補リストの自動通知」のチェックをはずさないと使いにくい
  • 変換操作をした直後に選ばれる第一候補が詳細読みされない
  • 変換候補の末尾のひらがなが通知されない(「川の」が「カワ」と通知される)
  • ATOK で候補が詳細読みされない
  • 候補が複数文節のときに文節移動の操作を読み上げない
  • 詳細読みに冗長な部分がある(「川:かわのせんがわ」)

本家の 2012.3 リリースまでに本家にフィードバックできること、翻訳で対応できることがあるか、検討します。

解決できない問題については、本家のチケットとして登録する必要がありそうです。

日本語チームからの情報提供とあわせて、本家のドキュメントやリリースノートにどのように記載してもらうかも課題です。

2012-10-19 16:25 Updated by: nishimoto
Comment

本家チケット2730を登録しました。

http://www.nvda-project.org/ticket/2730

2012-10-22 19:03 Updated by: nishimoto
Comment

本家版で「詳細読みに冗長な部分がある」(「川:かわのせんがわ」) の問題を解決するためには、中国語と同様に辞書を

(アジアノア)

のようにカッコで囲んで "%s as in %s" のフォーマットが使われないようにする必要があります。

2012-10-24 17:49 Updated by: nishimoto
Comment

以下の作業について説明します。

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

2012-10-31 14:28 Updated by: nishimoto
Comment

本家の韓国語の担当者から東アジア言語における「単語単位の読み上げ」について以下のチケットが上がりました。

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.

2012-11-03 15:22 Updated by: nishimoto
Comment

NVDA 本家 2012.3 系列の最新スナップショットでは「詳細読みに冗長な部分がある」(「川:かわのせん がわ」)にならないように、charcterDescriptions.dic のすべての項目にカッコがついています。

これとは関係なく、カッコを入力して変換すると「記号読み上げレベル」の影響を受けて読んだり読まなかったりする問題があるので、本家チケットに下記を登録しました。

http://www.nvda-project.org/ticket/2776

2012-11-04 23:43 Updated by: nishimoto
2013-02-23 17:01 Updated by: nishimoto
Comment

NVDA日本語版でのIME実装の移行は jpime スナップショット、チケット #30252 で検討しています。

このチケットでは #30252 の作業を本家版にフィードバックすることについて引き続き検討します。

これは本家 2013.1 には間に合いそうにないので、マイルストーンを変更します。

まず「かわの」の第一候補「川の」が「川」しか読まない問題について calculateInsertedChars() 関連の報告をしました。

http://www.nvda-project.org/ticket/2730#comment:1

この他に jpime スナップショットの実装を踏まえて以下の提案を検討します。

  • NVDAObjects/inputComposition.py class InputComposition def reportNewText に関する変更
    • calculateInsertedChars() の返す値が空であっても、直前のキーコードが VK_SPACE または VK_CONVERT のときは newString を通知する
    • newText は文字説明とキーエコーの両方に使える方法で説明読みに変換する
    • newText の通知は音声だけでなく点字でも行う
  • braille.py の def getBrailleTextForProperties の変更
    • name が _("Composition") の場合は name と roleText を通知しない
2013-02-24 01:16 Updated by: nishimoto
Comment

#30252 の作業についてのコメントです。

VK_SPACE または VK_CONVERT が押されたときには calculateInsertedChars() の結果を無視するような実装で問題がないので、calculateInsertedChars() を書き換える必要はないことに気づきました。

それから、文節区切りの変更や文節選択の移動は jpime130224 ではサポートできていません。

C++ の実装に手を入れて(ImmGetCompositionString() を GCS_COMPATTR で実行して)情報をとり出す必要がありそうです。

2013-08-15 09:15 Updated by: nishimoto
2015-01-08 15:30 Updated by: nishimoto
Comment

本家 2730 にコメントがついています:

http://community.nvda-project.org/ticket/2730#comment:2

他の件の影響もあるので、本家版での日本語IMEの不具合について改めて整理するべきか。。

2015-01-08 16:03 Updated by: nishimoto
Comment

私が本家 2730 に書いた説明が不十分だったと思えてきたので、補足説明すべきことを整理してみます。

  • 日本語の文字入力では、複数分節の選択、移動、確定、といった操作が必要。
  • もしも「かわの」を「川の」と変換して、この変換結果が1文節であれば「川」の詳細説明、ひらがな「の」の両方が通知されるべき。
  • もしも「かわの」の変換結果が「川」と「の」の2文節になり、先頭の文節「川」が、現在の操作対象の文節になったとしたら、「川」の詳細説明だけが通知されることは不適切とは言えない。変換を最初に実行した直後は「すべての文節を通知する」「操作対象の文節だけを通知する」の両方の流儀がある。
  • もし変換結果が1文節であるにも関わらず、送り仮名の「の」が変換の前後で変わっていないからという理由で省略されて「川」だけが通知されると、ユーザは「かわの」の変換結果が「川」「の」の2文節になってしまったと誤解してしまう。
  • NVDA 日本語版では 2014.3jp から「変換を最初に実行した直後はすべての文節を通知する」流儀で実装している。
  • 第2候補以降を通知する場合は常に「変換前の仮名文字と一致している文字も含めて、操作対象の文節の全体が通知される」べきである。

関連チケット #34110 複数文節の日本語変換をした直後にすべての文節を通知する仕様の検討

関連することを過去にまとめた日本語と英語の資料:

2015-01-08 18:20 Updated by: nishimoto
Comment

さっき書いたことを英語にして、下記のように書きました。

チケット #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:

  • type A: For the first time of pressing space key, all (including both target and non-target) characters are explained. For second time and later (i.e. choosing alternatives for the target portion), only the target characters are explained.
  • type B: Always only the target characters are explained.

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.

Attachment File List

No attachments

Edit

Please login to add comment to this ticket » Login