goo blog サービス終了のお知らせ 

IT翻訳 Nobuyuki の仕事部屋

ボランティアでソフトウエアーローカライズのために翻訳をしている。

Implementing an MSAA Server を完成原稿にするーその13

2005-03-29 09:46:25 | InReview
本日から校正表記方法を少し改善します。

いままで、

原文:青色
訳文:黒
校正文章:赤

で表示してきましたが、これですと校正対象文[範囲]が不明確だと思っておりました。自分では分かりますが、他の人が見ると分かりにくいと思います。この問題の解決方法は、校正対象範囲を明確にすることで、対応できます。そこで、校正対象を黒の太字で表示することにしました。昨日から部分的にやってみると、うまく行くようなので、そうすることにしました。多少の改善になるでしょうか。

それでは、例によって全文のリンクからどうぞ。


原題: Implementing an MSAA Server

訳題: MSAA サーバーを実装する

Missing functionality in MSAA

Problem and solutions: Assistive technology vendors need some things which MSAA does not provide, such as:


MSAA に欠けている機能

問題と解決方法: 補助テクノロジーベンダーには、以下のように MSAA が提供しないのに必要なものがあります:


No way of signifying that a document has finished loading. Fire EVENT_OBJECT_STATECHANGE for a window/client/pane object when it starts to load a new document. Use STATE_BUSY to indicate that a new document is being loaded. When the loading has finished, fire another EVENT_OBJECT_STATECHANGE event and clear the STATE_BUSY flag.

ドキュメントがロードを完了した事を示す方法//挿入:→がない//:オブジェクトが新しいドキュメントのロードを開始する時、ウィンドウ/クライアント/ペイン・オブジェクト用に EVENT_OBJECT_STATECHANGE を起動します。//挿入:→そして//STATE_BUSY を使って新しいドキュメントがロード中であることを示します。ロードが完了した時、EVENT_OBJECT_STATECHANGE イベントをもう一つ起動し STATE_BUSY フラグをクリアーします。

No method to get clipped/unclipped bounds of a piece of text within a text object. This is needed by screen magnifiers. No scrollTo method, also needed by screen magnifiers. Implement a custom interface for text objects, and support it through QueryInterface or QueryService if it's being implemented on a different object than IAccessible is. Support a scrollTo method which takes a text index, and a getClippedBounds and getUnclippedBounds method which takes a start and end index. Publish your custom interface.

テキストオブジェクト内のテキストの境界を刈り込んだり戻したりするメソッド//挿入:→がない//: 画面拡大鏡で必要なメソッドです。scrollTo メソッドがなく、これも画面拡大鏡で必要なメソッドです。テキストオブジェクト用にカスタムインターフェイスを実装しますが、それが、 IAccessible が実装されていない//IAccessible が実装されているのとは別の//オブジェクト上に実装されているならば、 QueryInterface や QueryService によってサポートします。テキストインデックス を取り込む scrollTo メソッドおよび、開始インデックスと終了インデックスを取り込む getClippedBounds と getUnclippedBounds メソッドをサポートして下さい。

No way for assistive technology to know when scrolling has stopped. Fire the EVENT_SYSTEM_SCROLLINGEND event to indicate when scrolling has ended (try not to fire too many of these, wait until scrolling has truly stopped). There is no need to support EVENT_SYSTEM_SCROLLINGSTART, it is not used by assistive technology.

補助テクノロジーがスクロールの終わりを知る方法//挿入:→がない//: スクロールが終了した時を示す EVENT_SYSTEM_SCROLLINGEND イベントを起動する(あまり多くこのイベントを起動せずに、スクロールが本当に//→完全に//完了するまで待って下さい)。補助テクノロジーでは使用されていない EVENT_SYSTEM_SCROLLINGSTART をサポートする必要はありません。

No support for document formatting or "DOM" as requested by some vendors: support a custom interface that gives them the formatting information they are requesting.

要求するベンダーもいる//→ベンダーからも要請のある//、ドキュメントのフォーマット化のサポートや DOM のサポート//挿入:→がない//:ベンダーが要求する//→ベンダーが必要とする//フォーマット化情報を提供するカスタムインターフェイスをサポートして下さい。

本日は以上です。
また、先日 Mozilla Japan の山口さんからコメントでご指摘をいただいた「下さい」 と 「ください」の使い分けをしました。明示的に校正はしせんが、editor ですべて置き換えておきました。


Implementing an MSAA Server を完成原稿にするーその12

2005-03-28 23:39:05 | InReview
話は全然関係ないのですが、春といえば花開く季節です。我が家の狭い庭にもようやくチューリップが色付きはじめました。チューリップだけでは寂しいので、本日ムチコーレという黄色い花の苗を12苗ほど、購入しました。コンテナ単位でセールスをしておりました。ノースポルという白い花がちらほら咲き初めておりましたので、黄色いムチコーレと調和してあと一ヶ月ほどすると、可憐に咲き誇っている風情が楽しめるでしょう。そのころチューリップは終わっているでしょうが、5月になると今度はバラが見ごろになります。

