Jamie, The reason for the odd high-order byte is that liblouis uses virtual dots 9 through e so that it can uniquely represent characters such as accented letters. For your purposes you can just ignore the high byte, as you are doing. The problem with dots 7-8 is more difficult. I will have to look into it and see if there is a fix for the next release. That will be as soon as I find some problems with the Nemeth math tables. I have been following the development of NVDA with great interest and will try it on my Vista Ultimate box as soon as braille support is working. John On Mon, Sep 15, 2008 at 09:17:16PM +1000, James Teh wrote: > Hi all, > > I am one of the core developers of NVDA (http://www.nvda-project.org/) > and am currently in the process of implementing braille support for > NVDA. We're using liblouis for braille translation. > > Rather than having liblouis output braille in text form, I prefer to > have the braille output in dot patterns. This eliminates the need for > the braille display driver to be aware of braille character set tables > and the like. (Even though we can use brltty, I'd rather users not have > to deal with two sets of braille table configuration.) Thus, we use > liblouis with the dotsIO mode. > > One oddity I discovered with dotsIO is that it seems to produce dot > patterns with the highest order bit in the widechar set. With a 16 bit > widechar, this means that everything has a base of 0x8000. This is > easily fixed by simply ignoring the higher order byte, but it seems > strange nevertheless. > > Now for the actual purpose behind this email: > Because we use dotsIO, we are using liblouis even for translation into > computer braille. However, using en-us-comp8.ctb as my translation > table, dots 7 and 8 are not ever set for capital letters and the like. > If I use the compbrlAtCursor mode and specify a cursor position, the > expanded word contains dots 7 and 8 if appropriate, but none of the > other braille does. I can specify computer_braille (8) as the typeform > for every character to manage this. However, I was hoping that the user > would just be able to set the appropriate braille table and have it use > dots 7 and 8 if appropriate. > Is there some table other than en-us-comp8.ctb that I should be using to > achieve this? > There is a mode constant named comp8Dots which I figured might achieve > this. However, this constant is never checked in the source; the mode is > unimplemented. > Is there any other way to achieve this? > If not, what is the reason for this behaviour and is there any chance of > it being changed? > > Thanks! > > Jamie > > -- > James Teh > Email: jamie@xxxxxxxxxxx > WWW: http://www.jantrid.net/ > MSN Messenger: jamie@xxxxxxxxxxx > Jabber: jteh@xxxxxxxxxx > Yahoo: jcs_teh > For a description of the software and to download it go to > http://www.jjb-software.com -- My websites: http://www.godtouches.org http://www.jjb-software.com Location: Madison, WI, USA For a description of the software and to download it go to http://www.jjb-software.com