Re: AtkText attributes



Brian Cameron wrote:
> 
> Bill & Others:
> 
> > We've had a couple of conversations about removing our current Pango
> > dependency from ATK.  Though we think Pango is great and will of
> > course depend on it heavily in GAIL, the only pango dependency that I
> > know of in ATK is the use of PangoAttributeSet as the means of
> > indicating text attributes.
> 
> Aside from returning the data as name/value paris, there are some
> issues with returning the attirbutes from the GtkTextWidget.
> 
> First of all, all PangoAttributes have a start_index and an end_index,
> (for example describing that the text uses a certain font in this
> range).  What if a TextBuffer has font 1 defined for characters
> 10-30, font2 defined for characters 31-50, and the user calls
> atk_text_get_range_attributes asking for the attributes between
> characters 25 and 40.  The "Font" attribute will have two different
> values within this range.  I'm not sure that this level of detail
> is returned via the current atk_text_get_range_attributes interface.

The idea was for atk_text_get_attributes() to return only those
attributes that are the same across the range given, so in the case
you cite Font would not show up.

This may not be what one expects, but otherwise I think the returned
data structs get too complex.  The Java API only returns a set of
attributes for a single character, and I'd like to do a little
better.  We've discussed adding a means of getting an attribute "run"
to the SPI, and I think we should, which would require a similar
function in ATK.  One way to do this is by adding a new TEXT_BOUNDARY
type, and possibly adding API to allow us to get boundary offsets as
well as just character strings.  Thus:

startOffset = atk_text_get_prev_boundary (text, offset,
ATK_TEXT_BOUNDARY_TYPE_ATTRIBUTES);
endOffset = offset = atk_text_get_next_boundary (text, offset,
ATK_TEXT_BOUNDARY_TYPE_ATTRIBUTES);

attributesOverRange = atk_text_get_attributes (text, startOffset,
endOffset);

> Perhaps one step of the solution is to return something more complicated
> than a (name value) pair, but instead something like a (name, value,
> start position, end position) structure.  This way multiple "font"
> attributes could be returned.
> 
> However, since font1 is used from position 10-30 and font2 is used
> from position 31-50, and the user asked for info for positions 25-40,
> does the function say font1 is used from 1-30 or from 25-30, and
> that font2 is used from 31-40 or 31-50?  Not sure if I'm making sense
> here, but it's not clear how the function should work.
> 
> One solution would be to make the function not range based.  If the
> function were just a atk_text_get_attributes() and returned an array
> of (name, value, start position, end position) structures for the
> whole buffer, then this would resolve any potential confusion about
> how to handle ranges.  This would pass all the info about the buffer
> back to the user and let them extract what interests them.

This is OK until the text buffer becomes very large, in which case,
ugh.

So maybe that is not the right solution.
 
> Another problem is that the GtkTextWidget doesn't give easy access
> to the Pango Attributes.  Instead it uses GtkTextTags to provide
> a level of indirection between Pango and the GtkTextWidget.  If
> you look at this website you can see what "tags" are supported.  See
> section named Args.
> 
>   http://developer.gnome.org/doc/API/2.0/gtk/gtktexttag.html
> 
> This function would be much easier to code if we could just use
> the tag information instead of the Pango information.  Is this
> acceptable?  I might need some help defining which of these "tags"
> are in fact useful ones that we want to make available through
> this interface...unless we just blindly want to pass them all
> through.

I think this would work nicely with the notion of "string" based
attributes, then text tags would do nicely, I think.

-Bill

> Let me know what you think.
> 
> Brian

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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]