バラといえば、今年ショックなことが起こりました。すでに冬に剪定していたバラの木々に若枝が伸び始めて、そこに若芽が吹きだしているのですが、ここ数年毎年大輪の花をつけていた白バラに、若枝が伸びてこないのです。どうも枯れてしまったようです。また、薄紅色のバラも細い貧弱な枝しか張っていません。ピンクのバラだけが例年どおり、太い新しい枝を伸ばしています。私はバラ愛好家でもないので、一通りの世話しかしませんが、それでも例年ならば3色のバラを中心に、小さいものも合わせて、しばしの間庭の片隅に華やいだ空間が出現して、心もどことなくうきうきします。今年は、それが望めないかもしれません。草花は元気に咲き誇っても、ある意味花形スターであるバラがさえない風情であれば、横綱が欠場の相撲の場所みたいなもので、物足りないこと限りありません。てなことを一人ごちた後で、今日もまた MSAA の話へと進みます。

No unique child ID for event target in window
ウィンドウ中のオブジェクトに一意の子 ID がない//→ウィンドウのイベントターゲット用に一意の子 ID がない//

Problem: MSAA expects events to be reported using NotifyWinEvent(eventNum, hWnd, worldID, childID), and there may not be an obvious way to get a window handle and a 32 bit childID for an object. You may be using windowless controls, or have an entire document with lots of objects in a given window. The child ID must be unique, because this is what the assistive technology will use to retrieve the accessible via AccessibleObjectFromEvent() which ends up using get_accChild on the accessible for the given window.

問題: MSAA は NotifyWinEvent(eventNum、hWnd、worldID、childID) を使ってイベントが報告される事を期待しますが//→NotifyWinEvent(eventNum、hWnd、worldID、childID) を使って、MSAA は イベントに報告を受ける事を期待しますが//、オブジェクト用のウィンドウのハンドルと 32 ビットの子 ID を取得する明確な方法がないかもしれません。あなたが、ウィンドウを使わない制御を使用しているところかもしれませんし、所定のウィンドウ中に多数のオブジェクトを含んだドキュメント全部を所有しているかも知れません//→あなたは、ウィンドウを使わない制御を使用中かもしれませんし、所定のウィンドウ中の多数のオブジェクトと一緒にドキュメント全部を備えているかも知れません//。子 ID は一意でなければなりません。というのは、補助テクノロジーがそれを使って、所定のウィンドウ用のアクセシビリティ上で最後に get_accChild を使うことになるAccessibleObjectFromEvent() を経由して、アクセシビリティに接続するからです//→・・・がそれを使って、AccessibleObjectFromEvent() を経由して、アクセシビリティに接続するからです。そしてこのインターフェイスは、所定のウィンドウ用のアクセシビリティ上で最後に get_accChild を使います//

Solution: In Gecko/Mozilla, we did not want to store an extra 32 bit unique ID value on every object. Instead, we hand back a 32 bit value derived from the UI object's pointer, which is unique. We ensure that the value we hand back is always negative. When the get_accChild call comes back, we check our hash table cache for that window to see if there's an accessible object still associated with that unique value. This means the client must use AccessibleObjectFromEvent immediately, because there is a danger that the object will go away, and another different object will be created with the same pointer value.That case seems extremely remote, because information from events is generally retrieved right after the event.

解決方法: Gecko/Mozilla では、すべのオブジェクト上に余計な//→追加で//32 ビットの一意の ID を保持する必要はありませんでした。代わりに、 UI オブジェクトのポインターが発信する 32 ビットの一意の値を返します。//挿入:→そして//返す値を必ず負の値にしなければなりません。get_accChild の呼出しが戻って来る時、ウィンドウ用のハッシュテーブルのキャッシュをチェックして、引き続き一意の値と関連しているアクセシビリティのオブジェクトが存在するかどうか調べます。これは、クライアントが直ちに AccessibleObjectFromEvent を使用しなければならないと言うことです。なぜならば、オブジェクトが消え去り同じポインター値で別の新しいオブジェクトが作られる危険があるからです。と言ってもイベントからの情報は一般的にイベントの直後に伝えられるので、これは極まれなことです。

If you're not using a hash table to keep track of unique ID's, store the child ID's and objects for the last 50 or so events in a circular array. In practice, this is enough to keep AccessibleObjectFromEvent() happy.

一意の ID を追跡記録するためにハッシュテーブルを使用していないならば、円形配列で最後の 50 程度の子 ID とオブジェクトを保持して下さい//→最後の 50 程度の子 ID とイベントを円形配列で保持して下さい//。実際、これだけあれば AccessibleObjectFromEvent() を楽に保管できます。


本日はここまでと致します。
以上

Implementing an MSAA Server を完成原稿にするーその11

2005-03-27 23:07:19 | InReview
本日より、新しい年度が始まりました。我が家の庭のチューリップも色付き始めました。気分一新でがんばりたいですね。


原題: Implementing an MSAA Server

訳題: MSAA サーバーを実装する

Confusion with system-generated events
システムによって作られるイベントによる混乱

Problem: When you test with Accessible Event Watcher in the MSAA SDK, you will see many events that your application did not generate. Microsoft Windows generates some events for you. These can be problematic, because the assistive technology has no way to tell whether the event came from your application or from Windows. For example, when you set window focus, Windows will generate an EVENT_OBJECT_FOCUS event an a ROLE_WINDOW object it also generated for you. If you happen to set window focus after you fired your own EVENT_OBJECT_FOCUS event on an object in the widnow, your event will be ignored, because assistive technology software tends to pay attention only to the last focus event.

