Braille display auto-detection feature causes errors on loading braille tables on NVDA startup after including the HUC8 Braille Tables (2019-03-01)

[DrSooom]

Steps to reproduce:

1. Install a portable copy of NVDA 2019.2 Beta-18133 on a USB flash drive as well as on a SSD.
2. Download and include the HUC8 Braille Tables (2019-03-01) into "de-de-comp8.ctb" by following these instructions.
3. Now start NVDA and change the braille output table to German Computer-Braille (8-dot) and disable the checkbox "Expand to computer braille for the word at the cursor".
4. Restart NVDA with debug logging level via NVDA+Q.

Actual behavior:

Sometimes the braille table couldn't be completely loaded if NVDA is running from a USB flash drive. Some ranges of code points couldn't be loaded e.g. U+2800 to U+2855 as well as some definitions from the Latin-1 Supplement Unicode block (U+0080 to U+00FF). This issue is new in NVDA 2019.2 Beta-18133 and it only occurs sometimes, but not always. Maybe you have to restart NVDA multiple times to get that unwanted behavior. If "NVDA ist bereit" (⡝⡧⡙⡁⠀⠊⠎⠞⠀⠃⠑⠗⠑⠊⠞) isn't displayed on the braille display (nothing is displayed), than the braille table couldn't be completely loaded. After pressing any key, which updates the braille output, the braille output seems to work again, but not fully correct due to the partly loaded braille table.

After I have installed a fresh portable version of NVDA to the SSD, the braille table seems now to work as expected, but I still get the following error in the logfile:

SSD logfile:

Touch only supported on installed copies

DEBUG - core.main (15:43:21.563):

Initializing global plugin handler

DEBUGWARNING - braille.BrailleHandler.setDisplayByName (15:43:21.565):

Error in initial display after display load

Traceback (most recent call last):

File "braille.pyc", line 1686, in setDisplayByName

File "braille.pyc", line 1976, in initialDisplay

File "braille.pyc", line 1840, in handleGainFocus

File "braille.pyc", line 1845, in _doNewObject

File "braille.pyc", line 1516, in getFocusRegions

File "braille.pyc", line 615, in update

File "braille.pyc", line 428, in update

File "louisHelper.pyc", line 65, in translate

File "louis_init_.pyc", line 183, in translate

WindowsError: exception: access violation reading 0x2A8A97D0

IO - braille.BrailleBuffer.update (15:43:21.859):

Braille regions text: [u'NVDA ist bereit']

IO - braille.BrailleHandler.update (15:43:21.861):

Braille window dots: 13457 12367 1457 17 - 24 234 2345 - 12 15 1235 15 24 2345

DEBUG - core.main (15:43:21.862):

Initializing core pump

Update – USB flash drive logfile (18:45 CEST):

I was now able to reproduce the error on the USB flash drive. Here is the complete logfile (see line 133 to 188). This error is different to the above mentioned. The "Ä" (U+00C4, ⡰) isn't displayed correctly. It is displayed as ⠠⡌⠭⠬⠬⠉⠙⠠. In other words: This time this Unicode code point and many others aren't defined by the loaded braille table.

Line 154: WindowsError: exception: access violation writing 0x00000000

Additional information regarding the Optelec ALVA BC680:

Regarding the Optelec ALVA BC680 I also get those error entries:

initializing Java Access Bridge support

DEBUGWARNING - brailleDisplayDrivers.alva.BrailleDisplayDriver.init (15:43:21.252):

Traceback (most recent call last):

File "brailleDisplayDrivers\alva.pyc", line 167, in init

File "hwIo.pyc", line 272, in init

WindowsError: [Error 5] Zugriff verweigert

DEBUG - braille.BrailleHandler.setDisplayByName (15:43:21.252):

Reinitializing noBraille braille display

INFO - braille.BrailleHandler.setDisplayByName (15:43:21.259):

Loaded braille display driver noBraille, current display has 0 cells.

DEBUG - brailleDisplayDrivers.alva.BrailleDisplayDriver._handleTime (15:43:21.295):

Time not synchronized. Display time 2019-07-25T15:43:26

INFO - brailleDisplayDrivers.alva.BrailleDisplayDriver.init (15:43:21.302):

