Hi All: I think a while back we had the discussion of rolling better i18n support (e.g., a lot of the extra stuff that gnome-braille does) into BrlTTY/BrlAPI, thus simplifying the setup and use of braille. It also puts the functionality into the hands of people who are properly resourced to support it. I thought we concluded that was probably the right way to go.
What happened to that idea? Will On Thu, 2006-10-19 at 00:04 +0100, Bill Haneman wrote: > Samuel Thibault wrote: > > As discussed a few months ago, gnome-braille depends on > > - libgobject for contraction/language module management > > - libglib for tricky stuff like unicode handling. > > > I don't have any objection to reworking this to remove > GObject, but it makes no sense to do that without removing the glib > dependency as well. The problem with removing glib is that > gnome-braille needs very sophisticated unicode support, which is much > harder to come by that one would think. > > If we have a fully desktop-agnostic unicode library alternative then I'd > be happy to work on swapping out glib/gobject. The other problem though > is that gnome-braille is very modular/object-oriented and trying to do > nice lifecycle management in C without something like GObject is not > much fun. > > So what does gnome-braille do that BriAPI and libbraille don't already > do? Well, it provides an extremely general pluggable/chainable > conversion API (so that very complex braille conversions can be done, > like all sorts of Grade2 and Asian language braille), > multi-lang/multi-locale braille, optional braille context switching > markers, and some other localization stuff. Also, it provides a > bidirectional mapping between braille cell offsets and character/glyph > offsets throughout, so you always know what braille cell corresponds to > which character offset in the input string. As far as I know, these are > things that the other APIs either don't offer or have difficulty with. > > gnome-braille also supports several sorts of hardware and software > events, and both hardware and software "regions" within a braille display. > > This is all stuff that probably isn't urgent for our English braille > users _yet_, but which I think will become increasingly important as we > get the more fundamental platform stuff working well. While I wrote > gnome-braille as a testbed initially, it'd be very nice if we could > morph it into something everybody could make use of. It already has > support for about 40 languages including some exotic stuff like > Devanagari/Hindi and Kanji Japanese braille; it also has a simple Grade2 > English engine. > > Best regards, > > Bill > > Else it can be used in any application, the output being done either via > > BrlAPI or libbraille (or a gtk fake braille device) > > > > Samuel > > _______________________________________________ > > gnome-accessibility-list mailing list > > [email protected] > > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > > > > _______________________________________________ > gnome-accessibility-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list _______________________________________________ gnome-accessibility-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
