Right now, if an input character doesn't make sense, it's being interpreted as
a computer braille character. To give you a context, I'm getting typed input
from a braille keyboard and feeding it to liblouis as Unicode braille pattern
characters.
For example, if, when using UEB, I accidentally type the EBAE ⠖⠛ (to go), the
first character, ⠖ (to) is interpreted as 6 (the digit 6). While a braille
typist won't detect this error, it makes for some rather interesting surprises
when the back translation is read by a sighted person or spoken via a speech
synthesizer. In this case, for example, a sighted person reads 6g (the digit
six, followed by the letter g) and the Android speech synthesizer says "six
grams".
I've worked around this with a translation cache which I preset as each
character is being typed, but I think the solution would make more sense within
liblouis itself. What I'm suggesting is that Unicode braille pattern characters
(U+28xx) in the input stream should stay as themselves (rather than be
interpreted as some unexpected computer braille equivalent) if they don't make
sense (yet) with respect to the current translation table.
The reason I'm saying "yet", here, is because of contractions that require more
than one braille character, e.g. ⠐⠞ (time). If the first characer, ⠐ (dot 5),
is kept as a Unicode braille character then all the right things happen when
the ⠞ (letter t) is typed. As it is now, the ⠐ (dot 5) is turned into a
quotation mark, and then, when the ⠞ (letter t) is typed, it ends up being ⠐⠦⠞
(an opening quote, followed by the letter t) instead of the word "time".
--
Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/
EMail: Dave@xxxxxxxxx | Canada K2A 1H7 | http://FamilyRadio.org/
For a description of the software, to download it and links to
project pages go to http://liblouis.org
