Distributing braille documens digitally, suggestions please

Samuel Thibault samuel.thibault at ens-lyon.org
Fri Oct 14 19:05:00 UTC 2005


Mario Lang, le Fri 14 Oct 2005 11:23:12 +0200, a écrit :
> Samuel Thibault <samuel.thibault at ens-lyon.org> writes:
> 
> > Lloyd Rasmussen, le Thu 13 Oct 2005 10:20:00 -0400, a écrit :
> >> The Unicode range 2800-28ff is the "official" way to represent any 8-dot 
> >> braille pattern, but I don't know whether anyone actually uses and supports 
> >> it.
> >
> > BRLTTY does support it when getting input from BrlAPI clients.
> > Braille tables in gnome-braille use it too.
> Yes, but is there any software out there to convert the Unicode
> representation to the local charset used?

There are at least gnome-braille and liblouis for this.

> It doesnt help much if I distribute stuff in the correct technical
> way, but no one can make use of it without jumping through hoops.

> I.e, can JAWS read unicode braille formatted text files?

Well, opening a unicode-capable editor in windows should be correctly
read by JAWS.

> Can I read them on Linux console with brltty?

Brltty doesn't support unicode yet, hence it won't work for now. But as
soon as brltty does support unicode, a program (based on gnome-braille
or liblouis for instance) can print U+28xy characters on the console,
and brltty will read them fine.

> >> > In particular, I am thinking about braille music notation,
> >
> > There is the U+1D100 Unicode range for plain music. I don't know whether
> > there exist an agreement on how a record should be written precisely,
> > but symbols are there to be used.
> Fine, but this is no use to me since I can not see them.

You just need a braille translation table to be added to brltty /
gnome-braille / liblouis / whatever.

> Braille music has been especially designed for reading it with the
> fingers, there is no staff and things are not written vertically as
> with music for sighted people.

The unicode range is not particularly designed for coding things
vertically either. In a few words: it just codes clefs, whole / half /
quarter notes, barlines etc. There is no vertical information, just
codes for symbols.

> Ideally, of course, we should hack Lilypond to create a new
> output type for braille music, then, I could just write .ly files
> and either generate PostScript or braille formatted ascii files.
> But, Lilypond is a complicated beast, at least to me.
> www.mutopiaproject.org contains so much free music, it would
> be a blast if we could just download the .ly files and create
> braille versions out of that.

To my mind, the best way is to explain to lilypond people how braille
notation works, and then they will be able to maintain a braille output
plugin.

> >> >Is there actually a standard way of specifying an ASCII files braill
> >> >encoding, or will I have to rely on guesswork?
> >
> > ASCII is just characters 0-127.
> Gah, nitpicking, you know what I ment :)

 :)

> > Now, about just braille encoding, there is the ISO/TR 11548-1 8-bit
> > encoding, which is used by BRLTTY, gnopernicus, BrlAPI, ...
> Fine, how do I convert an arbitrary braillecharset to
> that ISO thing?  And back again?

gnome-braille / liblouis are meant for such thing.

> >> How about encoding variants?
> >
> > Manufacturers have other encodings, but they are no standards.
> 
> YOu dont get my drift.

Indeed. Now I hope I got it :)

> I am talking about localisation here.

Have you read the "Localized Braille Pattern" (9th august) and
"Localized braille" (26th august) mailing list threads ? (they are
probably available on the mailing list archives of brltty at mielke.cc)
Erkki Kolehmainen has proposed to get braille encoding in the CLDR
(Common Locale Data Repository). Then brltty / gnome-braille / liblouis
/ etc could just pick up braille tables in the CLDR according to the
current "LC_BRAILLE" locale, just like other locale-dependant
informations ("yes" string, currency, telephone format, ...).

Regards,
Samuel




More information about the Blinux-list mailing list