Being a big time user of 8-dot computer Braille on my Braille display
with various markup/programming languages, your suggestion sort of fits
in with how I use Braille most of the time. So here are some of my
thoughts/comments.
Firstly note that I said I use 8-dot Braille for this. The additional 2
dots increases the single cell combinations from 64 to 256, and so ASCII
can be directly mapped to single cell dot patterns. For 6-dot Braille
even for 7-bit ASCII you need some multicell dot patterns to represent
some ASCII characters and so already introduce a slight complication
there and also loose the beauty of Braille and monospace text lining up.
Also as the text encoding of the maths is what sighted peers may use, I
get a feeling of a more direct route of communicating, I do not rely
upon software translating/mangling what I am reading/writing (I am sure
we all have our own examples of Google translate misunderstandings).
As ASCIIMath is ASCII surely it is as accessible to blind people as
sighted, yes and no. Sure it is plain text and providing the person
understands the rules of the language of the text (ASCIIMath is the
language here) they can read the text. However there is no single
language for representing math in plain text, another very popular one
is LaTeX, so the person may need to learn multiple languages for
representing math so they could read math from different sources. If
software can convert to a Braille code, then the person only needs to
know the one Braille code to read content from multiple sources. Should
the individual not want to rely upon translation to communicate, then
they probably will need to learn at least one of these languages anyway,
which combined with a Braille code like UEB already makes two codes they
need to know.
Some of the ASCIIMath notation may be more obvious to those who have at
least seen print maths as many of the commands are designed to look like
their print math. A couple examples are oo looking like infinity, and -:
looking like the divide sign. For someone who has never seen print maths
I could imagine these seeming not very intuitive.
Then there is the question of efficient representation. Traditionally
when paper Braille was used this may relate to number of cells to keep
things compact, but with Braille displays it could be more about
efficient/ease of reading/decoding. Taking size, in some cases UEB needs
more cells than ASCIIMath uses characters (think the basic operators
like plus and minus), however many things in ASCIIMath use more
characters than Braille codes use cells (eg. whilst some Greek letters
only use two characters, pi, mu, etc, others need three or four and
epsilon and upsilon use 7, with their variants being even longer). The
size question could easily be answered by comparing a number of samples
in Braille and ASCIIMath, I wouldn't be surprised if the Braille comes
out shorter in most cases. As for ease of reading, I don't think anyone
has ever done a study into that and I am not sure how one would do such
a study. Based on my own experience I feel some of the Braille code
rules are overcomplicated and do negatively impact upon ease of reading.
Reading James's earlier message on this thread about different uses of
grade 1 indicators depending on what signs are used, etc, is one such
example of overcomplication in my mind, I feel an always drop to grade 1
for maths would be simpler to process. I can't help thinking, if Braille
rules were simple, would we be here today discussing this because we may
have already created solid reliable implementations in code.
I was considering comparing specification sizes, but resisted that as it
can depend upon so much (how complete a specification is, how many edge
cases are covered, the writing style, etc as well as the complicatedness
of the syntax being described). However I do personally feel notation
like markdown combined with ASCIIMath is much less than something like
the UEB specification.
So whilst I personally have taken the route John was suggesting and work
directly in these text languages and avoid the Braille translation
issues, I do understand some of the problems the Braille code is trying
to resolve, particularly for paper Braille. I feel for Braille display
users Braille codes like UEB offer much less than they do for paper
users, and so I would recommend Braille display users try 8-dot computer
Braille and some of these ASCII notations like ASCIIMath, you can always
go back should it not work out for you.
Michael Whapples
On 13/05/2022 21:41, John Gardner wrote:
Hi all, I do not weigh in on liblouis very often these days. However I cannot help myself. ASCII Math is, well ASCII and should be just as understandable to a blind person as to a sighted person. Abe Nemeth and Tim Cranmer would turn over in their graves at the idea that ASCII Math needs translation at all. What am I missing?
John
*From:* liblouis-liblouisxml-bounce@xxxxxxxxxxxxx <liblouis-liblouisxml-bounce@xxxxxxxxxxxxx> *On Behalf Of *Michael McDonald
*Sent:* Friday, May 13, 2022 1:27 PM
*To:* liblouis-liblouisxml@xxxxxxxxxxxxx
*Subject:* [liblouis-liblouisxml] Re: [EXTERNAL] Re: ASCII Math Table
The big issue I'm looking at when dealing with ASCII math translation is the extra parentheses added by ASCII math itself. UEB is pretty straightforward because you have general fraction opening, closing and line, so the same type of grouping symbols aren't needed. For example in ASCII Math, (1+2)/3 needs the extra parentheses in the numerator, even though they wouldn't be needed either in Braille or in MathML. I've been reading over the opcodes especially the multi pass opcodes to try and decide if they could handle a case such as this. I could create a pre and post processor that would deal with the Unicode equivalents of the general fraction opening, closing, and line, but I would like to do it with just Liblouis if possible.
Regarding the grade 1 indicators, that was just an area I noticed when trying to translate different Braille examples from the UEB Tutorial. I noticed as you get further in the lessons you begin to see more and more examples of the grade 1 word and passage indicator.
Thanks,
Mike
------------------------------------------------------------------------
*From:*liblouis-liblouisxml-bounce@xxxxxxxxxxxxx <liblouis-liblouisxml-bounce@xxxxxxxxxxxxx> on behalf of James Bowden <James.Bowden@xxxxxxxxxxx>
*Sent:* Friday, May 13, 2022 4:53 AM
*To:* liblouis-liblouisxml@xxxxxxxxxxxxx <liblouis-liblouisxml@xxxxxxxxxxxxx>
*Subject:* [liblouis-liblouisxml] Re: [EXTERNAL] Re: ASCII Math Table
Hi Bert, Mike,
May I ask, was there any follow-up to the meeting we all had about mathematics support in Liblouis a little while ago?
We talked about the list of special furniture signs needed for mathematical constructs.
We also talked about separating out the input maths code from the Liblouis part.
Do we need a follow-up meeting to set next steps and who's doing what?
For fractions such as:
x plus 2, all over y minus 3,
there is no need for additional brackets in UEB. Correct output for this is:
⠰⠷⠭⠐⠖⠼⠃⠨⠌⠽⠐⠤⠼⠉⠾
Notice a single grade 1 symbol indicator is also sufficient here.
x squared plus 2 all over y minus 3:
Correct UEB braille is:
⠰⠰⠷⠭⠔⠼⠃⠐⠖⠼⠃⠨⠌⠽⠐⠤⠼⠉⠾
Notice now a grade 1 word indicator is needed, but still no brackets.
Finally:
1 + fraction x squared plus 2 all over y minus 3
UEB is:
⠼⠁⠐⠖⠷⠭⠔⠼⠃⠐⠖⠼⠃⠨⠌⠽⠐⠤⠼⠉⠾
Now, no grade 1 indicators are needed because of the number out front.
I could go on with further examples... but the number and position of grade 1 indicators depends on what signs are used and whether a number occurs.
I trust this helps.
With best regards,
James.
*From:* liblouis-liblouisxml-bounce@xxxxxxxxxxxxx <liblouis-liblouisxml-bounce@xxxxxxxxxxxxx> *On Behalf Of *Bert Frees
*Sent:* 13 May 2022 09:24
*To:* liblouis-liblouisxml@xxxxxxxxxxxxx
*Subject:* [liblouis-liblouisxml] Re: ASCII Math Table
Hi Mike,
Very happy to hear this news. I'm sure it will be a challenge and I don't know
if it can be done without changes to Liblouis itself, but I'm happy to work with
you to make the table a success because it will be a very useful addition.
But first I need to understand the requirements a bit better.
> I see support for the symbol grade 1 indicator, but not the word or passage
> indicator.
I don't know. Can anyone confirm this? Does anyone know if Liblouis has tests
for it?
> a numerator with multiple terms such as x+2 will need to have parentheses
> added around the numerator, but not if it is a single term
Maybe we should start with some YAML tests (ASCIIMath input, braille output) to
make these examples more concrete. Without concrete examples it is hard to
experiment and find out what is missing from Liblouis.
Thanks,
Bert
Michael McDonald writes:
> I'm working on an ASCII Math table for UEB and have a couple of questions.
> I'm new to table development so I still don't have my head wrapped around all
> of concepts and opcodes. I'm looking at forward and backwards translations.
>
> Looking at the current UEB tables, I see support for the symbol grade 1
> indicator, but not the word or passage indicator. Would these additions be
> possible with the current opcodes, or would this require changes to Liblouis
> itself?
>
> Currently one of the biggest areas I'm running into some issues with is
> complex and nested fractions. For example, a numerator with multiple terms
> such as x+2 will need to have parentheses added around the numerator, but not
> if it is a single term. I could always do some post processing by using
> fraction begin and end indicators but was wondering if this would be possible
> to do with Liblouis. Does anyone have an ideas how this might be achieved?
>
> Thanks,
> Mike
For a description of the software, to download it and links to
project pages go to http://liblouis.org
Donate: http://liblouis.org/sponsoring
--
<http://www.rnib.org.uk/business>
Visit rnib.org.uk/business <http://www.rnib.org.uk/business>to find out more. to find out more.
--
DISCLAIMER:
The information contained in this email and any attachments is confidential and may be privileged. If you are not the intended recipient you should not use, disclose, distribute or copy any of the content of it or of any attachment; you are requested to notify the sender immediately of your receipt of the email and then to delete it and any attachments from your system.
RNIB endeavours to ensure that all emails and attachments are virus free. We cannot, however, guarantee nor accept any responsibility for the integrity of unsecure email.
We therefore recommend that you use up to date anti-virus software and scan all communications.
Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB.
RNIB Registered Charity Number: 226227
Website: https://www.rnib.org.uk
