Braille cursor tracking confused when moving through unicode characters

[nvaccessAuto]

Reported by mdcurran on 2009-12-06 07:53
When viewing the following line on a braille display with NVDA and UEBC grade 1 and no expand to computer braille:

The middle character in x�x is not handled properly.

(there is a 0x7f character between the two x characters).

When arrowing through the characters up to the first x, everything is fine.
When on the x, the braille cursor is on the x (after the letter sign).
When moving one character right (on to the unicode 0x7f character) the braille cursor is now under the lettersign of the first x (i.e. it moved one cell to the left).
When moving one character right (now on the second x) the braille cursor is correctly on the second x (after the lettersign).

Note that this problem seems to occure for any unicode character where its escape hex number is printed on the display. E.g. if I type some english but include some Chinese characters on the same line.

Guessing this is an issue with libloui and mapping input offsets to output offsets?

Blocking #484

[nvaccessAuto]

Comment 1 by mdcurran on 2009-12-06 08:05
Some further odities, which may be related:
*A hex unicode character will not be printed at all on the display if it is the first character on the line and there is less than two characters after it.
*A hex unicode character as the first character on the display with two alphanumeric characters after it: when arrowing through the line the braille cursor starts moving through the \xHex representation.
*A hex unicode character at the end of the line will only be printed on the display if there are at least 4 other characters before it.

[nvaccessAuto]

Comment 2 by mdcurran on 2009-12-06 08:12
One more note:
Using English 6 dot computer braille as the table the original problem no longer exists. However the further problems (unicode characters not appearing depending on amount of characters) still exist.

[nvaccessAuto]

Comment 3 by jteh on 2009-12-07 04:01
Definitely a liblouis bug. The position arrays aren't being updated correctly when the unknown characters are being replaced.

[nvaccessAuto]

Comment 4 by jteh on 2010-01-19 04:05
Changes:
Milestone changed from 2010.1 to 2010.2

[nvaccessAuto]

Comment 6 by jteh (in reply to comment 1) on 2010-07-27 03:38
Replying to mdcurran:

Some further odities, which may be related:

*A hex unicode character will not be printed at all on the display if it is the first character on the line and there is less than two characters after it.

*A hex unicode character as the first character on the display with two alphanumeric characters after it: when arrowing through the line the braille cursor starts moving through the \xHex representation.

*A hex unicode character at the end of the line will only be printed on the display if there are at least 4 other characters before it.

These are all due to the Python bindings not providing a large enough output buffer to liblouis. I've proposed some ideas and am awaiting feedback on the liblouis community on the best way to fix this in the Python bindings.

[nvaccessAuto]

Comment 7 by jteh (in reply to comment 3) on 2010-08-03 08:41
Replying to jteh:

Definitely a liblouis bug. The position arrays aren't being updated correctly when the unknown characters are being replaced.

I fixed this in liblouis svn r365.

[nvaccessAuto]

Comment 8 by jteh (in reply to comment 6) on 2010-08-04 17:38
Replying to jteh:

These are all due to the Python bindings not providing a large enough output buffer to liblouis.

I fixed this in liblouis svn !r371.

However, we also now have another option. We can specify that undefined characters be displayed with a certain character (e.g. space) instead of displaying the hexadecimal value. I think this is more user friendly for screen reader users.

All of this will be in the next liblouis release. I can try to request one, but I want to wait to see what happens regarding the proposed changes to the Danish tables, as an NVDA user has requested this.

[nvaccessAuto]

Comment by jteh on 2010-08-05 08:10
(In #484) Confirmed. These are liblouis bugs.

The problems exhibited in steps 8 and 9 should be fixed by my changes to liblouis as part of #499.

I understand what is causing the earlier problem, but don't know how to fix it yet.

[nvaccessAuto]

Comment 10 by jteh on 2010-08-19 09:22
Fixed in liblouis 2.1.0. We now require liblouis 2.1.0 in 0264986.
Changes:
State: closed