William.Walker at Sun.COM
Thu Oct 19 15:03:13 CEST 2006
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?
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,
> > 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
> > gnome-accessibility-list at gnome.org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
> gnome-accessibility-list mailing list
> gnome-accessibility-list at gnome.org
More information about the kde-accessibility