Closed garrettk18 closed 2 years ago
I had a moment, this is a dot 7 and not a dot 8. And, as per a suggestion from a friend, I confirmed this is not a cursor marker.
Hi, I wonder if this is specific to UEB grade 2, or if it is reproducible in grade 1? If yes, I think we may need to dig into what’s going with braille cursor code. If not, chances are that this might be something going on with liblouis. CC @LeonardDer
Possibly related: I think there's a fundamental issue somewhere with what "computer braille" means in UEB Grade 2.
x86
This one goes away when using English U.S. Grade 2 (AKA EBAE). The original issue does not.
Hi, I wonder if this is specific to UEB grade 2, or if it is reproducible in grade 1? If yes, I think we may need to dig into what’s going with braille cursor code. If not, chances are that this might be something going on with liblouis. CC @leonardder
@josephsl This occurs in UEB Grade 1 as well.
I have the feeling that the "Expand To Computer Braille for the Word at the Cursor" option is severely broken. It is most likely that this is a liblouis issue.
cc @Andre9642
Considering a p1 regression, assuming that I understand @leonardder correctly, this was likely introduced by "Update liblouis to 3.13.0 #10832"
See also: Issue liblouis/liblouis#869
I don’t recommend to downgrade liblouis.
Report this issue to the liblouis project.
I'm also not very fond on the idea to downgrade liblouis just for this.
I don't think this has been introduced by LibLouis 3.13. According to the OP's initial commend this has been the case in 2019.2 and 2019.3 as well.
cc: @Andre9642
With liblouis 3.13, I have the same behavior with the following tables (and probably others):
A quick fix to remove dots 7 (not perfect):
*. You can do the same with en-chardefs.cti.
With this change, the main issue is that you can no longer see capitalizations when the cursor is placed on a capitalized word.
According my tests, the problem seems to be introduced between liblouis 3.3.0 (NVDA 2018.1.1) and liblouis 3.5.0 (NVDA 2018.2).
However I compared en-ueb-g2.ctb and en-us-g2.ctb (including sub-tables) from these versions and There doesn't seem to be any important change.
So it's probably a bug in the liblouis core, and I also recommend to open an issue on Liblouis repository.
Has anyone created a bug on Liblouis repository already? If yes, please link the issue here so that we can track it also in this issue. Thanks.
@BueVest and @bertfrees do you know if an issue has already been raised for this?
@feerrenrut Possibly related to https://github.com/liblouis/liblouis/issues/963.
Yes, looks like the same issue.
It appears that https://github.com/liblouis/liblouis/issues/963 is closed and NVDA is using a version with the fix https://github.com/liblouis/liblouis/pull/1123
Steps to reproduce:
Hello, world!
Actual behavior:
There is a dot 6 before the 'h' and a dot 7 under the letter (i.e., ",Hello" instead of ",hello".
Expected behavior:
There should only be a dot 6 preceding the 'h' in "Hello".
System configuration
NVDA installed/portable/running from source:
Installed
NVDA version:
2020.1RC1
Windows version:
Windows 10 1909 build 18363.778
Name and version of other software in use when reproducing the issue:
Notepad (webpages, ETC. will work as well).
Other information about your system:
Other questions
Does the issue still occur after restarting your computer?
Yes
Have you tried any other versions of NVDA? If so, please report their behaviors.
2019.2.x: Same behavior 2019.3: Same behavior
If addons are disabled, is your problem still occuring?
Yes
Did you try to run the COM registry fixing tool in NVDA menu / tools?
No