[nvdajp-team 1078] NVDA日本語チームSkype会議 2013年1月7日 報告

Takuya Nishimoto nishi****@gmail*****
2013年 1月 8日 (火) 12:51:01 JST


西本です。

NVDA日本語チームSkype会議 2013年1月7日(月曜) 報告
開始:20時30分
終了:23時45分
参加者:9人(参加した役員:西本、高地)

主な議論

(1)点訳エンジンの開発方針
日本の情報処理点字はメールアドレスとWebサイトのURL以外で使うべきでない。
ユーザーによる点訳モードの切替を実装できるか?
日本の点字利用者にほとんど使われていない英語2級点字をサポートする必要があるのか?
日本点字表記法(175ページ)の算数記号は数学の書籍に限られる。説明なしに理解は困難。

(2)1バイト記号の点訳に関する仕様検討
文字コード(16進)21から29までを具体的に検討してみた。
以下、右端はNVDAにおけるコード表記案(1月7日の議論の結果)

21	!	日本点字	235
22	"	日本SR点字(?)	56-356(?)
23	#	日本SR点字	56-146
24	$	日本SR点字	56-1456
25	%	日本SR点字	56-1234
26	&	日本SR点字	56-12346
27	'	日本SR点字	3
28	(	日本点字	2356
29	)	日本点字	2356

「日本SR点字」は日本のスクリーンリーダーが独自に作っている仕様の一部である。
書籍点訳の規則から逸脱した規則を使うことはやむをえないのではないか?

書籍点訳用のために作られた日本点字や情報処理点字に正しく準拠すると、
たとえばドル記号は 6-236-1456-6-356 のように点字体系切り替えを前後で行う必要があり、
実用的ではない。

このような議論でNVDAの点訳エンジンの仕様を完成させることができるのか?

(3)「点訳のてびき」に基づく点訳エンジン仕様の具体化
「NVDA点字表示の誤り」というファイル名で行っていただいてるDropbox共同作業について。
事例を増やすのであれば、点訳のてびき(第3版)の規則番号と対応付けて、
規則全体のうち、どの範囲がカバーできているかを確認できるとよい?

(4)開発活動のバランスについて
点訳エンジンの開発の詳細にこだわりすぎているのではないか?
文字入力の実装を改善する作業のほうを優先すべきではないか?
他の日本語点訳エンジンのプロジェクトと協力できないか?
日本語チームの仕事を減らしていく工夫が必要。
妥協の目安として「読めればよい」?どの程度なのか?

(5)KGSディスプレイドライバについて
NVDA 日本語版は DirectBM.dll だけを同梱している。
日本のスクリーンリーダーの多くは KBDC.exe も同梱しているので、
BMユーティリティをインストールしていなくても点字ディスプレイを使える。

(6)どのレベルの人をNVDA日本語版のユーザーとして想定するか
日本の現状ではNVDAはセカンド・スクリーンリーダー?
日本の点字ユーザーの読み取り能力の幅が大きい。
情報処理に関して学ぶ人は人手で点訳された書籍を読まざるを得ない。
オープンソースソフトを使える(自分でカスタマイズできる)人が当面の対象?
初めてスクリーンリーダーに触れる人、こどもに使えるスクリーンリーダー?

(7)コントローラークライアントの拡張
現在読み上げ中かどうかをアプリケーションから取得できる拡張を実装した。
音声ドライバの修正が必要。
今後、音声の種類やピッチの制御なども検討。

(8)翻訳および日本語チームの活動全体について
メッセージカタログの翻訳はなんとか追いついているが、ドキュメントの翻訳は遅れている。
役員会を開いて今後の運営を話し合うべき?
日本語チームに参加してもらえそうな人に個別に連絡を取る?
募金など、日本語チームの活動費用を得る方法?

(9)その他の話題
wxPython の参考書。そのほかのオープンソースの話題。
西本は月末にATIAに行く予定。
次回は1月14日(月曜)の夜に開催する。

--
Takuya Nishimoto




nvdajp-team メーリングリストの案内