Re: AtkText attributes
- From: Bill Haneman <Bill Haneman sun com>
- To: Brian Cameron sun com, korn sun com
- Cc: bill haneman sun com, gnome-accessibility-list gnome org
- Subject: Re: AtkText attributes
- Date: Mon, 28 May 2001 11:58:26 +0100 (BST)
>Hi Brian, Bill,
>> [...discussion about attributes and text ranges...]
>I think the basic tension here is between efficiency and complexity. It's
>inefficient to look at attributes a single character at a time, but simple.
>It's more efficient to look at ranges of characters (or runs as they are often
>called), but then we run into interface complexity problems if we want to convey
>all of the attribute information.
>Perhaps there is a third way? What about enumerating the unique attribute runs
>and then allowing the AT to get information about those runs, in addition to
>doing so a character at a time? Thus, the text:
> <font="times">This <bold>bold, <italic>itali</bold>ziced </italic> text</font>
>would contain 5 runs: [0-4], [5-10], [11-15], [16-21], and [22-26].
I had a conversation just before my holiday with Brian about this I think, at any
rate it looks as though I neglected to document my thoughts. My suggestion was to
add a new "BOUNDARY" type for the text get_text_at/before/after API,
DARY_ATTRIBUTES) would then return an attribute run.
For Java, until Java supports attribute runs, the resulting runs would always be
one character long as Peter suggests. Perhaps the bridge could add a small bit of
smarts, so that for the SPI we could implement the attribute run logic to reduce
the number of out-of-process calls required to get a text run on the AT side.
>An AT gets the following information when querying about text attributes for a
>given character index: the attributes for that index, and the range containing
>that index of similarly attributed text. Thus, to acquire all of the
>information for the full string, the at would start at index 0, get the
>attribute set and range [0-4], then ask for character index 5 (getting
>attributes and range [5-10]), etc. If a screen reader were doing an attribute
>search (a feature of outSPOKEN for Windows), they might start from the caret and
>go in run chunks.
>Another benefit of this approach is that it layers nicely on top of the Java
>Accessibility API which doesn't provide range information: all ranges are simply
>the index in question (so if you ask about index 5, the range you get back is
>[5-5]). So this approach would work well in the AT SPI.
>Sun Accessibility team
Bill Haneman x19279
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland
] [Thread Prev