nishimotzの日記

月: 2015年3月

  • すごい広島 95 と NVDA 日本語版のソースコード管理

    すごい広島 95 に参加してきました。
    事前に呼びかけてみたら、NVDAユーザ会広島の関係者が、私を含めて3人集まりました。
    やること宣言した作業は NVDA 日本語版の点訳エンジンに関する下記の検討でした。
    日本語点訳で (日) と (火) の区別がつかない
    NVDA 日本語版のソースコードは Git で管理されています。
    また、NVDA 日本語版に含まれている日本語点訳エンジンにはテストコードが用意されており、なにか修正をしたときに、いままでうまくいっていた点訳の事例を壊さないように作業をしています。
    テスト駆動開発の理念を尊重して作業しています。
    いわゆる「デグレード」を避けるべき理由はいろいろあるでしょうが、不具合が増えてしまうと、それを嫌って「古いバージョンをわざわざ使う人」が増えてしまいます。
    NVDA 本家版はそのようなことがないように努力しているのがわかるので、日本語版もそうしたいと思います。
    私がこの日にやった作業は以下のような感じでした。

    • 点訳エンジンのテストを実行して、既存のテストケースでエラーが出ていないことを確認
    • 報告があった「不具合の事例」をテストケースに追加
    • 追加されたテストケースで、テストを実行して、そこだけが新しいエラーになることを確認

    本当はエラーが出ているのでコミットするべきではないですが、作業手順の説明とバックアップのためにコミットされました。
    帰宅して数日のうちにもうひとつのコミットを行い、この時点でエラーの数は0に戻りました。
    作業はチケットに対応するトピックブランチ ti34973 で行い、作業が完了してから master にマージされました。
    この作業をしたレポジトリは通称 miscDepsJp と呼んでいるもので nvdajpmiscdep という名前で管理されています。
    この miscDepsJp レポジトリは nvdajp 本体のレポジトリから submodule として参照されています。
    NVDA 日本語版の実行ファイルをビルドすることなく、miscDepsJp のソースだけで点訳エンジンの開発と単体テストが可能になっています。
    修正の中身をすこし詳しく説明しておきます。
    日本語点訳において（日）（火）などの曜日表記が、読み付与が間違っているためにどちらも「ヒ」になっていて、区別がつかない。
    このような事例だけでも個別対応をして修正できないか、というのがいただいた要望でした。
    日本語点訳の読み付与は Open JTalk の処理系に合わせて MeCab で行っています。
    一般的には「日」や「火」という文字が出てくるたびにすべてを「ニチ」「カ」のように変換してしまうわけにはいかず、本来は文脈に応じた処理を行う必要があります。
    もし文脈に応じた処理をしないと、たぶん既存のテストケースのどこかが壊れてしまうでしょう。。
    今回はメーリングリストでいただいたアイディアを参考に、「（日）」のように「前後にカッコ、カッコとじがついている場合」だけ特別な対応をするという方針で作業をしてみましたが、実際には「記号」「一般名詞」「記号」という3つの形態素として処理されるべきなので、MeCab の辞書登録に加えて形態素解析結果の後処理で正規化（形態素の分割）を行って、なんとかつじつまを合わせています。
    MeCab の辞書に単語を追加したので JTalk の読み上げにも影響が及ぶのですが、今回の作業の結果 JTalk の読み上げで「（日）」「（火）」は「ヒ」「ヒ」のままになっています。
    音声読み上げについては音声合成に送られる前に句読点記号辞書が適用されるので、音声エンジンが受け取る前に「カッコ 日 カッコトジ」「カッコ 火 カッコトジ」のような文字列になってしまいます。
    なので「（火）」のような単語を MeCab 辞書に追加しても、点訳エンジンに対してしか効果はありません。
    以上、やった作業の簡単な報告でした。
    NVDA 日本語チームのメーリングリストにおいて、日本語テキスト解析に関する開発には多くのひとが興味をお持ちのようなので、この部分に特化した開発をしていただくために、ソース、ドキュメント、ツールなどを整理したいと思っています。
    複雑な作業であることにはかわりないので「誰でも開発に参加できるようになる」と期待されるとつらいですが。。
    なお NVDA 日本語版のソースコード管理システムを github にまとめる作業を進めているところです。
    ソースを github にコミットすると点訳エンジンのテストを自動実行する、いわゆる「継続的インテグレーション」などもやりたいと思っています。

  • Michael Curran さん来日対応の報告

    2月28日から3月2日にかけて、NV Access 代表の Michael Curran さんの来日をサポートしてきました。
    20150302095241写真は3月1日に行った打ち合わせの様子です。奥の方、写真では真ん中に座っているのが Mick さん。多くのかたにご参加、ご協力いただきました。
    最終日に日本財団で行われた打ち合わせや講演会には私は同席しませんでしたが、その他のスケジュールで話し合ったことや聞いたことを、簡単にまとめます。
    （１）NVDA本家版における日本語対応の課題
    文字入力：

    • IMEから「文字アトリビュート」を取得する必要がある。
    • 現在はNVDA日本語版では inputCompositionUpdate で「変換中の文字列」「タブコード」「文字属性を’0′, ‘1’, ‘2’ のように表した文字列」を送るように C++ 側を拡張している。IMM32 と TSF それぞれ実装が必要で、TSF 側を実装したのは日本語版で 2014.3jp 以降。
    • ユーザーから見ると範囲（選択中のかな文字、選択中の文節）という概念になるが、実際には特定の属性の場所をスキャンすることで「範囲」を取得する。
    • 「はいりそうです」という入力を「入りそうです」「はい理想です」のように文節の区切り方を変えたり、注目する文節を切り替えたりしながら変換する例。
    • 最初にスペースキーが押されたときに、「はい理想です」という候補は（選択されている第一文節の）「はい」だけを通知するか、「はい」「理想です」の全体を通知するか。選択範囲が常に通知されるべきというNVDA全体の仕様からは、前者がよい？だが日本語版は現在は後者の実装になった。最初のスペースキーを押したときに妥当な結果が得られている可能性は高いので、文節の区切られ方よりも全体の文字説明を知ることのほうが効率的であるため、という考察。もしかすると「はい理想です」全体の詳細説明に続いて「はい」が選択中であることを通知するのがよいのでは。。
    • 入力コンポジション設定の「読み文字の通知」は「エイチ」「ハ」「イ」「アール」「リ」のようなローマ字入力のキーエコーを制御するべきではないか。現在はキーボード設定の「入力文字の読み上げ」で制御している。
    • Enter と Esc は日本語入力中とそれ以外の場合でまったく違う役割を持つので、この2つのキー入力の結果を分かりやすくする必要がある。現在の日本語版では IME の確定でない場合のEnterは「改行」と通知できる。また IME 作業中のEscは「クリア」と通知する。
    • 日本語版では、いくつかの処理のためにキー入力フックに手を入れて直前の状態を取得している。なるべくIMEからAPIで取得した情報（文字アトリビュート）を前提とした実装に置き換えるべき。

    文字説明：

    • レビューカーソルやキャレットの左右移動で常に文字説明を行う「説明モード」はアジア言語圏の開発者が本家版に取り入れつつある。特定の言語で自動的に有効になる、という実装の見込み。
    • 日本語版では文字説明のときに「カタカナのピッチを下げる」「半角文字のピッチを上げる」という実装を追加している。
    • 辞書候補アイテムについては、特別な通知方法が必要。「カタカナ シ」「カタカナ オ」を「カタカナ シオ」のようにまとめる。iOS の VoiceOver でもこういう実装はすでにできている。
    • フォネティック読みや半角全角などの文字の種類を通知したい場合とそうでない場合がある。UnicodeData のような国際化の枠組みを使うと一般化できそう。

    点字ディスプレイと日本語点字：

    • 日本のケージーエス社の点字ディスプレイを紹介。
    • BT接続なら追加でドライバーをインストールする必要はない。
    • NVDA用のドライバは本家版へのアドオンとして提供できる
    • メンテナーがいれば本家版に統合は可能
    • liblouis での日本語対応が困難であることについて。
    • 逆変換でドットからかな文字への変換には曖昧性はないはず。これができれば、点字ディスプレイからの文字入力はできるのでは。
    • 点字出力にフォーカスモードとレビューモードがある。フォーカスモードは出力が冗長で使いにくいという意見が日本にある。
    • NVDA コアでの数式(MathML)サポートが進んでいる。これにより、点字を適切に仮想バッファで処理する枠組みが整備される見込み。
    • 仮想バッファが点字を適切に処理できないため、点字メッセージ出力を使ったアプリや処理が必要。例えば仮名漢字変換候補を点字に出力するために「メッセージ表示待ち時間」を無効化するオプションを日本語版につけている。「待ち時間を負の値にする」という仕様なら本家版に取り入れられるかも知れない。
    • 日本語に通常の6点点字、漢点字、6点漢点字というシステムがあることの紹介。

    （２）NV Access の状況

    • 日本財団、Google, Adobe からの支援、ユーザーの寄付。
    • Microsoft Office サポート、特にビジネスで使われる機能に注力して、学生や企業の利用が増加。寄付も増えた。
    • Web 標準への対応、WAI-ARIA と IE 対応
    • Skype 対応の改善
    • Google の支援。Webアプリケーションがどんどんアクセシブルに。YouTube でアクセシビリティ機能が紹介されている。現在は Firefox 推奨だが Chrome もこれからよくなるはず。
    • インドの Sapient 社がフルタイムの NVDA 開発者を雇用している。Excel 対応の改善、言語の自動認識、インド国内の様々な言語や文字への対応。NV Access とインドのチームは定期的に電話会議をしている。
    • ディストリビューション。ダウンロード数はバージョンごとに78,000件。ユーザ数は一日あたり21,000人。
    • 各種の会議やイベントへの参加
    • 企業向けの有償サポート
    • フィリピンの eyRead 社によるエンドユーザ向けサポート事業の支援
    • 教材を作成中
    • 国際アドバイザリ委員会を立ち上げ準備中（西本も参加予定）

    日本からの質問とその回答：

    • タブレットについて。Windows アプリケーションの操作は一般的に複雑なので、キーボードがまったく不要になるほどタッチ操作を拡張することには懐疑的。
    • アプリケーション開発者に対してNVDAへの対応をどう伝えていくか。「ナレーターで使えるようにしてほしい」は悪くないメッセージ？
    • 日本におけるNVDAの位置づけ。国産スクリーンリーダーの普及率の高さや使いやすさは変わらない。新しいことにチャレンジできるのがNVDAのメリット？
    • NV Access はどこかに買収されたりしないのか？ 現在の非営利法人の法的な位置づけの制約で、営利企業に買収される可能性はない。非営利団体に吸収される可能性は過去に検討されたことはある。
    • Microsoft には競争相手としての「ナレーター」の存在に期待する。ナレーターは点字をサポートしないので、視聴覚の重複障害に対応できない。

    （３）NVDA 日本語チームの状況

    • 日本語版は本家版が出るごとにちゃんとリリースしてきた。
    • リリースごとのダウンロードは2000から3000。
    • 一日あたりのユーザは650（先週700を超えたばかり）。
    • コードサイニング証明書を独自に手配している。2014.4jp からはNVDA用音声合成エンジンを販売するナレッジクリエーション社が提供。
    • 用語の一貫性に配慮してきた。例えば「クイックナビゲーション」を「一文字ナビゲーション」に統一したり、「マウス」「マウスカーソル」「マウスポインタ」といった揺らぎを解消したりしてきた。教材を作る以前の作業として、開発者が行うべき「学習しやすさ」の改善と考える。
    • NVDA日本語版ガイドブックを執筆した。まる2日間の実習で使える内容になっている。ブラウズモードとオブジェクトナビゲーションを具体的に説明している。ユーザの環境や使っているアプリに依存しないように、なるべくNVDA自身の操作画面を使うように配慮している。また開発者の立場から技術的に正確な説明を心がけている。
    • NVDAワールドというイベントを毎年開催。展示ブースを作ってスポンサーを募った。
    • 企業の社会貢献活動、個人、ボランティア団体からの寄付を受けた。
    • ミートアップという新しいイベントの定期開催を始めた。

    この他に、食事しながら雑談したことなどは、また機会があればご紹介します。