[BRLTTY] Braille in CLDR

[Timothy Partridge]

To introduce myself: I noticed this discussion partly copied on to the
Unicode list so came over to take a look. I've had a read through some
American and British braille manuals but that's the limit of my experience.

> Is it fairly well agreed, though, that there is no desire for  
> encoding the dot patterns for specific bits of locale data, apart  
> from printed-to-braille?  i.e.:
>
> 	<month type="1">â  â šâ â </month>   <!-- (that's supposed to say  
Samuel Thibault <samuel.thibault at ens-lyon.org> said

> Steven R. Loomis, le Mon 05 Jun 2006 09:52:53 -0700, a écrit :
> > Is it fairly well agreed, though, that there is no desire for  
> > encoding the dot patterns for specific bits of locale data, apart  
> > from printed-to-braille?  i.e.:
> > 
> > 	<month type="1">â  â šâ â </month>   <!-- (that's supposed to say  
> > "Jan",  6-245-1-1345).  -->
> > 
> > 	etc..
>
> I'd say that contracted braille for bits of locale data can be useful
> indeed, but not without all the rest of contraction rules (for usual
> words).  And as Nicolas Pitre pointed out, these rules are very tricky,
> possibly too tricky for being sanely encoded in XML.

The rules seem relatively quick to specify in the manuals, e.g. whole word,
start of word, end of word etc. The contractions also have the rule that
they may not cross (major) syllable boundaries. An actual implementation has
to determine syllable boundaries, which is a non-trivial task (and one that
has close links to hyphenation in English and similar languages).

Could an XML coding simply encode the fact that "this contraction can only
be used within a syllable". How that is implemented is entirely up to the
programmer. Perhaps as an optional addition word lists of helpful spellings
could be added. Maybe the CLDR as a separate exercise could hold rules on
how to determine syllables in a language. (TeX has sets of rules for this
for example, but I'm not sure about the copyright on them.)

I feel there is difference in providing rules that encode Braille correctly,
and in providing rules for a high quality encoding. The rules coded in XML
should not produce incorrect Braille, but they might miss some opportunities
for, say, contractions that are only possible with an extensive dictionary.
Implementations aren't compelled to do just what is in the publicly
available information, but that information would promote a basic level of
support for langauges across implementations.

I hope my ideas are not too naive.

   Tim

-- 
Tim Partridge. Any opinions expressed are mine only and not those of my employer