Re: AtkText attributes

[Brian Cameron <Brian Cameron sun com>]

Peter:

> I'm afraid I may not have been clear.  I'm suggesting that *all* attribute
> information be returned *every* time.  Then our "unique attribute run" for
> [5-10] is "font times, bold, 12-point"; and [11-15] is "font times, bold,
> italic, 12-point" (and of course [16-21] is "font times, italic, 12-point". 
> Make more sense now?  (I'm presuming here that 12-point is the default size when
> none is specified in HTML).

Ah, that would work much better.  This would work.  

> > Let's say I'm personally interested in the attributes on text [18-24]
> > 
> >    I would have to first call a function to find out that my section of 
> >    interest falls between two runs [16-21] and [22-26].  Once this was 
> >    established I would have to loop over all the runs before these to find
> >    out what attributes are set.
> 
> No.  You would make the following 2 calls only:
> 
>   getAttributes(18, &attrStruct);  // what is it like at the start of my range?
>   ... // calculation here
>   getAttributes(22, &attrStruct);  // what is it like in the next run that's
>                                    // within my range?

Wouldn't the function need to return the start of the next range as well as the
information about the attributes?  This way the user could loop.  If not, how
do you see the user finding out where the next range starts?  The "calculation
here" section above.  :)
 
> The first attrStruct returned would give you "font times, bold, italic,
> 12-point" for the range [16-21].  You would then notice that the end of this
> run, 21, was less than 24, and so make the second call starting at index 22,
> getting back the attrStruct "font times, italic, 12-point" for the range
> [22-26].  Since 26 is greater than 24, you are now done.

That makes sense.
 
> > ...
> > 
> >    I call the function saying I am interested in the text from 18-21.  I am
> >    returned perhaps an array of two structures which have the following info:
> > 
> >       struct[0]->attribute = font
> >       struct[0]->value     = times
> >       struct[0]->start     = 0
> >       struct[0]->end       = 26
> >       struct[1]->attribute = style
> >       struct[1]->value     = italics
> >       struct[1]->start     = 11
> >       struct[1]->end       = 21
> > 
> >    Using this data it is very easy for me to see what attributes apply to the
> >    text that I am interested in.  I can quickly see that the font attribute
> >    applies to all of the text between 18-21 and that the italics style applies
> >    to just 18-21.
> > 
> >    Does this seem like an overly burdened interface to you?
> 
> Your approach returns an array of unknown size that has to be allocated and then
> de-allocated.  When if we've got a ransom letter, every character a different
> font (or some other attribute).  I ask for a range [0-500].  I now get a huge
> struct back.  Especially again in the Java case, where we don't support range
> info, every situation will look like a ransom letter.

Isn't this the same with your proposal too?  Your example above where the
"attrStruct returned would give you the information "font times, bold, italic,
12-point" would also require an array of name,value structures wouldn't it?
Or are you proposing returning a string that has all the name value pairs
separated by commas?  I mean you could return the range info this way too.
"font times start end, style bold start end, style italic start end" would
similiarly avoid requiring a structure that needs allocation/deallocation.
Perhaps I'm missing something here.

...

> The Atk API works over a range.  Presumably the AT SPI will also work over a
> range.  But there will be a bridge from the Java API to the AT SPI, and so we
> will need to solve the attribute problem in that bridge.  And the Java API
> doesn't work over a range.  Since we can always return a range of 1 in this
> proposal, we have a very natural bridging.  And at such time as the Java API
> supports ranges, we'll get improved performance.

Point taken.  There's certainly no reason why we need to make things any harder
than necessary for the Java bridge implementation.

Brian