Re: Annoucing libbraille

Sébastien Sablé <sable users sourceforge net> writes:

> I have been working for some time on a project called libbraille, which
> I think could be useful for kde and gnome accessibility.
> Libbraille is a shared library which makes it possible to easily access
> Braille displays and terminals. It provides a simple API to write text
> on the Braille display, directly draw Braille dots, or get the value of
> pressed keys. It is compatible with a wide range of Braille displays and
> can autodetect some of them.

"wide range" is a very stretchable term indeed.  If I look at the
braille display hardware I personally use at work and at home:
* HandyTech Braille Star: libbraille only appears to support
the serial port of HandyTech displays, no support for USB or
the recently installed bluetooth connectivity.  On my laptop, I
have no serial port, so the display would be completely unusable
without a USB-to-serial adapter with only libbraille.
No support for the external keyboard either.

Telesensory Inc. PowerBraille 40/80: I couldn't find any
driver in libbraille for those displays at all.

So, of the three available displays I have, only one is very
partially supported by libbraille.  That doesn't look too good to me, and I am
a bit afraid of such a driver base being adopted in any major
desktop project as the primary braille library.

> Some features include:
> * support for serial and USB displays

BRLTTY supports the following display models via USB:
Alva Satellite, Freedom Scientific displays, Papenmeier EL 40 Slimline,
HandyTech Braille Star/Braillino and the Tiemand Voyager.

From what I can see, you currently only seem to support
the Alva satellite displays via USB.

> * usable from C or as a Python module or as a Java extension

libbrlapi is also usable from C, and bindings to other languages
should be reasonably simple to implement.  In fact, I wrote
a binding for GUILE a year ago in about 2 hours IIRC.

> * distributed under the LGPL Free Software Licence

BRLTTY's BrlAPI is also distributed under the terms of the LGPL, at
least all the code required for the client side library is LGPL.

> * portable (linux, win32, MacOS X, FreeBSD, Solaris and probably other
> unix systems)
BRLTTY has been ported to Solaris, HP-UX, OpenBSD, FreeBSD
and NetBSD.

> * provides a virtual graphical terminal so that developers without a
> Braille display can develop and test their application with a (Fake)
> Braille display

Such a "fake" display has just been added to BRLTTY in the
development repository, actually two: One for TTY's, and one for XWindows.
BRLTTY 3.5 (the last release) includes a "Virtual" driver which
allows one to write his own client (freedom of choice of toolkit).

> * supports blocking or timeout mode for reading Braille keys
Same for BrlAPI.

> * usable directly from Mozilla in JavaScript as an XPCOM component

In the end, I am more than glad to see yet another free software
developer working on Braille terminal issues, but I am very
sad about yet another fork.  I think it can not be good
for the user-base if we have several driver code bases with varying quality.

Note that yet another issue is sharing devices between several applications.
You were criticizing the fact that BRLTTY is a daemon and does
console screen reading by default in some other mail.  This is actually
a big advantage to some, since it allows for different screen readers
to cooperate nicely without running into device locking problems.
If I configure Gnopernicus for instance to use BrlAPI as braille output
backend, I can switch between text and graphical consoles back
and forth without any problems.  As long as a text console
is current, BRLTTY does its screen reading job, and as soon as
my X Window console is current, Gnopernicus gets to write
to the display.  I think this is even more important
if we consider that KDE is entering the picture in the future.

Yet another important feature of BRLTTY is that it
does not require any components from the /usr filesystem hierarchy, making
it possible to run very early in the system boot process when /usr
is not mounted yet.  This is vital to enable blind
users to administer their systems as independently as possible.
Since libbrlapi lives in /lib, BrlAPI clients can
inherit this property from BRLTTY.


Attachment: pgp1gFTMNWE30.pgp
Description: PGP signature

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