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

[Bill Haneman <Bill Haneman Sun COM>]

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
> declares).
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,

Bill

> 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,
> though.
>
> Regards,
> Samuel
> [1] http://www.unicode.org/cldr
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>