GNOME Bugzilla – Bug 418287
[blocked] Treat words separated by non-breaking spaces as a single word in OOo
Last modified: 2013-01-09 22:34:39 UTC
When words are separated by non-breaking spaces in an OOo Writer document, Writer does not treat those non-breaking spaces as word boundaries. As a result, when navigating with Control Left/Right Arrow one skips over words (in the linguistic sense). In these conditions, Orca speaks the new word (again, in the linguistic sense) at the caret rather than the new phrase at the caret, thus bits of text seem missing. Speaking words separated by non-breaking spaces as a single word would, I think, be less perplexing to the user than not speaking the affected text at all.
Created attachment 84586 [details] sample document with non-breaking spaces Try navigating the attached with Control Left/Right Arrow.
This looks like a disparity between the what OOo tells us a word is and what it thinks a word is for navigating. Around line 1854 in StarOffice.py, there's a call to our wonderful friend, text.getTextAtOffset(caretOffset, atspi.Accessibility.TEXT_BOUNDARY_WORD_START). This returns what the AT-SPI implementation thinks is the word at the given caret offset. Well, more correctly, it returns the word, the startOffset, which is the character offset of the beginning of the word at or before the caret offset, and the endOffset, which is the character offset of the beginning of the next word (don't ask me, I didn't go to API obfuscation school). In debugging this, getTextAtOffset is returning what we'd expect - just a single word. OOo's word caret navigation scheme, however, seems to skip over nbsp. I'd say this is a bug in OOo's navigation code and we should log a bug with OOo. Thoughts?
> I'd say this is a bug in OOo's navigation code and we should log a bug with > OOo. Thoughts? Makes sense to me. Here's the bug: http://www.openoffice.org/issues/show_bug.cgi?id=75441 Updating the summary to reflect our blocked status.
Removing target milestone from [blocked] bugs. We have little control over them, so we're better off letting priority and severity be our guide for poking the related components.
Bad news/good news: The bad news is that this has just been targeted for OOo 3.0. :-( But the good news is that it's been targeted, acknowledged as a true defect, and theoretically assigned to the individual better in a position to deal with it.
Yet another ancient tracking bug and not something we have control over.