Reported by orcauser on 2011-06-24 16:31
This was a bit tricky to pinpoint, but here it is:
numpad8 and the current line that you are on should be the same.
There is a secondary issue, which maybe related, which is that braille also has problems refreshing with rapid movement and to get it to sync with speech again one has to move up then down again. Unfortunately it look like the log file contains the output of the braille display. Please see attached.
Attachment english-500.txt added by orcauser on 2011-06-24 16:32
Attachment nvda-office-2010.log added by orcauser on 2011-06-24 16:33
Comment 1 by briang1 on 2011-06-25 10:45
Just a few additional questions. Is your machine a single processor, non hyperthreading one? I ask as I tried a demo of 2010, and decided to stay with my old copy of Office xp as it was painfully slow particularly on scrolling stuff.
However if what you describe used to work OK then ignore me totally!
Comment 2 by mdcurran on 2011-06-27 00:37
I cannot reproduce in MS Word 2010. However I was not using a braille display. do the lines get mis-spoken even with out a braille display for you? I shal try with a braille display soon also.
Comment 3 by orcauser on 2011-06-27 07:40
Confirmed, I am unable to reproduce the problem when braille is disabled.
When enabled, the problem appears consistantly again, both using espeak and any sapi5 synth.
Comment 4 by mdcurran on 2011-06-28 03:34
confirmed. now to debug this weridness.
Comment 5 by mdcurran on 2011-06-28 04:19
wdFirstCharacterLineNumber is per-page, not per-document. When braille is enabled we fallback to using range.goto with wdLine, using the line number found with range.information, with wdFirstCharacterLineNumber. Again, expanding selection still seems the most accurate way to get line offsets, but this does cause issues for braille. I need to think about this some more.
Comment 6 by mdcurran on 2011-06-28 04:19
Also, probably not specific to office 2010.
Comment 7 by jteh on 2011-07-01 06:22
Milestone changed from None to 2011.2