Apache OpenOffice (AOO) Bugzilla – Issue 72470
[a11y] multiline paragraphs in table cells not returning correct accessible text information.
Last modified: 2007-05-14 08:55:17 UTC
See comment #9 of Orca bug #382425 for more details. http://bugzilla.gnome.org/show_bug.cgi?id=382415#c9 Use: http://bugzilla.gnome.org/attachment.cgi?id=77846 as a sample test case, which contains a table where several of the table cells contain multiline paragraphs. Tabbing around those table cells in Orca does not speak or braille the correct table cell contents. Upon investigation, we have found that: "These objects of role "paragraph" have an obj.text, so displayedText = obj.text.getText(0, -1) is called. This should return all the text associated with this object. It the test case, for example with the cell that contains: Line 1 for R2C2 Line 2 for R2C2 Line 3 for R2C2 it always returns "Line 3 for R2C2". You can verify this by Tabbing into that cell, then using the Up/Down arrow keys to move up and down the three lines within that cell. You will always here "Line 3 for R2C2"." This suggests that this is a problem in OOo, hence this issue.
@richburridge: tested on Nevada 61 with OOo 2.2 (m14). The braille monitor correctly displays the current text (1,2,3) the cursor is in. Can you confirm?
Eric, the Orca braille monitor does indeed contain the correct information. This is because we have scripted around the problem in the Orca StarOffice.py script. See the various comments and attachments to the Orca bug for more details: http://bugzilla.gnome.org/show_bug.cgi?id=382415 What we would really like is for the problem to be fixed "at the source" so that this extra Orca scripting is necessary. Thanks.
@richburridge: I do understand. I couldn't find this background info just reading the issue. So I think this bug should be renamed like "Give a real fix for the current workaround". @obr: please take over. After fixing, tell me how to differenciate the state "Bug with workaround" from "fixed version". Thanx!
> @richburridge: I do understand. I couldn't find this background info just > reading the issue. > So I think this bug should be renamed like "Give a real fix for the current > workaround". That's fine with me. Hopefully Oliver can just turn on some debugging (or something) in the OOo Writer accessibility code and see the actual problem mentioned in the initial description of this bug. Thanks.
Hmm, the table cells in the sample document do not have one multi-line paragraph as a child, but three single line paragraph objects each returning the correct text information (verified with at-poke). I also merged them into one paragraph (by using shift-return) and again the result seems to be correct. Are you saying that all three objects return the same string for you ? BTW: in my test OOo build, the application name has changed from "soffice.bin" to "soffice". Just in case that matters.
> Are you saying that all three objects return the same string for you ? Yes. > BTW: in my test OOo build, the application name has changed from > "soffice.bin" to "soffice". Just in case that matters. Yes that does. You are going to need to add a line to .../orca/src/orca/settings.py, around about line 602, that goes something like: setScriptMapping(re.compile(_('soffice')), "StarOffice") then reinstall the modified Orca. Thanks.
I have tried reverting the changes to StarOffice.py done for and attached to http://bugzilla.gnome.org/show_bug.cgi?id=382415, but I am still unable to reproduce the issue: Moving through the lines with "up" and "down" orca reads exactly the line the cursor is in (tested on SNV 63 with vermillion 64 and orca build from source). Can you still reproduce the issue ?
Created attachment 44952 [details] Patch to remove workaround from Orca StarOffice.py script.
I've just attached a patch to remove the workaround from the Orca StarOffice.py script. This should be applied to the latest version of Orca in SVN trunk/HEAD. I'm testing against the latest OpenOffice that comes with Ubuntu Feisty. The version string is: openoffice.org 2.2.0-1ubuntu3, Tue Apr 10 21:51:38 UTC 2007 I'm using the test document in the Orca bug: http://bugzilla.gnome.org/attachment.cgi?id=77846 In Orca, make sure that you have "speak table cell row" set to True. That's: orca.settings.readTableCellRow = True in your ~/.orca/user-settings.py file. For the output below, I also have the debug level set to: orca.debug.debugLevel = orca.debug.LEVEL_INFO #orca.debug.eventDebugLevel = orca.debug.LEVEL_OFF I startup OOo Writer. Load the test document and initially click the focus to the left of the "Test Table" label. I then started Orca and gave focus to OOo Writer. I then used Tab and arrow keys to navigate the table. Here's the output I was getting spoken. Hope this helps. Thanks. ----------- $ orca GTK Accessibility Module initialized SPEECH OUTPUT: 'Welcome to Orca.' BRAILLE LINE: 'Welcome to Orca.' VISIBLE: 'Welcome to Orca.', cursor=0 BRAILLE LINE: 'orca Application Orca Screen Reader / Magnifier Frame' VISIBLE: 'Orca Screen Reader / Magnifier F', cursor=1 SPEECH OUTPUT: 'Orca Screen Reader / Magnifier frame' BRAILLE LINE: 'orca Application Orca Screen Reader / Magnifier Frame Preferences Button' VISIBLE: 'Preferences Button', cursor=1 SPEECH OUTPUT: '' SPEECH OUTPUT: 'Preferences button' BRAILLE LINE: 'soffice.bin Application multiline-table - OpenOffice.org Writer Frame' VISIBLE: 'multiline-table - OpenOffice.org', cursor=1 SPEECH OUTPUT: 'multiline-table - OpenOffice.org Writer frame' BRAILLE LINE: 'Adjust table row' VISIBLE: 'Adjust table row', cursor=0 SPEECH OUTPUT: 'Adjust table row' SPEECH OUTPUT: 'table with 3 rows and 3 columns.' BRAILLE LINE: 'soffice.bin Application multiline-table - OpenOffice.org Writer Frame multiline-table - OpenOffice.org Writer RootPane ScrollPane Document view Table1-1 Table Column 2 Column 3' VISIBLE: ' Column 2 Column 3', cursor=1 SPEECH OUTPUT: ' Column 2 Column 3' BRAILLE LINE: 'soffice.bin Application multiline-table - OpenOffice.org Writer Frame multiline-table - OpenOffice.org Writer RootPane ScrollPane Document view Table1-1 Table Column 2' VISIBLE: 'Column 2', cursor=1 SPEECH OUTPUT: 'Column 2' BRAILLE LINE: 'soffice.bin multiline-table - OpenOffice.org Writer multiline-table - OpenOffice.org Writer Document view Table1-1 Row 2 Line 3 for R2C2 Line 3 for R2C3' VISIBLE: 'Line 3 for R2C2 Line 3 for R2C3', cursor=1 SPEECH OUTPUT: 'Row 2 Line 3 for R2C2 Line 3 for R2C3' BRAILLE LINE: 'soffice.bin multiline-table - OpenOffice.org Writer multiline-table - OpenOffice.org Writer Document view Table1-1 Row 3 Line 3 for R3C2 Line 3 for R3C3' VISIBLE: 'Line 3 for R3C2 Line 3 for R3C3', cursor=1 SPEECH OUTPUT: 'Row 3 Line 3 for R3C2 Line 3 for R3C3' BRAILLE LINE: ' $l' VISIBLE: ' $l', cursor=0 SPEECH OUTPUT: '' BRAILLE LINE: 'soffice.bin multiline-table - OpenOffice.org Writer multiline-table - OpenOffice.org Writer Document view Table1-1 Line 3 for R3C3' VISIBLE: 'Line 3 for R3C3', cursor=1 SPEECH OUTPUT: 'Line 3 for R3C3' SPEECH OUTPUT: 'Goodbye.' BRAILLE LINE: 'Goodbye.' VISIBLE: 'Goodbye.', cursor=0
Thanks to the patch I was finally able to reproduce the issue. However, this doesn't seem to be an OOo bug: what happens is that Orca always queries the last child/paragraph of the table cell for its text, which seems to be due to the implementation of getRealActiveDescendant in default.py. I have changed it to return child 1 if the child count is greater than 1, and now Orca is reading "Line 2 of RC.." all the time.
@obr: thanks (especially for debugging Orca)! I've reopen the original Orca bug to see what should be done w.r.t. getRealActiveDescendant in default.py.
closing.