This is similiar to atk_text_get_offset_at_point()/GetOffsetAtPoint() and thus the underlying implementation should share code if possible.

For both horizontal and vertical bounds of the in rect parameter, we need to support these: ATK_TEXT_CLIP_NONE No clipping to be done ATK_TEXT_CLIP_MIN Text clipped by min coordinate is omitted ATK_TEXT_CLIP_MAX Text clipped by max coordinate is omitted ATK_TEXT_CLIP_BOTH Only text fully within mix/max bound is retained My question is how can we do that? For example if you have a paragraph that flows, how are we supposed to do any clipping when all we can return are start and end offsets anyway? We're not returning concatenated text. If it wasn't for that I'd say the implementation of this is trivial, because we can use the offsets of the rectangle corner points and feed them into GetOffsetAtPoint.

My mistake, this returns an array of ranges. This is perfectly doable. AtkTextRange** atk_text_get_bounded_ranges (AtkText *text, AtkTextRectangle *rect, AtkCoordType coord_type, AtkTextClipType x_clip_type, AtkTextClipType y_clip_type) Where AtkTextRange is define as follows: typedef struct { AtkTextRectangle bounds; gint start_offset; gint end_offset; gchar* content; } AtkTextRange;

This should be very easy to add, we have: http://lxr.mozilla.org/seamonkey/source/accessible/public/nsIAccessibleText.idl 138 void getRangeExtents (in long startOffset, 139 in long endOffset, 140 out long x, 141 out long y, 142 out long width, 143 out long height, 144 in unsigned long coordType);

Ignore comment 3, this is the reverse of that. Given |rect| we need to provide the text range. I must say this API is annoying to implement with all the text clipping arguments. What uses it?

It is implemented in atktext.c I think we needn't to re-implement it in Gecko. It requires get_offset_at_point, get_text_at_offset, get_character_extents, get_range_extents, we have implemented all of them.