Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

NVDA miss-reading lines in word 2010 (regression) #1603

Closed
nvaccessAuto opened this issue Jun 24, 2011 · 9 comments
Closed

NVDA miss-reading lines in word 2010 (regression) #1603

nvaccessAuto opened this issue Jun 24, 2011 · 9 comments
Labels
bug component/speech
Milestone
2011.2

Comments

@nvaccessAuto
Copy link

Reported by orcauser on 2011-06-24 16:31
This was a bit tricky to pinpoint, but here it is:

  1. open word 2010
  2. open english-500.txt from location on disk.
  3. arrow down as usual to read lines.
  4. 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.

expected output:
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.

Thanks.
@nvaccessAuto
Copy link
Author

Attachment english-500.txt added by orcauser on 2011-06-24 16:32
Description:

@nvaccessAuto
Copy link
Author

Attachment nvda-office-2010.log added by orcauser on 2011-06-24 16:33
Description:

@nvaccessAuto
Copy link
Author

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!

@nvaccessAuto
Copy link
Author

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.

@nvaccessAuto
Copy link
Author

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
  • 1gb real ram for the vm, running on an I7 system.

Thanks

@nvaccessAuto
Copy link
Author

Comment 4 by mdcurran on 2011-06-28 03:34
confirmed. now to debug this weridness.

@nvaccessAuto
Copy link
Author

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.

@nvaccessAuto
Copy link
Author

Comment 6 by mdcurran on 2011-06-28 04:19
Also, probably not specific to office 2010.

@nvaccessAuto
Copy link
Author

Comment 7 by jteh on 2011-07-01 06:22
bead0ae
Changes:
Milestone changed from None to 2011.2
State: closed

@nvaccessAuto nvaccessAuto added this to the 2011.2 milestone Nov 10, 2015
@nvaccessAuto nvaccessAuto mentioned this issue Nov 10, 2015
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug component/speech
Projects
None yet
Milestone
2011.2
Development

No branches or pull requests
1 participant
@nvaccessAuto