問題: MSAA SDK 内の//→ MSAA SDK で// Accessible Event Watcher を使って試験する時、あなたは自分のアプリケーションが発生させたわけでない、数多くのイベントを見ることになります。//・・・する時、自分のアプリケーションが発生させたわけでない、数多くのイベントに気付きます。//MS Windows はあなたのために幾つかのイベントを発生させます。補助テクノロジーにイベントが//、//あなたのアプリケーションからか Windows から来ているのかを告げる方法が備わっていない以上、これらのイベントは問題です。例えば、ウィンドウフォーカスが設定される時//、// Windows は、これも//Windows はこれも//あなたのために発生させる ROLE_WINDOW オブジェクトとして、 EVENT_OBJECT_FOCUS イベントを発生させます。ウィンドウ内のあるオブジェクト上で、あなた自身の EVENT_OBJECT_FOCUS イベントを起動させた後でたまたまウィンドウフォーカスを設定するならば、あなたのイベントは、補助テクノロジーソフトがただ最後にフォーカスされたイベントにしか注意しないという理由で無視されます。

Solution: When an object is about to get focused in a different window, make sure you focus a window before you fire your own focus events for objects inside it. Test using Accessible Event Watcher in the MSAA SDK, and use the settings panel to watch subsets of accessibility events. Count on the assistive technology to make sense out the jumble of extra system-generated events, it's not your problem.


解決方法: あるオブジェクトが、異なるウィンドウ内でフォーカスされようとしている時//他のウィンドウ内で、あるオブジェクトがフォーカスされようとしている時//、ウィンドウ内のオブジェクト用に自分自身のフォーカスイベントを起動しない内に、必ずウィンドウをフォーカスするようにして下さい。MSAA SDK 内の Accessible Event Watcher を使って試験して下さい。そしてアクセシビリティイベントの下位集合を監視する設定パネルを使って下さい//・・・試験しアクセシビリティイベントの下位集合を監視する設定パネルを使ってください//
。補助テクノロジーを信頼してください。そして、システムが引き起こした余分なイベントのがらくたの存在を承知して下さい//補助テクノロジーを信頼して、システムが引き起こした余分なイベントのがらくたの存在を承知して下さい//。これはあなたの問題ではありません。


本当に難しい所を、駆け抜けている感じです。

Implementing an MSAA Server を完成原稿にするーその10

2005-03-26 22:34:22 | InReview
本日もアーロンさんの指摘が続いております。

例によって全文のリンクをご参照下さい。

原題: Implementing an MSAA Server

訳題: MSAA サーバーを実装する

Event window handle is incorrect

Problem: The screen reader or other assistive technology does not track the focus or other events correctly.

Solution: This may be because you are reporting that the events in a different window from the current system focus. The assistive technology may be asking GetGUIThreadInfo for its hwndFocus, and throwing away MSAA events that are not in the currently focused window. Even if you are visibly showing window focus on the correct window, you must also tell the operating system to focus this window before any other accessibility events get fired in it.


不正確なイベントウィンドウの扱い//→ イベントウィンドウの処理が正しくない//


問題: スクリーンリーダや他の補助テクノロジーはフォーカスや他のイベントを正確に追跡しない。//→ スクリーンリーダを含む補助テクノロジーはフォーカスやその他のイベントを正確に追跡しない//


解決方法: この事は、あなたが現在のシステムとは異なるウィンドウ中のイベントがフォーカスを持つと報告しているためかもしれません//→ 現在のシステムとは異なるウィンドウ中のイベントがフォーカスされるとあなたが報告しているために、この件が問題になるのかもしれません//。補助テクノロジーは GetGUIThreadInfo のhwndFocus を要求して、現在フォーカスのあるウィンドウ内に存在しない MSAA のイベントを//→ 挿入:例外として//投げているかも知れません。正しいウィンドウ上で、ウィンドウのフォーカスが見えるように表示されているとしても、他にアクセシビリティイベントがその中で起動されないうちに、このウィンドウをフォーカスするようにオペレーテイングシステムに命令が出されなければなりません。


短い節ですが、本日はここまでとします。

Implementing an MSAA Server を完成原稿にするーその9

2005-03-25 21:08:55 | InReview
本日も難しい内容が続きます。がんばりましょう。


原題: Implementing an MSAA Server

訳題: MSAA サーバーを実装する


Hacky highlight tracking causes problems
問題を引き起こす裏技ハイライトの移動


Problem:
Screen readers ignore the MSAA focus whenever a highlight bar moves, speaking the current highlighted text instead. The implementation of automated highlight tracking simply reads any text that is currently highlighted, even if it resides in several places on the screen. It does not take into account the problems that commonly occur with this feature, such as speaking the wrong thing, speaking the right thing twice or speaking two different things. Problems can easily happen merely by having two listboxes visible at the same time, because selected listbox items use the system highlight color, even when the listbox itself is not focused. Other problems occur when a piece of static text which has the same color background, which will cause that text to be repeated each time the focus or highlight moves. At least one major screen reader has a feature to turn highlight tracking off, but that's only a global setting, and turning off highlight tracking globally also turns off the speaking of menu items.

