[BRLTTY] Final release of brltty 3.8?

[Willie Walker]

> About the USB issue, IIRC the solution that was found was to just drop
> (0x0403,0x6001) from the udev rule so as to avoid starting brltty when
> plugging serial boards that have the same IDs (since that's the board
> embedded in the HandyTech device), wasn't it?

I'm not sure of what works where, but I've not been able to get either 
3.7.2 (which is the BrlTTY version that comes with Feisty) or BrlTTY 
from SVN to connect to my Baum Vario 40 hanging off a Keyspan USA-19HS 
dongle on my Feisty box, which is up-to-date as of last night.  I 
suspect this is a Feisty issue and not a BrlTTY issue since I've had 
success with doing this configuration on Edgy.

I've been looking at these things, but I'm not sure how they might apply 
to my configuration:

https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/80892
https://launchpad.net/ubuntu/+source/brltty/+bug/83939

>> 1) Internationalization support
> 
> What do you mean by this? Different braille tables? (that's on the
> schedule)

I want to be able to throw UTF-8 strings at BrlAPI and have the "right 
thing" happen.  :-)

>> 2) Grade 2 braille, both displaying it and handling cursor routing keys
> 
> As already discussed, that should probably be handled by something like
> gnome-braille.

I keep getting confused about the discussion and need to better 
understand where the support starts and ends in BrlTTY/BrlAPI.  I see 
contraction and translation tables in BrlTTY, which is probably the 
source of my confusion.

Is the proposal on your part the following:

1) An assistive technology such as Orca would use BrlAPI only for saying 
which dots are to be popped up or down and for determining which buttons 
the user has pressed on the display.

2) Orca would use a separate package, such as gnome-braille, to convert 
UTF-8 strings to a set of cells/dots and also for mapping a given cell 
to a character in a string.  As such, all communication between from 
Orca to BrlAPI would be at the raw "put these dots in these cells" level 
instead of "display this string and put the cursor here" higher level as 
we do now.

With this, Orca and the separate package would be in complete control of 
allowing for things such rapid switching between contracted/uncontracted 
braille and for handling multiple locales.

If this is the case, where do the BrlTTY contraction and translation 
tables come into play, and how do we make sure the user sees the same 
dots for the same strings when switching between BrlTTY on the console 
and Orca on the desktop?

Thanks!

Will