Re: Localized braille (Was: Gnopernicus and ISO-Latin2 characters)

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.

Best regards,


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 gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]