Mario Lang, le Fri 14 Oct 2005 11:23:12 +0200, a écrit :
> Samuel Thibault <samuel.thibault@xxxxxxxxxxxx> 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@xxxxxxxxx)
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
_______________________________________________
Blinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/blinux-list