[BRLTTY] Final release of brltty 3.8?

[Samuel Thibault]

Willie Walker, le Wed 21 Feb 2007 10:35:46 -0500, a écrit :
> >>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.  :-)

Mmm, isn't that already the case?!
I mean, UTF-8 strings should already work.  Now, brltty is currently
limited to 256 characters table.  Using unicode tables (for coping with
mixing languages and hence need more that 256 characters) is on the
schedule for post-3.8.

> >>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.

BrlAPI is a low-level way to access braille devices.  Contraction seems
to me too advanced to put here.

> 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.

That's what we end up with as a solution, yes.

> 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?

BrlTTY could also use gnome-braille instead of having its own
contraction tables.

The ground idea for this is that things like contraction tables, just
like device drivers, should be shared.

Samuel