Found display with 80 cells connected via hid (\?\hid#vid_0798&pid_0680&col02#6&38174385&0&0001#{4d1e55b2-f16f-11cf-88cb-001111000030})

DEBUG - braille.BrailleHandler.setDisplayByName (15:43:21.303):

Switching braille display from noBraille to alva

DEBUG - driverHandler.Driver.saveSettings (15:43:21.311):

Saved settings for BrailleDisplayDriver alva

INFO - braille.BrailleHandler.setDisplayByName (15:43:21.312):

Loaded braille display driver alva, current display has 80 cells.

DEBUG - NVDAObjects.NVDAObject._get_placeholder (15:43:21.312):

Potential unimplemented child class: <NVDAObjects.window.Desktop object at 0x05443490>

DEBUG - core.main (15:43:21.331):

Initializing legacy winConsole support

This issue could be caused by that prototype ALVA driver written by @LeonarddeR here, which is still used with NVDA 2018.1 (installed version). Maybe it influences the portable versions of NVDA in a negative way. But as this issue also occurred with NVDA 2019.1 (Portable), it isn't really relevant here.

Expected behavior:

No errors as in NVDA 2019.1.1 (Portable). The braille table can be loaded completely again on a USB flash drive, which is mostly much slower than a SSD.

System configuration

NVDA installed/portable/running from source:

Portable

NVDA version:

2019.2 Beta-18133

Windows version:

Win7x64

Other information about your system:

Optelec ALVA BC680 is connected via USB2. But it's the same result if the USB1 port is used.

Other questions

Does the issue still occur after restarting your PC?

Not tested.

Have you tried any other versions of NVDA? If so, please report their behaviors.

Already works as expected with 2019.1.1 (Portable).

[LeonarddeR]

Is this the same issue as #9982?

I"m hesitant to explore the cause of this issue, as it has to deal with tables that currently are no part of liblouis. Furthermore, including tables in other tables isn't something that's going to supported this way by liblouis upstream anyway. We aren't sure whether this is caused by NVDA or liblouis as well.

[DrSooom]

Is this the same issue as #9982?

That could be the case. I decided to open a new issue, because the HUC Braille Tables aren't part of Liblouis yet. Therefore fixing #9982 should have priority.

Furthermore, including tables in other tables isn't something that's going to supported this way by liblouis upstream anyway.

You should take a deeper look into some braille tables. There a quite a lot braille tables which includes other braille tables by using the "include" command. The only different here is that including the HUC Braille Tables will lead to multiple definitions, which has a few side effects.

See also: Issue liblouis/liblouis#688 and liblouis/liblouis#689 and PR liblouis/liblouis#730 as well as NVDA issue #8702 and the FAQ section in the HUC Braille Tables documentation.

[DrSooom]

Closing as no longer reproducible with NVDA 2019.2 RC1 Portable.

[josephsl]

Hi, confirmed, although we will find out if it holds true once 2019.2 stable is installed. Thanks. From: Daniel Mayr <notifications@github.com> Sent: Monday, July 29, 2019 4:03 PM To: nvaccess/nvda <nvda@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [nvaccess/nvda] Sometimes partly loaded braille tables after including the HUC8 Braille Tables (2019-03-01) into NVDA 2019.2 Beta-18133 (#9973) Closing as no longer reproducible with NVDA 2019.2 RC1 Portable. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9973?email_source=notifications&email_token=AB4AXEGZXIWOFYKKH2BX5V3QB5ZL5A5CNFSM4IG334FKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3CIBBY#issuecomment-516194439> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AB4AXEFU7CIXIRUFJNXUUT3QB5ZL5ANCNFSM4IG334FA> .

[DrSooom]

This issue is back in NVDA 2019.2 RC2 (portable).

[DrSooom]

… and also in NVDA 2019.2 Stable (Portable).

[LeonarddeR]

I'm pretty sure this has to do wit liblouis and not with NVDA itself.

@DrSooom Could you please provide some logging with NVDA loggign level set to debug and liblouis debugging enabled in the advanced settings?

[LeonarddeR]

Given the issue descriptions and occurrence in some NVDA versions but not in others, I'm closing this in favour of #9982, which deals with tables that are accessible from NVDA itself and doesn't require manual table overriding intervention to reproduce.

[DrSooom]

I recently updated the issue title due to this and this comment on issue #9982.