|
Description
|
Originall Filed in bugzilla
http://bugzilla.gnome.org/show_bug.cgi?id=153410
------------------------------------------------
Reporter: xxxxx@xxxxx.com (Javier)
Please describe the problem:
When you are reading a text line in a text editor, if this line has only two
separated words, Gnopernicus reads it as if was two lines of text.
Steps to reproduce:
1. Open gedit in a blank new text file.
2. Write in one line two separated words:
hello world
3. Up and down arrow to read the text line.
Actual results:
Gnopernicus first read the word hello as if was in a single line, and then down
arrow and reads world in an another single line.
Expected results:
The complete line has to be read, "hello world".
Does this happen every time?
This happend everytime.
Other information:
I am running Gnopernicus 0.9.12 and GNOME 2.7/2.8 with festival's synthesis.
------- Additional Comment #1 From Javier 2004-09-23 01:42 -------
Same behavior seems to occur when you write two words separated for example by
a dot, an at (@) sign.
If you write three words, the problem it's not present. It's very strange,
isn't it?
------- Additional Comment #2 From Dana Ormenisan 2004-09-23 07:37 -------
The problem is that in some situations AccessibleText_getTextAtOffset called
with SPI_TEXT_BOUNDARY_WORD_START returns wrong values for start/end word (I've
checked this with gnopernicus and an independent at-spi tester).
Case1:
Type in gedit, on a single line: "hello world" <enter>
Move up and down. When you move down, from the "hello world" line to the empty
line, gnopernicus reports "world" (it should say "enter"). Checking with at-spi
tester, these are the ranges for char/word/line:
Current char ranges: 12-12 text:
Current word ranges: 6-12 text:world
Current line ranges: 12-12 text:
Why the current word is "world" if the cursor is on the next line?
Case 2:
Type in gedit: "hello world"<enter>
<space>"test"
Move up and down. When you move down, from the "hello world" line to the
"<space>test" line, gnopernicus reports "world test" (it should say only
"test"). Checking with at-spi tester, these are the ranges for char/word/line:
Current char ranges: 12-13 text:<space>
Current word ranges: 6-17 text:world test
Current line ranges: 12-17 text:<space>test
Why the current word is "world test" if the cursor is on the "<space>test" line?
Case 3:
Type in gedit: "hello world"<enter>
"test"
In this case, the ranges are correct:
Current char ranges: 12-13 text:t
Current word ranges: 12-16 text:test
Current line ranges: 12-16 text:test
Transferring to at-spi for evaluation.
------- Additional Comment #3 From xxxxx@xxxxx.com 2004-09-24 03:49 -------
Transferring to atk/gail for evaluation.
------- Additional Comment #4 From xxxxx@xxxxx.com 2004-09-24 05:12 -------
I have used the test modules in gail to reproduce the results reported by Dana.
I believe that the result for Case 1 is correct. The documentation for
atk_text_get_text_at_offset states that for boundary type
ATK_TEXT_BOUNDARY_WORD_START the returned string is from the word start at or
before the offset to the word start after the offset.
The result for Case is clearly incorrect. I am still investigating why.
------- Additional Comment #5 From xxxxx@xxxxx.com 2004-09-24 06:54 -------
In Case 2 a call to gtk_text_iter_inside_word() returns TRUE when the
GtkTextIter is on the space character. This is, I believe, a bug in GTK for
which I will log a bug.
------- Additional Comment #6 From xxxxx@xxxxx.com 2004-09-27 03:28 -------
Bug #153628 has been logged and fixed. This should fix Case 2. I do not believe
Case 1 is a bug.
Transferring back to gnopernicus for further evaluation.
------- Additional Comment #7 From Dana Ormenisan 2004-09-29 04:23 -------
Created an attachment (id=32056)
proposed patch
Do not provide a word-by-word navigation if the current reported word is not on
the current line (this situation can appear in a short line of text, when user
moves using up/down arrow keys). In this case, the current line should be
reported.
------- Additional Comment #8 From Javier 2004-09-30 08:17 -------
I have applied the patch, case 1, 2 and 3 are solved.
------- Additional Comment #9 From xxxxx@xxxxx.com 2004-09-30 10:46 -------
Dana, I do not understand the case which the gnopernicus patch is intended to
solve.
------- Additional Comment #10 From Dana Ormenisan 2004-09-30 11:02 -------
There are some situations (see case1) in comment #2) when the current reported
(by at-spi) word does not belong to the current reported line. In this case,
gnopernicus will report the 'current word' even if the cursor is on a different
line.
This situation occurs in gedit if user types _two_ words on a single line,
followed by <enter>: if user moves up/down, when the cursor will be on the empty
line gnopenricus will report 'word' (because this is the current word...). The
patch is intending to not report the current word (but the current line) if the
current word does not belong to the current line.
------- Additional Comment #11 From xxxxx@xxxxx.com 2004-10-05 09:36 -------
I think the issue is the use of BOUNDARY_WORD_START, because in this case even
though the current cursor position is on a new line, the boundary from the
"current position" which is bounded by "word starts" does include the word from
the previous line.
------- Additional Comment #12 From Dana Ormenisan 2004-10-06 04:23 -------
Some times ago (see bug #149785) you suggested that we can implement a
word-by-word navigation not only in the current line, but also between lines.
In order to have this functionality, we compare the word boundary for the
current and last offset and in this way we decide if there is a word-by-word or
a line-by-line navigation.
I do not know how could I check these ranges (if the offset moves to a new line
and start_crt_word==end_last_word or end_crt_word==start_last_word =>
word_by_word navigation) without using BOUNDARY_WORD_START. The current
algorithm works fine if user moves using Ctrl+Left/Right because the caret will
be moved to the beginning/end of the next word. A word from the previous line
can never be reported in this way.
The problem occurs only if you have two words on a line and the second line is
empty or begins with spaces and user moves using up/down arrow keys, not Ctrl
Left/Right. In this way the last word from the previous line can be reported
even if the cursor was moved to a new line. But the intention of this patch is
to avoid this situation. The logic is: if the current reported word belongs to
the current reported line => word-by-word navigation, otherwise => line-by-line
navigation.
------- Additional Comment #13 From Calum Benson 2004-10-21 12:41 -------
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs.
Filter on "SUN A11Y SPAM" to ignore.
----------------------------------------
xxxxx@xxxxx.com 10/28/04 14:55 GMT
|
