Another test case:

1. Open OpenOffice 2.0.3 and press Ctrl+n or choose 'new document' option in
File menu.
2. Write some lines of text
3. Locate the cursor in the top left corner of the document
4. Press KP+ to get a "say all"

  Only the first line is read, but if you restart orca and try to  make a "say all" again, the whole document is read.

I can now reproduce this problem. Orca seems to read as far as the end of the first paragraph marker and then stop.

This is also present in OOo 2.0.4 RC1.

Okay, I've tried this with Open Office 2.0.4 with latest Orca
on my Solaris box. I tried it with a fairly extensive document
and Numpad-+ happily spoke it.

Could somebody please attach a Open Office test file that fails 
for them, and I'll give that a try.

Thanks.

Rich, in my experience, what Juan said in his original report, namely: "It only happens when you create a new document, not when you open an old document" is true. So how 'bout a test case instead: :-)

1. Launch Orca (I have the build from yesterday afternoon)
2. Launch OOo 2.0.4 (I have RC2)
3. Type "This is a test."
4. Press Enter.
5. Type "So is this."
6. Press Control Home
7. Press NumPad +

My results:  The first line is read.  The caret moves to the end of the first line.

This is with the latest Edgy.  I suppose I need a Solaris box for comparison....

Created attachment 73158 [details]
Orca debug generated reprodicing this per Joanie instructions.

Thanks. I've reproduced it on Solaris with OOo 2.0.4 and latest
Orca.

Note that after I'd terminated Orca with Insert-q and saved away
the debug file, I restarted Orca. Ooo was still running with this
test document in it. My cursor was at the end of the first line.
In hit Home to get to the begging of the line and then Numpad-+.
Orca happily spoke both lines.

So there is something funky about the specific test scenerio you gave me.

I'll investigate further...

The problem is caused because sometimes the OOo text paragraph
doesn't have a atspi.Accessibility.RELATION_FLOWS_TO relationship,
that would point at the next paragraph to speak.

This is checked for in util.textLines() at about line 551.
I'm going to try to generate a standalone Python script that
will replicate the problem. If I can do that, I'll file an OOo
bug and add a "[blocked]" tag to the summary for this one.

I've opened an issue in OpenOffice against this problem. See issue #69753.
http://www.openoffice.org/issues/show_bug.cgi?id=69753

Adjusting the summary for this issue to show that it's blocked on this other
problem.

Add accessibility keyword.  Apologies for spam.

Created attachment 75413 [details] [review]
Patch to remove caching of relation sets.

If I apply the attached patch so that Orca no longer caches
relation sets, Orca will do a "say all" of all the text.
There is still a problem here though in that there is a subsequent
"object:state-changed:focused" event which causes the last line to 
be spoken again:

vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv
OBJECT EVENT: object:state-changed:focused             detail=(1,0)
    app.name='soffice.bin'        name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE FOCUSED MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_FROM FLOWS_TO'
Finding top-level object for source.name=None
--> obj.name='Document view'
--> obj.name=None
--> obj.name=None
--> obj.name='Untitled1 - OpenOffice.org Writer'
--> obj.name='Untitled1 - OpenOffice.org Writer'
LOCUS OF FOCUS: app='soffice.bin' name='' role='paragraph'
                event='object:state-changed:focused'
OBJECT EVENT: object:state-changed:focused             detail=(1,0)
             app.name='soffice.bin'        name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE FOCUSED MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_FROM FLOWS_TO'
StarOffice.locusOfFocusChanged - Writer: text paragraph.
SPEECH OUTPUT: 'So is this.'
GENERATOR: _getBrailleRegionsForText
           obj             =
           role            = paragraph
BRAILLE LINE:  'So is this. $l'
     VISIBLE:  'So is this. $l', cursor=12
^^^^^ PROCESS OBJECT EVENT object:state-changed:focused ^^^^^


Will, what do you think is the best approach to solving this?

Should I go ahead and check in the "remove caching of relation
sets" patch?

Removing the "blocked", as we aren't.

Rich: eliminating the relations cache is probably the right thing to do.  If we find we take a performance hit, we could potentially optimize by caching for things whose relations we're pretty sure will not change (e.g., labels?).

As for the focus event - what is causing that to happen?  I'm confused if it is SayAll because all we're doing is querying for info and not changing state in OOo, right?

When you do the "say All" function in swriter with Orca
(Numpad-Enter), it moves the taxt cursor to the end
of the last line spoken. That's what is causing the 
object:state-changed:focused event.

Ahh...thanks.  Not sure what to do here.  Maybe call orca.setLocusOfFocus (with notifyPresentationManager=False) with the object whose text/caret we're mucking with before we muck with its text/caret?

Sorry, I have no idea what your last sentences means. 
Could you expand it a bit?  

Note that OOo behaves different then say gedit. Imagine you
enter the following two lines into the application.

Line 1
Line 2

Both of those lines have a newline at the end of them.

After doing a "say all" with gedit, the text caret is moved
to the line *after* "Line 2".

After doing a "say all" with OOo writer, the text caret is moved
to the very end of "line 2".

This seems inconsistent to say the least.

I suspect if gedit had moved the cursor to the end of "line 2"
after a "say all", we would be saying that line twice as well.

default.py, lines 829, 832 do this upon interruption/completion of SayAll:

 context.obj.text.setCaretOffset(context.currentOffset);

Maybe these lines should do this:

 orca.setLocusOfFocus(None, context.obj, False)
 context.obj.text.setCaretOffset(context.currentOffset)

The idea here is that maybe OOo is issuing a focus event for the paragraph when the caret offset is set - try debugging a bit to see if this is what is happening - I'm just surmising this might be what is happening.  In gedit, I don't think were getting any sort of focus event (e.g., focus: or state-changed:focused) because we're always in the same object.  In OOo, we potentially jump from paragraph to paragraph.  Thus, if a setCaretOffset causes a focus event to be issued, Orca will respond and speak the current line of the text object.  By preventing a focus event from being propagated, this won't happen.

Created attachment 75456 [details] [review]
Patch to hopefully fix the problem.

Thanks Will. This seems to nicely fix the problem.

Changes checked into CVS HEAD. They seem to work nicely for me.
Could others please test this as well, to see if this is fixed.
Thanks.

  It works fine for me with the last CVS Orca code. 
I am using  Ubuntu edgy and OpenOffice 2.0.4 

   Thanks
   Juan Ramón

Thanks Juan Ramon!  Closing as FIXED.