GNOME Bugzilla – Bug 578072
Orca does not always present text attributes in braille in OOo documents
Last modified: 2009-04-08 23:26:06 UTC
Steps to reproduce: 1. In OOo Writer 3.0, create a document in which you have several lines of text. In each line, make one of the words bold. Such as: *First* word bold Middle *word* bold Last word *bold* Apply bold in place of the asterisks 2. Enable the indication of text attributes in braille and arrow through the text. Expected results: bold text would always be indicated in braille Actual results: bold text is only indicated when that attribute is present at the beginning. This is due to bogus offsets being returned from getAttributes (also from getAttributeRun) like start: 154243824 end: -18131255. :-( Hack to follow.
Created attachment 132152 [details] [review] hack to work around the YAOOB Pylinted; not regression tested. I limited this to the soffice script and it seems to solve the problem. While the OOo guys need to fix their bug IMHO, users need to have access to text attributes in braille. Will, what are your thoughts on this?
(In reply to comment #1) > Created an attachment (id=132152) [edit] > hack to work around the YAOOB > > Pylinted; not regression tested. > > I limited this to the soffice script and it seems to solve the problem. While > the OOo guys need to fix their bug IMHO, users need to have access to text > attributes in braille. > > Will, what are your thoughts on this? I think this looks fine. Thanks for doing the work. It might be nice to put a debug.printStack and debug.println at level WARNING in the the defensive section that handles end < 0. Not fully needed, but it would let us know we're doing something to hack around YAOOB. BTW, have you filed YAOOB yet?
Created attachment 132304 [details] [review] revision 2 > I think this looks fine. Thanks for doing the work. It might be nice to put a > debug.printStack and debug.println at level WARNING in the the defensive > section that handles end < 0. Not fully needed, but it would let us know we're > doing something to hack around YAOOB. My initial reaction was to agree. Then I did it. I pressed Up Arrow one time moving to a short line ("Middle word bold") and 1100 + lines resulted. :-) The nature of the bug and the hack is that braille.py's getAttributeMask is going to keep coming back character by character. The offsets will continue to be bogus until we stumble across some formatted text. Here's an example: vvvvv PROCESS OBJECT EVENT object:text-caret-moved vvvvv OBJECT EVENT: object:text-caret-moved detail=(0,0) app.name='soffice' name='None' role='paragraph' state='editable enabled focusable focused multi line multiselectable showing visible' relations='flows from flows to' soffice.script.py:getTextAttributes: detected a bogus end offset. Start offset: 0, end offset: -17934646 soffice.script.py:getTextAttributes: detected a bogus end offset. Start offset: 1, end offset: -17934646 soffice.script.py:getTextAttributes: detected a bogus end offset. Start offset: 2, end offset: -17934646 soffice.script.py:getTextAttributes: detected a bogus end offset. Start offset: 3, end offset: -17934646 soffice.script.py:getTextAttributes: detected a bogus end offset. Start offset: 4, end offset: -17934646 soffice.script.py:getTextAttributes: detected a bogus end offset. Start offset: 5, end offset: -17934646 soffice.script.py:getTextAttributes: detected a bogus end offset. Start offset: 6, end offset: -17934646 soffice.script.py:getTextAttributes: detected a bogus end offset. Start offset: 11, end offset: -17934646 soffice.script.py:getTextAttributes: detected a bogus end offset. Start offset: 12, end offset: -17934646 soffice.script.py:getTextAttributes: detected a bogus end offset. Start offset: 13, end offset: -17934646 soffice.script.py:getTextAttributes: detected a bogus end offset. Start offset: 14, end offset: -17934646 ---------> QUEUEING EVENT object:property-change:accessible-name soffice.script.py:getTextAttributes: detected a bogus end offset. Start offset: 15, end offset: -17934646 BRAILLE LINE: 'soffice Application attrib-test.odt - OpenOffice.org Writer Frame attrib-test.odt - OpenOffice.org Writer RootPane ScrollPane Document view Middle word bold $l' VISIBLE: 'Middle word bold $l', cursor=1 sayLine: line=<Middle word bold>, len=16, start=0, caret=0, speakBlankLines=True SPEECH OUTPUT: 'Middle word bold' ^^^^^ PROCESS OBJECT EVENT object:text-caret-moved ^^^^^ Do we want the output from debug.printStack for each of the characters above? If so I'll put it in. > BTW, have you filed YAOOB yet? I have now. :-) http://www.openoffice.org/issues/show_bug.cgi?id=100938
(In reply to comment #3) > My initial reaction was to agree. Then I did it. I pressed Up Arrow one time > moving to a short line ("Middle word bold") and 1100 + lines resulted. :-) Ugh! > Do we want the output from debug.printStack for each of the characters above? Given the circumstances, it seems very ugly. So, I guess I lean towards not doing it. Even at LEVEL_ALL it would be very annoying in the debug logs. > I have now. :-) http://www.openoffice.org/issues/show_bug.cgi?id=100938 Many thanks!
Okie dokie. I've committed revision 2 to both trunk and the gnome-2-26 branch. Closing as FIXED.