問題:
スクリーンリーダは、ハイライト表示部が移動する時はいつも、MSAA のフォーカスを無視して、代わりに現在ハイライトのあるテキストを読み上げます。ハイライト移動自動化の実装は、画面上の数箇所にハイライトが存在していても、現在ハイライトのあるテキストのみを読むだけです。//→画面上の数箇所にハイライトが存在していても、ハイライト追跡自動化の実装によって、現在ハイライトのあるテキストだけが読まれます。//しかし、間違ったものを読み上げる、正しいものでも 2 度読み上げる、または 2 つの異なるものを読み上げるなど、読み上げ機能について共通に発生する問題が考慮されていません。同時に表示される 2 つのリストボックスがあるだけで、問題は容易に//→すぐに//発生します。というのは、選択されたリストボックスの項目は、リストボックス自体がフォーカスされていない時でも、同じハイライト色を//→システムのハイライト色を//使うからです。同じ背景色を備えた静的テキストの時、別の問題が発生します。フォーカスやハイライトが移動するたびに、テキストが繰り返し読み上げられるというものです。ある大手のスクリーンリーダで、すくなくともハイライトの移動を無効にする機能を備えたものがありますが、その機能の設定がグローバルであるために、ハイライトの移動をグローバルに無効化すると、メニュー項目の読み上げ設定もまた無効化されてしまいます。


Solution:
Don't use the system highlight color for items that you don't want spoken when the highlight or focus moves. To fix this for standard listboxes, use owner drawn list items, so that you can change the highlight color when an item doesn't have focus. For listboxes that are not focused, use a different highlight color, to give the appearance that the listbox is no longer focused -- a lighter color for unfocused lists will also make the listbox state more visually obvious and thus more usable for everyone. For popup listboxes used for dropdowns in autocomplete text fields, change the color value by 1 when the user is typing in the textfield as opposed to arrowing through the list. The listbox will still visually appear to be active, but the screen reader behavior is improved by not echoing too much spoken information for each keypress. One downside to this solution is that means that you cannot use "client data" for the list items, because Windows won't allow owner drawn list items to use client data.


解決方法:
ハイライトやフォーカスが移動する時は、読み上げて欲しくない項目に対してシステムのハイコント色//→ハイライト色//を使用してはいけません。標準のリストボックスでこの問題を解決するためには、オーナー描画リスト項目を使用すると、項目にフォーカスが無い時はハイライト色を変更出来ます。フォーカスのないリストボックスには、異なるハイライト色(より薄い色の方が、フォーカスのないリストは//→ 、//リストボックスの状態を//→ 状態が//見た目に分かりやすく、だれもが使い易くなるので良い)を使って、リストボックスがもはやフォーカスされていないことを表示して下さい。自動補正テキスト領域でドロップダウン表示に使われるポップアップリストボックスは、リストを矢印で進めるのに対応して、ユーザーがテキスト領域でタイプ入力する時は、明度を 1 変更して下さい。リストボックスは表示上はなおも動作中に見えますが、スクリーンリーダの動作は各キー入力に対して読み上げ情報を過度に繰り返さないことで、改善されています。この解決方法の一つの欠点は//→ この解決方法の欠点は//、リスト項目に対して「クライアントデーター」が使えないことです。これは、Windows がオーナー描画リスト項目にクライアントデーターの使用を許可しないためです。

なかなか先に進みませんが、ここまでにしましょう。

Implementing an MSAA Server を完成原稿にするーその8

2005-03-24 20:46:35 | InReview
本日も張り切って行きましょう。
新学期も間もなくやってきます。裏山では、ホトトギスが鳴いています(本当かな?)。
花粉症がなければ、最高の季節なのですが。

Green leaves to their eyes,
There are robins singing near the hill.
Tears subside in my eyes,
Leaving a sense of being ill.

-Nobuyuki.


原題: Implementing an MSAA Server

訳題: MSAA サーバーを実装する


Hacky caret tracking causes problems
問題を引き起こす裏技キャレットの移動


Problem:
Assistive technologies do not use the MSAA caret. They follow screen draws, looking for a vertical blinking line. Unfortunately, some products can get confused by the vertical lines on other objects, such as list boxes, even though those lines are not blinking. The assistive technology may not see your caret at all.

問題:
補助テクノロジーは MSAA キャレットを使用しません。それは、一番上の点滅する行を探しながら、画面の描画を移動します。不運にも、リストボックスなどのように行が点滅しないのにかかわらず、他のオブジェクト上の一番上の行によってエラーになる製品もあります//→ リストボックスなどのような他のオブジェクトの一番上の行によって、行が点滅しなくても、混同してエラーになる製品も残念ながらあります//。この場合補助テクノロジーは、全くあなたのキャレットを見ない//→ あなたのキャレットを全然見ない//のかもしれません。



Solution:
Make sure there is a configuration file for each assistive technology specific to your application. Read the manual or help, and find the keystroke or commands for training the caret, and save this information in the configuration file. Make sure the caret always has the same width (1px or 2px) within a given window class. Don't support the MSAA caret unless you need Home Page Reader's desktop reader application to work with your application -- no one else uses the MSAA caret.



