[Accessibility] Re: Localized braille (Was: Gnopernicus and
Bill.Haneman at Sun.COM
Fri Aug 26 06:43:47 PDT 2005
Hi Samuel, All:
I really look forward to re-activating work on 'gnome braille' in this
context. I agree that we should aim for a single library for
international braille, and would love to take it out of the 'gnome
namespace' and make it more of a freedesktop project. I'll comment on
some of Samuel's observations below...
Samuel Thibault wrote:
>But more than that, it would be useful to have a single library using
>these tables, that every software would be able to use. Because
>elaborating braille is _not_ an easy task at all :)
>The experimental gnome-braille software from Bill is a bit similar
>to such library. In a few words (please correct me if I'm wrong), it
>is able to turn utf-8 text into braille dots and display them via
>libbraille or on braille mon. It takes into account the limited width of
>the actual display, and lets the application control how it is scrolled.
By using UTF-8 internally (though we can accommodate any input format,
in theory), we ensure that mixed language braille can be handled, for
those cases where it is desirable. Important use cases include foreign
language texts, "Loaner words", web content, and mixed Latin/non-Latin
text which is very common in some locales.
>Some examples of issues that I personally see are that it uses
>libgobject and libglib, while screen readers tend to be as small as
>possible, for embedded devices or installation images ;
I gave a lot of thought to the use of glib; basically it does two
important things. Firstly, it easily allows for an Object-oriented
pluggable architecture in C, which is important because of the many
different types of braille encodings and drivers which we need to
support. We could consider using another language, which might
eliminate the need for GObject and GInterface, but this would introduce
other issues. In any case the GObject dependency is something that
could be eliminated if the benefits were significant enough; remember
though that glib is quite portable and runs on many platforms, not just
Linux/Unix/BSD, and is readily available for embedded devices. The
second reason for using glib is more important in my opinion - as
Sebastien has pointed out, unicode manipulation for braille is quite
complex, and we clearly must avoid implementing our own unicode
processing library in this braille code. This is not just because of
the undesirability of code duplication in general, but more importantly
the need for timely one-spot bugfixes; no unicode library is bugfree,
and the unicode standard continues to evolve, so getting it right is not
a trivial task.
> the features
>that gnome-braille proposes also seem a bit mixed: it proposes braille
>translation, display width management and braille output, all in one,
>while I would have rather seen 3 separate libraries.
Gnome-braille treats these as separate interface classes, so it does
distinguish between them. However it turns out that braille output and
braille encoding/translation do need to be fairly closely coupled at
least at the level that gnome-braille handles them; this is because of
the importance of mapping braille cell positions to character offsets.
Unless the encoding and output libraries are designed to communicate
this information to one another, you can't remap the output cell
positions to the original input string properly. Gnome braille keeps
the display-dependent part of the output code separate though; for
instance gnome-braille would probably have a single "BrlAPI" driver,
rather than have separate drivers for specific types of hardware. I
don't think we want to duplicate effort in this area, as long as we can
be confident that BrlAPI can be used to implement what we need.
>I guess that for instance Brass/brltty/suse blinux would rather be
>interested in a very simple library, with no libgobject/libglib
>dependency, which just provides localized braille translation (actually,
>roughly what gnome-braille's braille-encoder.h and braille-table*.h
I don't think you can do this effectively without the UTF-8/unicode
library, and you need some Object/Interface model to base your classes
on if you wish to use C.
The braille tables along don't give you that much by themselves - you'd
have to re-implement the state machine logic (which will be evolving
over time), and the back-translation of cell coordinates to character
offsets, which for some languages and brailles is quite nontrivial.
Also the gnome-braille framework is designed to include non-table-based
encoding, which is a requirement for Grade 3 and other highly-contracted
forms of braille.
> It could be seen as a braille equivalent to the mb*towc*(),
>iconv(), setlocale() etc. functions, so I'm not sure whether this should
>remain in the gnome project. Erkki, maybe you would have more precise
>opinion on this?
>Gnopernicus could then be interested in a complementary library that
>takes care of screen width and scrolling.
>And eventually, for applications (or even gnopernicus, I don't know),
>facilities to connect that to actual output (braille monitor / BrlAPI /
>libbraille) could be useful indeed.
>Well, that was just to give a first opinion. This really needs discussed
>somehow. Probably not using all those mailing lists but some new list,
>gnome-accessibility-list mailing list
>gnome-accessibility-list at gnome.org
More information about the Accessibility