I'd be inclined to think this is AP2.

Yes, it shouldn't get lost with less important AP3s.

I tried to reproduce this bug and i notice that on a change between paragraphs
gnopernicus reads out the paragraph even the cursor is or not at the beginning
of the paragraph. This is ok.

If the cursor is not at the beginning of the paragraph and press 'down',
gnopernicus reads out the word that "contains" the cursor.

The difference is that not "only the first word of the paragraph line is
output", but gnopernicus outputs the word that "contains" the cursor.

Alexandra's comment is correct.

The question is whether gnopernicus is usable for a blind user trying to
determine what text is on the screen.

It seems that a blind user needs to memorize the entire text spoken for a
paragraph and it is not possible to read by line.

I made some investigations and I believe this is not a gnopernicus issue.

The problem is that function AccessibleText_getTextAtOffset does not return the
correct start/end position for a text line.

When you move using up/down arrow keys between the paragraph lines, gnopernicus
speaks only one word because it reads the text between some ranges which are not
correct.

Dana,

Can you give me an example of where the function AccessibleText_getTextAtOffset
does not return the correct start/end position for a text line?

In yelp, if the cursor is at the begining of a multi line text and you press
down arrow key, the function AccessibleText_getTextAtOffset will return the
start/end position for the first word in the line and not for the entire text line.

What parameters are you calling AccessibleText_getTextAtOffset with and what
start/end values are returned?

Created attachment 27387 [details] [review]
Proposed patch for gtkhtml2

The proposed patch corrects the behavior of getText when LINE_START or LINE_END
is specified.

As this patch does not fix the reportyed problem I am transferring this bug back
to gnopernicus.

Padraig, I can see the correct behaviour on my computer with your patch. I
restarted the computer to see the effect. First (before restarting, but with
patch applied) the behaviour was the same as described in bug.

Please check again.

I ran yelp; activated the links "Desktop", "GnomeDisplayManagerReference Manual"
and "About this Article".

The frist line of the paragraph containing the first link is read , i.e.
Permission is granted to copy, distribute and/or modify this "

After pressing F7 nothing is spoen as the cursor is moved unless in the
paragraph containing the link. 

Padraig, please check on "Desktop", "GnomeDisplayManagerReference Manual" and
"Terms and conventions used in this manual". Seems to be a problem if user moves
from a text which is a link to a text which is not a link.

I am not seeing anything spoken here when I move the cursor. Do I need a patch
for gnopernicus?

This bug depends on bug 143502.

I think the logic for accepting/rejecting caret events when using caret
navigation needs to be relaxed/extended in order to support this case.

I applied padraig's patch from this bug and from #bug 143502 and for me
gnopernicus reports:
If I press:
  a)Up/Down key:
    1. "multi line text  <first line of the paragraph>" -if the line that  
        'contains' the cursor is from a new paragraph that the previous;
    2. " <current line> " - if the new line is from the same paragraph 
         as the one before .
   b) Left/Right:
     1. " <current character> " 
     2. " <current word> " --if I press Ctrl+Left/Right.
I think that those are the correct behaviors.
  
So, for me this bug is fixed, please check it.

I used gnopernicus from CVS HEAD (June 04) and gtkhtml2 from CVS HEAD (June 04)
with the two patches applied.

But, I observe a "strange" behavior.
In the following situation:
"   This is the fist paragraph of the example, named paragraph A.
    This is another paragraph, paragraph B.
    <Link>... [this should be paragraph C and it has a link as "fist word". "
Paragraph C can be replace with a link only.]"

Moving with caret enable from paragraph A to B and from there to C, every thing
is ok. 
Press right until the cursor is 'on' the link, now press Up, paragraph B is not
reported, press Up again until paragraph A, paragraph A is reported. 
 So, when moving Up from a paragraph with link as 'first word', the new
paragraph is not reported.
 This kind of paragraphs can be found in Yelp, the link can be one of those
placed at the bottom of the page. Or launch Yepl-> Desktop-> System
Administration Guide -> Using GConf ->GConf Command Line Tool.

Just to confirm, Gnopernicus saying "multi-line text" in these cases happens
only in Verbose mode, right?  In "normal" mode it is completely silent, right? 
From what I've seen in traffic on gnome-accessibility-list, this is one of the
more objected-to aspects of the Gnopernicus user interface (lots of "multi-line
text" speech)

Alexandra,

Is the "strange" bevahior you describe a bug in gnopernicus or gtkhtml2? If
gtkhtml2, can you specify what function call is giving unexpected result?

Gnopernicus outputs "multi-line-text" for bought situations. 
 In default mode, for 'multi-line-text' gnopernicus outputs:
   <name> <role> <text>
 In verbose mode:
   <name> <description> <role> <text>.

 About the "strange" behavior, I'm still investigating.

Given the feedback we've seen from users, I think in default mode for
'multi-line-text', Gnopernicus should output: <name> <text> (and NOT <role>).

gtkhtml2 patch committed to CVS HEAD.

I made some changes in CVS to report only '<name><text>' in default mode for
multi-line-text.

The remained issue (comment #19) is subject of bug 143502 comment #13.

Please see bug 143502 comment #15, for more example of "strange" behaviour.

This bug is solved with Remus's patch from #bug 143502.