[BRLTTY] Re: gnome-braille

[Bill Haneman]

Hi Samuel, Will, Dave...

Samuel said:
> Of course, this should probably be developped jointly with
> gnome-braille.
>
> Samuel
For the record, I'd be delighted to work with Dave and the BrlTTY 
community to move gnome-braille's functionality to BrlTTY/BrlAPI.  It 
sounds as though the sort of higher-level library you are thinking about 
may be the right opportunity.
For CVS browsing see http://cvs.gnome.org/viewcvs/gnome-braille/

To do this, we'd need to remove the glib and gobject dependencies from 
gnome-braille (assuming we can reuse much of the existing code, 
otherwise) - I think this is quite feasible, but there's no reason to do 
so unless the community wishes to make use of what has been, up until 
now, mostly a proof-of-concept braille library.  Currently gnome-braille 
does have a BrlAPI back-end (not sure what version of BrlAPI though), so 
gnome-braille can be used with any braille display BrlTTY supports, as a 
client wrapper library.

Sebastien Sablé has done some work to exercise gnome-braille, and there 
have been numerous community contributions to its list of braille 
locales (about 40 at last count, including some fairly tricky Asian 
locales that need proofing by a native reader). 
See http://cvs.gnome.org/viewcvs/gnome-braille/tables/

I will note a few of the things gnome-braille was intended to do which 
may be important to braille clients (in particular, the things Will 
mentions below):

(and Will replied ...)

> Gnome-braille is definitely a good thing to talk about.  At some point
> > soon, we want to make sure we have the following in Orca:
> > 
> > 1) Good support for multiple locales
> > 2) Good support for Grade 2 braille
> > 
> > For both of these, we'd really like to be able to just toss UTF-8 text
> > to BrlAPI and have it display the right thing.
>   
>
> I think this already works right now.
>   
However BrlAPI/BrlTTY doesn't currently support Asian languages except 
vietnamese, as far as I can tell.  Asian language braille codes tend to 
break the usual table-lookup variety of encoding engines, and to the 
best of my knowledge BrlTTY would have problems with them as well.  We 
also need to support mixed-locale braille, eventually - in English and 
latin-languages, the end user can usually do context detection/switching 
when reading dots, but some use cases (for instance a language text for 
an Asian language - or even some of the more esoteric 'english' brailles 
such as music braille and mathematical brailles) make this more 
challenging. 

Support for Asian and grade2 brailles, and support for multi-locale and 
multi-contextual braille, were two of the main motivations for 
gnome-braille.  Another one is the ability to "chain" encoding engines, 
which is useful for supporting Japanese braille, grade 2 brailles, and 
some other use cases.
>> >  In addition, we'd like
>> > to determine UTF-8 character offset from cursor routing keys versus the
>> > Grade 2 braille cell offset.
>>     
>
> About that I don't know what ispossibl an what isnot.
>   
Currently I don't think BrlAPI exposes this info, and it may not even 
retain it internally.  Retaining bidirectional transformation mapping 
from character offsets to braille cells (even with chained encoding 
operations) was the other primary design goal.  For a chained-encoding 
example, see 
http://cvs.gnome.org/viewcvs/gnome-braille/tests/test-kakasi-wrapper.c

Perhaps I am wrong about the bidirectional mapping, but my understanding 
from Will is that this info is currently not available via BrlAPI, thus 
it is difficult to effectively use brailles that don't have a 
one-cell-per-character implementation.

If you folks are interested in looking at pulling part or all of 
gnome-braille into BrlTTY I'd be happy to continue the discussion (note 
however that I will be on holiday from later this week until January)

Best regards,

Bill

> Cheers,
> Sébastien.