コントローラークライアントAPIの拡張
nishimoto nishimoto NVDAHelper.py の nvdaController_speakText(text) で文字列に get_short_desc() を適用する（１文字だけの出力には音訓読み辞書を使う） nvdajp 独自の修正の経緯を確認しました。
手順：Emacs で vc-annotate したら 39行のリビジョンが 4165.1.53 と判明したので、下記で確認。
bzr log -r4165.1.53 ------------------------------------------------------------ revno: 4165.1.53 tags: nvdahiro110808 committer: Takuya Nishimoto <nishimotz@gmail.com> branch nick: jp2011.2 timestamp: Mon 2011-08-08 22:11:05 +0900 message: IME key echo of symbols for 64bit applications (nvdajp ticket 25032)
チケット25032 全角文字を入力時に読んでほしい（2011.2jで完了）
64ビットのアプリケーションで「日本語変換」有効の状態でプリエディット（変換前）文字列が追加されたとき、キーエコーのために speakText の RPC 呼び出しを使っています。 （これは nvdajp の実装に限定した話で、 nvda-dev-asia は別のやりかたをしていると思います）
従来の speakText では記号などの読み上げが確実ではない（記号読み上げレベルの影響を受ける）という理由で、speakText の仕様を「１文字だけの文字列が送られたときには、音訓読み辞書を使って読み上げる」という仕様に変更しました。
ただ、その後 nvdajp_keyEvents 関連は大幅に書き換えたので、この処理は不要になった可能性があります。
nvdajp の speakText 独自仕様は、日本語以外の動作環境を考慮していないので、本家版の仕様に戻しても問題ないかどうか、検討してみます。
あわせて、もしかすると、コントローラークライアントから文字を「詳細読み」で読ませる機能と「音訓読み」で読ませる機能と、両方あったほうがよいのかも知れない、という気がしてきたので、コメントさせていただく次第です。
日本語の「音訓読み」は、音声設定においてNVDAが「スペル読み」と呼んでいる機能に近いので、その場合は speakSpelling という名前は音訓読みのAPIにふさわしい名前かも知れません。
nishimoto 以下のコミットで日本語版独自の speakText の拡張を削除しました。
lp:nvdajp rev 4302
Windows 7 sp1 x64 + メモ帳およびワードパッド、Microsoft IME および ATOK 2012 を使い、記号読み上げ「なし」の状態でプリエディット文字列の句読点「テン」「マル」が適切にキーエコーされることを確認しています。
言い換えると、日本語入力サポートのために RPC に音訓読みAPIを導入する必要はなくなったので、今回の speakSpelling 拡張はこのままでもよいと思います。
nishimoto コントローラクライアントの開発者用ファイルは下記のとおりですが、
http://sourceforge.jp/projects/nvdajp/wiki/ControllerClient
日本語版で拡張した speakSpelling を追加した DLL は
で作成する必要があります。
いちおう以下の Python コードで「カタカナ ひらがな」をピッチを変えて出力できていることは確認しました。
# coding: utf-8 import time import ctypes DLLPATH = 'c:/work/nvda/jpmain/nvdaHelper/build/x86/client/nvdaControllerClient32.dll' clientLib=ctypes.windll.LoadLibrary(DLLPATH) res=clientLib.nvdaController_testIfRunning() if res!=0: errorMessage=str(ctypes.WinError(res)) ctypes.windll.user32.MessageBoxW(0,u"Error: %s"%errorMessage,u"Error communicating with NVDA",0) for count in xrange(4): clientLib.nvdaController_speakSpelling(u"カタカナ ひらがな") time.sleep(5)
nishimoto Michael Curran さんにこの件を話したところ、複数の SDK が存在するのは好ましくないので、パッチを本家にフィードバックして欲しい、というコメントをいただきました。
nishimoto コントローラークライアントの暫定アーカイブ nvdajp-client-121030.7z をこのチケットの添付ファイルにしました。
http://sourceforge.jp/ticket/download.php?group_id=4221&tid=29342&file_id=4853
拡張子 .7z は 7-zip で展開できるアーカイブファイルです。
簡易なプログラムから NVDA に短い（８文字程度の）テキストを送っても、プログラムの言語によってはそれを NVDA が読み上げないようです。 今回、その現象を確認した言語は、HSP です。 ちなみに、全く同じ文字列でも PCTKUSR.dllでは読み上げています。
nishimoto ご報告ありがとうございます。
できるだけ同じ状況を作って再現したいので、テストした環境（NVDAとHSPのバージョン）、テストプログラム（できるだけコンパクトにしたもの）をご提供いただけますか？
HSP は下記から HSP 3.31 をダウンロードすればよいでしょうか？
http://hsp.tv/idman/download.html
なお、詳細読みAPIの拡張は 2012.2.1jp では実装されていないので、2012.3jp-beta3 をお使いください。
環境は NVDA バージョンが 2012.3jp-beta3 で、HSP のバージョンが 3.31 です。 テストプログラムなど一式を添付していますので、よろしくお願い致します。
HSP 3.31のフルセット版は、http://hsp.tv/idman/download.html からダウンロードしてインストールをする必要があります。（テスト環境もフルセット版です。）
HSP 3.31でテストされ、もしプログラムの改良によってきちんと読み上げるようでしたらわたしのプログラムに誤りであると考えられます。 改良したソースコードなど見せて頂けますと幸いです。
nishimoto 本件、まだ作業に取りかかれていません。
Dropbox で共有していただいたファイルを添付しようとするとエラーになったので、添付ファイルの容量かセキュリティの制約かも知れません。
この作業にご協力いただけるかたで、Dropbox の nvdajpTeam に参加しておられないかたは西本宛にご連絡ください。
nishimoto コントローラークライアントのAPIを追加していただきました。
ブランチ newClient のレポジトリ：
lp:~misono/nvdajp/newClient
テストケース：
lp:~misono/nvdajp/testCase
確認できたら jpmain にマージする予定です。
なお、このチケットで過去に議論された HSP に関する問題は未解決です。
nishimoto 新しいクライアント開発キットのアーカイブ nvdajp-client-130223.zip をこのチケットの添付ファイルとして公開しました。
ソースは lp:~misono/nvdajp/newClient lp:~misono/nvdajp/testCase で、それぞれ client および python ディレクトリに収められています。
オリジナルは 7z ですが、zip に変更しました。
マイルストーンを 2013.1jp に設定するにあたり、残った課題はドキュメントの作成・加筆です。
このチケットが完了したら、本家に対するパッチを作って提出したいと思います。
nishimoto ほとんどサンプルプログラムのコピーペーストで申し訳ないですが、日本語版のAPI拡張についての英語のドキュメントを下記に作りました。
http://sourceforge.jp/projects/nvdajp/wiki/ControllerClientEnhancement
このチケットはクローズします。
Screen Reader NVDA Japanese
Fork
コントローラークライアントに詳細読みAPIを追加するパッチをマージしました。
lp:~misono/nvdajp/nvdajp 4297..4301 を lp:nvdajp 4299 としてマージして 4300 でコメントだけ西本が修正しました。