Re: AtkText attributes

[Bill Haneman <Bill Haneman sun com>]

>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.

-Bill

>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.
>
>
>Regards,
>
>Peter Korn
>Sun Accessibility team

------
Bill Haneman x19279
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland