[Webkit-unassigned] [Bug 45381] [Gtk] Adjust atk_text_get_text_at_offset to account for bullets/numbers in list items

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=45381





--- Comment #8 from Mario Sanchez Prada <msanchez at igalia.com>  2010-09-24 00:15:18 PST ---
(In reply to comment #7)
> (From update of attachment 68509 [details])
> when you get the text of an item with a list marker, should there be a space between the suffix and the actual text?
> atk_text_get_text(ATK_TEXT(item3), 0, -1), ==, "3.text and a link"
> 
> otherwise this patch is looking pretty good

Yeah, actually the previous version of the patch would need that extra space in the test, as I was also returning the space that sometimes comes along with the suffix in the RenderListMarker...

But then I thought again when redoing the patch without using the suffix, and I realized that the aditional space that sometimes is added to the suffix seemed to be too dependant on the painting process (where it's decided whether to put or not that extra space), and so to return that space along with the suffix would be too much hassle, would complicate this patch too much just because of it and, after all, if I wanted to be coherent, a function RenderListMarker::suffix() should return just the suffix, not the suffix and that -sometimes used while painting- extra space.

On top of that, from the ATK world POV, I don't think this is a big deal anyway, because at least a 1-character suffix will always be there separating the marker and the item's content (if it's not a character like '.', it will be at least ' '), so I don't think it was worth messing with that kind of things.

Of course, I can be wrong... but I honestly think this is a better, cleaner and good enough implementation. But in case I was wrong, just point it out and I'd look for a reliable way to put that extra space when needed, just the same way it would be done during the execution of the paint() method.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.