Continuing to stray off-topic... a problem with coming up with a way to
encode Unicode technical chars in Nemeth is "who is going to know them?".
Basically, it is like display Unicode encoding to a sighted person and
expecting them to know U+2146 is the 'd' used in differentials, that U+2BAF
is a "black curved rightwards and downwards arrow", etc. In speech, they
can be pronounced in some long form if they don't represent some known
semantics (e.g,. "in equilibrium with" for ⇌), but in Braille, basically
it will just be some multi-char dot pattern that needs to be looked up. My
completely uninformed feeling is that Nemeth (and UEB and ...) should
introduce a unicode prefix encoding char and then just give the unicode
value for any char not already a part of the code (or at least a unicode
value for chars that *should *already be part of the code). In the case of
alphabets though (this case), the obvious thing is to add more prefixes to
indicate the alphabet as there are already many such prefixes. Even if the
reader doesn't know the "the following is an open face character" prefix
dot pattern, they would at least know what the letter is.
It's not in the mandate of the MathML WG to augment braille codes, but it
certainly seems reasonable for interested members to get together and come
up with a proposal for BANA (Braille Authority of North America), RNIB
(Royal National Institute of Blind People) and other braille standards
groups on how they should handle math characters not in their codes.Our
group has considerable expertise in the characters used in math.
Neil
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>