Reported by orcauser on 2011-06-24 16:31
This was a bit tricky to pinpoint, but here it is:
open word 2010
open english-500.txt from location on disk.
arrow down as usual to read lines.
in quick succession, page down twice or three times.
At this point the lines that nvda is reading do not reflect the document.
When you up/down arrow, it seems that nvda is still reading from the first page, but if you use numpad 8, the correct line is being read.
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.
The text was updated successfully, but these errors were encountered:
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.
Using braliant 64 and baum driver,
Testing in a virtualmachine, running windows xp sp3
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.