解決方法:
各補助テクノロジーに、あなたのアプリケーションに固有の設定ファイルが存在するようにして下さい//→ 各補助テクノロジーごとに、あなたのアプリケーションに固有の設定ファイルを必ず作成してください//。手順書かヘルプを参照して、キャレットをティーチングするためのキー打ち//→キー入力//か、コマンドを捜してください。そして、その情報を設定ファイルへと保存して下さい//→・・・へ落とし込んでください//。この時所定のウィンドウクラス内で、キャレットがいつも同じ幅( lpx か 2px) を保つようにして下さい。ホームページリーダーのデスクトップ読み上げアプリケーションがあなたのアプリケーション(他に MSAA キャレットを使用するアプリケーションはありません。)と一緒に動作する必要がない限りは、MSAA キャレットをサポートしないで下さい。

本日はここまでといたします。

Implementing an MSAA Server を完成原稿にするーその7

2005-03-23 18:46:37 | InReview
本日も同じことを続けます。
ウェブに不慣れなせいもあって、時々タグがむき出しの見づらい原稿となっています。editor でみるときれいなのですが、投稿すると不要な記号が現れてしまいます。お見苦しい点は真に申し訳ありません。現在勉強中ということで、お目こぼしいただき、徐々に見やすいものにしていきたいと思います。どうか、長い目で見てください。(汗:

以下の第 3 章は、リストの翻訳が主で、スペースばかりとりますので省くことにします。必要でしたなら、リンクをご参照下さい。
訳題: MSAA サーバーを実装する
原題: Implementing an MSAA Server

3. Deciding Which MSAA Features to Support
MSAA Events Cheat Sheet
MSAA States Cheat Sheet
MSAA Roles Cheat Sheet
MSAA Object Identifiers Cheat Sheet

3.MSAA サポート機能の決定
MSAA メソッド - 開発者のためのカンニングペーパー
MSAA イベント カンニングペーパー
MSAA 状態カンニングペーパー
MSAA 役割カンニングペーパー


本日以降、アーロンさんがアクセシビリティと格闘するなかで、MSAA の問題点を語っている第 4 章を校正します。この章が、この文書の一番の読みどころと思います。ところで、訳していて、自分の日本語に全然満足していません。もっと分かりやすい言葉で表現できないものかと、ほとんど苛付いています。もし、お気づきの点があれば、是非コメントをいただければ、ありがたく存じます。よろしくお願いいたします。

4.Dealing with the Quirks of MSAA



4.MSAA の気まぐれさと回避方法


MSAA has a well deseved reputation for quirkiness. It is not "plug and play", and will take a lot of testing/refinement before your solution works with any product. Here are some of it's quirks and some solutions/workarounds:
MSAA は気まぐれという評判に十分値します。「プラグアンドプレイ」とは言いがたく、すべての製品がうまく動作するようになる前に、多くの試験と調整が必要になります。以下に MSAA の気まぐれさとその解決方法、回避方法のいくつかを挙げます:

MSAA can be crash prone
MSAA のクラッシュ傾向//→MSAA はクラッシュし易い//


Problem:
Many of MSAA's crash occur because more than one process is refcounting the same objects, and because pointers are being shared between processes. When your application closes, different signals are typically broadcast. For example, the application window closes and the window is blurred. It is impossible to know if and when the 3rd party assistive technology will use one of these signals to release the objects of yours that is is refcounting. This can lead to crashes where it releases something and the wrong time, when some of your dll's are unloaded but not others, and a destructor is called in an unloaded DLL.

問題:
MSAA のクラッシュの多くは、二つ以上のプロセスが同じオブジェクトを参照カウントし、ポインターがプロセス間で共有される//→されている//ことで発生します。アプリケーションが閉じるとき、ふつう異なる信号が通知されます。例えば、アプリケーションウィンドウが閉じて、ウィンドウがぼやけて見えます。サードパーティーの補助テクノロジーが、参照カウント中(草稿訳注:is is refcounting は is in refcounting の typo?)のこれらの信号のひとつを使ってあなたのアプリケーションのオブジェクトを解放するかどうか//→アプリケーションのオブジェクトを解放するために refcount 中のこれらの信号のひとつを使うかどうか//、使うなら何時使うかを知ることは不可能です。このために、信号が何かを解放する場所でクラッシュが発生します。しかも、あなたの dll で//→ DLL で//アンロードされるものと、されないものがある時や、アンロードされた DLL の中で//→ DLL で//ディストラクターが呼ばれているなどの不都合な時に、クラッシュが発生します。


Solution:
Create a "shutdown" method for each internal accessible object, to remove any references to other internal objects before any of your dll's are unloaded. In order to do this effectively, you will have to keep track of every accessible object that you create. The shutdown method for an accessibility object should be called whenever the document or UI object it refers to goes away. The easiest way to do that is to keep a pointer to an accessible in each internal UI object. If that pointer is non-null, then there is an accessible object for it. Whenever the UI object is destroyed, shutdown it's accessible object as well. In Gecko/Mozilla we are not allowed to keep this extra pointer for each
accessible object, so when accessibility is turned on we use a hash table to cache these objects. Such a cache must be kept in perfect sync with the tree of UI and document objects, which is difficult. Therefore, unless 4 bytes extra on each object is criticial in your application, just keep the extra pointer around instead of using a hash table.


解決方法:
「シャットダウン」メソッドを内部の各アクセシビリティのオブジェクト用に作成して、あなたの dll のどれもが//→ dll が1つとして//アンロードされない内に他の内部オブジェクトへの参照を取り除きます。このことを効率的にするために、作られたすべてのアクセシビリティオブジェクトを追跡可能にする必要があります。ドキュメントオブジェクトやドキュメントオブジェクトが参照する UI オブジェクトが消え去る時はいつも、アクセシビリティオブジェクト用のシャットダウンメソッドが呼ばれるべきです。そうするため最も簡単な方法は、各内部 UI オブジェクト内のアクセシビリティにポインターを確保することです。そのポインターが null でなければ、アクセシビリティオブジェクトがあります。UI オブジェクトが排除されるときはいつも、そのアクセシビリティオブジェクトも同じく終了させて下さい。Gecko/Mozilla では、各アクセシビリティオブジェクト用にこの追加のポインターを確保できませんので、アクセシビリティが有効にされると、これらのオブジェクトをキャッシュするために、ハッシュテーブルを使います。このキャッシュは UI およびドキュメントオブジェクトのツリーと完全に同期をとって保持される必要がありますが、これは難しいことです。従って、あなたのアプリケーションで各オブジェクトに 4 バイトを追加することを必須条件としなければ、ハッシュテーブルを使わずに、追加のポインターを近くに保持だけして下さい。

Also, don't implement EVENT_OBJECT_CREATE or EVENT_OBJECT_DESTROY.
Vendors have found that watching these events causes crashes.

また、EVENT_OBJECT_CREATE や EVENT_OBJECT_DESTROY を実装しないで下さい。ベンダーはこれらのイベントを監視することはクラッシュを引き起こすことを知っています。
本日はここまで、難しくなって来ましたね。

Implementing an MSAA Server を完成原稿にするーその6

2005-03-22 13:52:25 | InReview
さて本日は、インターフェイスに関連するメソッドの説明です。
早速行きましょう。

3.Deciding Which MSAA Features to Support
3.MSAA サポート機能の決定


MSAA Methods - Cheat Sheet for Developers
MSAA メソッド - 開発者のためのカンニングペーパー




    The IAccessible interface is used in a tree of IAccessible's, each one representing a data node, similar to a DOM.

    Here are the methods supported in IAccessible - a minimal implementation would contain those marked "[important]":IAccessible は IAccessible のツリーの中で使われ、各インターフェイスは DOM と似たデーターノードを表しています。 IAccessible でサポートされるメソッドを挙げます。最小限の実装としては[重要] と記されたメソッドを含みます。 :

    • get_accParent: Get the parent of an IAccessible. [important]get_accParent: IAccessible の親を得る。[重要]
    • get_accChildCount: Get the number of children of an IAccessible. [important]
    • get_accChildCount: IAccessible の子の数を得る。[重要]
    • get_accChild: Get the child of an IAccessible. [important]
    • get_accChild: IAccessible の子を得る。[重要]
    • get_accName: Get the "name" of the IAccessible, for example the name of a button, checkbox or menu item. Try to use unique names for each item in a dialog so that voice dictation software doesn't have to deal with extra ambiguity.[important]
    • get_accName: IAccessible の名前を得る。例えば、ボタン、チェックボックス、あるいはメニュー項目の名前。音声検知ソフトウエアーが曖昧さを余計に抱え込まないように、ダイアローグボックスの各項目には一意の名前が必要。[重要]
    • get_accValue: Get the "value" of the IAccessible, for example a number in a slider, a URL for a link, the text a user entered in a field. [important]
    • get_accValue: IAccessible の「値」を得る。例えばスライダー中の数値、リンク用の URL 、ユーザーがテキスト領域に入力するテキストなど。[重要]
    • get_accDescription: Get a long description of the current IAccessible. This is not really too useful.
    • get_accDescription: 現在の IAccessible の長い解説を得る。実際それほど有用でない。
    • get_accRole: Get an enumerated value representing what this IAccessible is used for, for example. is it a link, static text, editable text, a checkbox, or a table cell, etc. [important] get_accRole: この IAccessible の使用目的を表す列挙数値を得る。例えば、リンク、静的テキスト、編集可能テキスト、チェックボックス、テーブルセルであるかどうかなど。[重要]
    • get_accState: a 32 bit field representing possible on/off states, such as focused, focusable, selected, selectable, visible, protected (for passwords), checked, etc.[important]
    • get_accState: フォーカスされているか、フォーカス可能か、選択されているか、選択可能か、見えるか、(パスワード)で保護されているか、チェックされたかなど、オン/オフの状態がどちらであるかを表す32 ビットのフィールド[重要]
    • get_accHelp: Get context sensitive help for the IAccessible.
    • get_accHelp: IAccessible 用に文脈に対応したヘルプを得る。
    • get_accHelpTopic: We don't use this, it's only if the Windows help system is used.
    • get_accHelpTopic: これは使用しない。Windows のヘルプシステムが使用されるときのみ使用。
    • get_accKeyboardShortcut: What is the keyboard shortcut for this IAccessible (underlined alt+combo mnemonic) get_accKeyboardShortcut: この IAccessible のキーボードショートカットは何であるか。(下線が引かれた alt+combo ニーモニック)>
    • get_accFocus: Which child is focused? [important]
    • get_accFocus: フォーカスのある子はどれか?[重要]
    • get_accSelection: Which children of this item are selected?
    • get_accSelection: この項目のどの子が選択されているか?//→ この項目のどの子たちが選択されているか?//
    • get_accDefaultAction: Get a description or name of the default action for this component, such as "jump" for links.
    • get_accDefaultAction: リンク用の「jump」など、この部品の初期設定された動作の説明と名前を得る//→ 動作の説明や名前を得る//
    • accSelect: Select the item associated with this IAccessible. [important]
    • accSelect: この IAccessible と関係している//→ 関連している//項目を選択する。[重要]
    • accLocation: Get the x,y coordinates, and the height and width of this IAccessible node. [important]
    • accLocation: この IAccessible ノードの x、y 座標、高さ、幅を得る。 [重要]
    • accNavigate: Navigate to the first/last child, previous/next sibling, up, down, left or right from this IAccessible. [important, but no need to implement up/down/left/right]
    • accNavigate: この IAccessible からの最初/最後の子、前/次の兄弟、上、下、左、右へと移動する。[重要、ただし、上/下/左/右は実装不要][重要]
    • accHitTest: Find out what IAccessible exists and a specific coordinate.
    • accHitTest: どんな IAccessible が存在するかを見出し、特定の座標を見出す。
    • accDoDefaultAction: Perform the action described by get_accDefaultAction.
    • accDoDefaultAction: get_accDefaultAction によって解説された動作を実行する。
    • put_accName: Change the name.
    • accDoDefaultAction: put_accName: 名前を変更する。
    • put_accValue: Change the value.
    • accDoDefaultAction: put_accValue: 値を変更する。



続く・・・・・・・フーツ、

Implementing an MSAA Server を完成原稿にするーその5

2005-03-21 20:58:23 | InReview
昨日の続きです。と言いながら今日で何日だろう。

原題: Implementing an MSAA Server

訳題: MSAA サーバーを実装する

MSAA decision-making guide:


  • Use MSAA whenever you have created custom controls where you're handling the drawing, mouse and keyboard accessibility in your own code. MSAA is the only way to let all AT's know what your code is doing.

MSAA 採否決定ガイド//→MSAA の採否を決定するための手引き//:


  • 自分自身のコードで描画、マウス、キーボードのアクセシビリティを取り扱うようなカスタム制御を作った時はいつも//→作り上げた時は必ず// MSAA を使用して下さい。MSAA はすべての補助テクノロジーにあなたのコードがしている事を知らせる唯一の手段です。 

  • Don't use MSAA if you're not running on a Windows platform ... hope that one was obvious.
  • Windows プラットフォームで動かさない場合は、MSAA を使わないで下さい... プラットフォームが明白であって欲しいですね。
  • Don't use MSAA if you're only Windows target for accessibility is Longhorn.
  • アクセシビリティ用の Windows のゴールが Longhorn であれば、MSAA を使わないで下さい (草稿訳注:英語構文的に理解できない。//→(草稿訳注:英語構文的に理解できない。Don't use MSAA if your only Windows target for accessibility is Longhorn. か?)//
  • Don't use MSAA if you're not going to take it all the way via testing with assistive technologies and working with AT vendors.
  • 最初から最後まで、補助テクノロジーを使って試験し、補助テクノロジーベンダーと共同作業をするのでなければ、 MSAA を使わないで下さい
  • Don't use MSAA for exposing documents or other specialized data, if it's important that the user get access to formatting information. You will have to expose interfaces that contain more info than MSAA does. This information may be in the form of extensions to MSAA, like Mozilla has done with ISimpleDOMNode (you can QI to it from IAccessible). This is likely to be a painful road even if you are a major player, in terms of getting the cooperation of AT vendors. It may be a good enough solution; however, if what you need is JAWS, Dragon and ZoomText support. ZoomText and Dragon can get by with your MSAA support., and JAWS can be scripted (even by external developers) to support alternative interfaces.
  • フォーマット化の情報へアクセスすることが重要な場合//→フォーマットする情報へアクセスすることが重要になる場合//、文書や他の専門的データーを公開するためにMSAA を使わないで下さい。 MSAA が保持するよりも多くの情報を保持しているインターフェイスを公開することになります。この情報は Mozilla が ISimpleDOMNode (IAccessible から ISimpleDOMNode へ QI できます。)を使って拡張したように、MSAA への拡張のフォームになる可能性があります。(草稿訳注: QI = QueryInterface か?/ また it = ISimpleDOMNode の解釈でよいか?)このことは、補助テクノロジーベンダーの協力を得ることに限っては、実力があっても険しい道のりになります。しかし解決方法としては、必要なものが、JAWS、Dragon および ZoomText のサポートであるなら、十分よい方法かもしれません。ZoomText と Dragon は MSAA のサポートがあれば、なんとか出来ますし、JAWS は、代替インターフェイスをサポートするためにスクリプト化(外部の開発者によっても)可能です。
  • Don't use MSAA if you're working with a small number of AT vendors, you can get everyone to agree on a different solution, and you're sure that you won't be needing to support other assistive technologies later.
  • 少人数の補助テクノロジーベンダーと協力しているならば//→わずかな補助テクノロジーベンダーグループと協力しているならば//MSAA を使わないで下さい。だれにでも//→すべての人に//、異なる解決方法に同意してもらうことが可能ですし、後になって他の補助テクノロジーをサポートする必要がないことを確信できます。


ちょうど切れの好い所に来ましたので、ここでやめます。この原稿のように時間がたって推敲すると、細かいところで色々変更して、伝えたいところをより明確にしたくなります。


Implementing an MSAA Server を完成原稿にするーその4

2005-03-20 14:33:45 | InReview
昨日の続きです。

原題: Implementing an MSAA Server

訳題: MSAA サーバーを実装する

2. When to use MSAA, and when not to
It's a common mistake to say that MSAA is not worth using, for a number of reasons.
Myths for not using MSAA
Myth: MSAA doesn't really work
Realtity: MSAA works really well for dialogs and UI. True, it's not great for documents, but it's the only existing widely-used standard for exposing accessibility.


2.MSAA を使うべき時と、使ってはいけない時
MSAA が使用に値しないというのは、大きな間違いである多くの理由があります。
MSAA を使わないための俗説
俗説: MSAA は実際動作しない
事実: MSAA は、ダイアローグ//→ダイアログ//ボックスと UI については、本当はとても良く動きます。確かに、MSAA は文書化については優れていませんが、広く使われているアクセシビリティを公開している現行の唯一の標準です。
//→アクセシビリティを公開している現行の唯一の汎用的標準です。//

Myth: MSAA is too slow
Realtity: Assistive technology vendors have found ways around most of the performance problems related to out-of-process COM method calls. Just make sure to have decent performance on your end.

俗説: MSAA は遅すぎる
事実: 補助テクノロジーのベンダーは、多くの性能上の問題を COM メソッドの呼出しの不具合のせいにしています。開発者サイドでは//→あなたの部門では//必ず優れた性能を働かせてください。


Myth: "MSAA sucks"
Realtity: This statement may come from another engineer or even an employee of an AT vendor. And what are they recommending for an alternative, a proprietary solution? MSAA is by no means perfect, but it is the only thing that will make your custom UI elements work with most assistive technologies. Try to be careful that AT vendors do not lock you into a prioprietary solution that will work with only their products.

俗説: "MSAA は低レベルだ"
事実: こんな風に言っているのは、他部門のエンジニエアか補助テクノロジーの従業員かもしれません//→補助テクノロジーの他部門のエンジニエア//→エンジニア//か、従業員かもしれません//。そういう彼らは代替手段として何を提案するのでしょうか。独自開発の解決案でしょうか。MSAA はけっして完全ではありませんが、開発//→カスタム化//された UI エレメントがほとんどの補助テクノロジーと一緒に動作可能な唯一の手段です。補助テクノロジーのベンダーによって彼らの製品だけでしか動かない独自開発の解決手段に縛り付けられないように注意が必要です。


Related Myth: MSAA is not supported by AT vendors
Reality: It's a standard, and it is supported by JAWS, Window-Eyes, ZoomText, Dragon and Supernova/HAL. There's currently nothing better.

関連する俗説: MSAA を補助テクノロジーのベンダーがサポートしない。
事実: MSAA は標準であり、JAWS、Window-Eyes、ZoomText、Dragon と Supernova/HAL によってサポートされます。現状は MSAA より優れたものはありません。


Myth: MSAA has no documentation
Realtity: You're reading useful documentation right here. The docs on MSDN are useful as well.

俗説: MSAA は文書化されていない。
事実: ここで実際有益な文書を参照されてますね。MSDN 上の文書もまた有益です。


Mostly myth: MSAA is too expensive to implement
Reality: *Too* expensive is relative, and depends on how important accessibility is for your project. This document's Deciding Which MSAA Features to Support section attempts to lower the cost by showing which parts of MSAA are not very important to work on. You only need to support MSAA on the non-standard controls in your app. So, it's not too bad.

多くの俗説: MSAA は実装するのに高価すぎる。
事実: 高価過ぎるとは相対的感覚であり、プロジェクトにとってのアクセシビリティの重要さによります。 当文書のサポートされるべき MSAA の機能の決定の章は、取り組むほどでないそれ程重要でない MSAA の部分を示すことで、コスト削減することを目的としています。//→当文書では、『MSAA のサポートする機能を決める』の章で、あまり重要でない MSAA の実装部分を紹介する事によって、コスト削減を企てています。//アプリケーションの標準外の制御上//→制御//で、MSAA をサポートすることだけが必要です。従ってそんなに高価すぎることはありません。


Mostly myth: Microsoft is abandoning MSAA in Longhorn
Realtity: Microsoft's accessibility strategy is changing to a new API in Longhorn. MSAA will still be supported through an emulation layer, but that will probably be a very slow solution. We'll have to wait and see how good the MSAA support in Longhorn is, before we can call this one.

多くの俗説: Microsoft は MSAA を Longhorn においてゆくゆくは廃止する。//Longhorn において Microsoft は MSAA をゆくゆくは廃止する。//
事実: Microsoft のアクセシビリティ戦略は長期的に//Longhorn において(抜け)//新しい API へと変わりつつあります。MSAA は依然としてエミュレーション層を通してサポートされますが、おそらく大変時間のかかる解決方法となります。この件を問い合わせる前に、結論を急がず長期的に Longhorn における MSAA のサポートがどれほど有効かを見る必要があります。


本日はここまでとします。
フーツ、先は長いぞ。