braille cursor position incorrect on words after letter/capital/number/math signs when expand to computer braille enabled

[nvaccessAuto]

Reported by miahtech on 2013-01-26 05:45
I only noticed this by accident, not sure how often this odd bug pops up, but I can give you at least 1 replicatable situation:

1. Bring up a text field, notepad or whatever.
2. Paste this line:
   53rd Avenue, and, Al tura Street.
3. Have your settings set for Unified English Braille Grade 2, Expand to computer braille for the word at the cursor, blink rate 0, and Braille tethered to focus.
4. Now, try to use cursor routing keys anywhere in the word Tura. While the routing keys will move the actual cursor, the Braille display cursor remains stubbornly on the last letter of the word.
   I encountered this while working on something today; not sure how often this bug would show up, or if it happens on other setups than mine, but figured I'd drop it here.

[nvaccessAuto]

Comment 2 by mdcurran on 2013-01-28 20:33
From my testing the issue seems to be a lot bigger than just cursor routing on Pacmate.
It seems that, from NVDA 2012.2 at least, When ever the cursor is within a word that is after a word that contains a letter sign, number sign or capital sign, and expand to computer braille is on, the cursor is usually positioned at the end of the word, no matter where it really is supposed to be within the word.
I personally always use a grade 1 table and no expand to computer braille so I've never seen the bug until now. I'm surprized no other users ever reported this... unless my testing is somehow faulty? ??
Changes:
Milestone changed from None to 2013.1

[nvaccessAuto]

Comment 3 by mdcurran on 2013-01-30 04:24
Changes:
Changed title from "Odd Behavior with cursor Routing with Pac Mate 40 cell Display" to "braille cursor position incorrect on words after letter/capital/number/math signs when expand to computer braille enabled"

[nvaccessAuto]

Comment 4 by jteh on 2013-01-31 23:49
This is a bug which should be fixed in the next version of liblouis. In the meantime, I've worked around this in cbf8368.
Changes:
State: closed

[LeonarddeR]

I can no longer reproduce this with cbf8368 reverted, so I'm pretty confident that this is fixed upstream now.