Apache OpenOffice (AOO) Bugzilla – Issue 100938
Incorrect offsets returned by getAttributes
Last modified: 2013-08-07 14:44:00 UTC
1. Open the test case (to be attached) and launch Accerciser 2. In Accerciser, select the Document View accessible in the list of accessibles 3. In Accerciser's iPython console, type the following: for a in acc: t = a.queryText(); print t.getText(0, -1), t.getAttributes(0) 4. Press Return Expected results: The start and end offsets would be valid. Actual results: If the character at the offset passed to getAttributes is not bold, the start and end offsets are bogus, e.g.: All bold ('weight:600', 0, 9) None bold ('', 154245040, -18142958) First word bold ('weight:600', 0, 7) Middle word bold ('', 154245040, -18142958) Last word bold ('', 154245040, -18142958) This bug is present in OOO300m9 (Build:9358), DEV300m41(Build:9383), and OOO310m9(Build:9396)
Created attachment 61443 [details] sample document
@OD: as described. (also reproducible with Accerciser 1.4.0 ;) )
fix in progress in cws swa11y32. defect cause: the start offset and end offset are only calculated, when there exists a certain attribute run. Otherwise the values are not initialized. solution: initialize the start offset and the end offset to the complete text boundaries. OD->williewalker,joaniediggs,MT: I do not think that the given end offset is correct. In our ATK bridge the end offset provided by the corresponding OOo-UNO-A11y-API is incremented by 1 which I think is not correct. I am right, that the increment by 1 is not correct?
@williewalker -> od: I'm not sure I understand the OOo implementation enough to determine whether the value is correct or not. Can you provide an example with specific offset numbers?
OD->williewalker: Just take your example. Look at the getAttributes results for the first and the third paragraph: I my opinion the end offset should be 8 not 9 respectively 6 not 7. The first paragraph consists of only one attribute run. The end offset in this paragraph is 8. In the third paragraph the first word "First" and the following space character are bold. The offset 6 is between the space character and the following character "w". While offset 7 is between "w" and "o".
Ok. Now I have read the specification for <atk_text_get_run_attributes()> at http://library.gnome.org/devel/atk/unstable/AtkText.html#atk-text-get-run-attributes. There it is said: <quote> ... Note that end_offset is the offset of the first character after the range. ... </quote> Thus, everything seems to be fine. Sorry for the noise.
Hm... thinking again. In the third paragraph of the given example the offset of character "F" is 0 and the offset of character "w" is 6. Thus, the provided end offset is wrong in my opinion.
joaniediggs->OD,williewalker: Yeah, that does look off. It also jogged my memory about something: I just took a look in Orca's script for StarOffice/OOo. In cases where the bogus offsets are *not* being seen and everything is presumably fine, getTextAttributes is automatically decrementing the end offset by 1. I don't believe we're doing this elsewhere in Orca. From that, I'm guessing that the OOo implementation's end offset is consistently 1 greater than it should be.
In looking at the specific example Joanie supplied, let's see if we can agree upon some numbers. All bold: t.attributes(0) = ('weight:600', 0, 8) None bold: t.attributes(0) = ('', 0, 9) First word bold (assume the space character after 'First' is bold): t.attributes(0) = ('weight:600', 0, 6) t.attributes(6) = ('', 6, 15) Middle word bold: t.attributes(0) = ('', 0, 7) t.attributes(7) = ('weight:600', 7, 11) - assuming the 'space' is not bold t.attributes(11) = ('', 11, 16) Last word bold: t.attributes(0) = ('', 0, 10) t.attributes(10) = ('weight:600', 10, 14) Seem OK?
Ok. Thus, I will adjust OOo's ATK bridge code accordingly. BTW, it is not the intrinsic OOo implementation which provides the wrong end offset. In the code of OOo's ATK bridge the end offset provided at OOo's UNO-A11y-API is incremented by one. Thus, an adjustment of Orca's script for OOo will be needed after this fix.
fixed as suggested in cws swa11y32 - changed file: /vcl/unx/gtk/a11y/atktext.cxx, rev. 273229
OD->ES: Checked in internal installation set of cws swa11y32_2nd - please verify
This fix has been confirmed by the Orca team using the swa11y32_2nd_en-US_SolarisIntel.tar file Thomas Lange made for me (300m51(Build:9408)[CWS:swa11y32_2nd]). Many thanks!
Thanx for verifying!
Fixed and integrated => closing now..