Re: AtkText attributes

[Bill Haneman <bill haneman sun com>]

Peter Korn wrote:
> 
> Hi Brian,
> 
> > > ... my proposal for a struct for attributes & ranges ...
> >
> > ... Brian raising the question of different attributes coming from different
>       places ...
> 
> I think the individual bridges should be able to map <b> to "bold" to ... as
> needed.  And I really like the extensibility of asking for specific tags and
> then getting those back (or really a set of tags).

Yes, I think that it's straightforward for bridges to map attributes
to strings that are somewhat descriptive, and for attributes that are
expected to be common to several bridges/apps, like "bold", it's
fairly easy to work out mappings and make sure that they are
consistent.  It then would be the responsibility of bridges to make
sure that "new" attributes are added to these bridge implementations
in a way that is consistent with other corresponding attributes in
other bridges.  In other words, if a particular bridge has no
"overline" attribute in version 1.0, its implementor must ensure that
if such an attribute is added later, it observes precedents
established for similar attributes by other bridges. 


-Bill

> The idea I put forth was that there would be a "core" set of attributes, and
> then the full set would be represented in string form.  But a tag-based approach
> makes a lot of sense, so long as we have a way for the requestor to ask for a
> set that it's looking for.  I also think returning a string-form of them is also
> useful, so that a user can get attribute information that the screen access
> product is not aware of (so to speak or Braille the string, for example).
> 
> Peter

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