Reviving an old thread...
At a meeting last May I said I'd look into porting MathCAT's Nemeth and UEB
tests into liblouisutdml. I finally tried to do that today but using the
docker image (which is from 2.10.0), it looks like some files have changed
format since the original MathML tests were written and so they don't run
(the .trs files claim success though, but that's another issue). Here's a
representative example in tests/mathml_nemeth
mfrac_01.log
../../lbu_files/nemeth.sem:34: Action or style or macro 'matrix' in column
1 not recognized
mfrac_01.trs
:test-result: PASS
:global-test-result: PASS
:recheck: no
:copy-in-global-log: no
The reference to nemeth.sem comes from mathml_nemeth/liblouisutdml.ini. I
tried eliminating the "matrix" line, but more errors showed up:
file2brl -w /tmp -f mathml_nemeth/liblouisutdml.ini
mathml_nemeth/mfrac_01.test/input.xml /tmp/output.txt
Cannot resolve table 'nemeth.ctb'
1 errors found.
nemeth.ctb could not be compiled
liblouisutdml.ini:38: Table 'nemeth.ctb' cannot be found.
liblouisutdml.ini:38: invalid mathexprTableName
Cannot resolve table 'nemeth.ctb'
1 errors found.
nemeth.ctb could not be compiled
liblouisutdml.ini:38: Table 'nemeth.ctb' cannot be found.
liblouisutdml.ini:38: invalid mathexprTableName
Can't open input file mathml_nemeth/mfrac_01.test/input.xml.
If I run the command from the mathml_nemeth dir, I get a different error:
file2brl -w /tmp -f mathml_nemeth/liblouisutdml.ini
mathml_nemeth/mfrac_01.test/input.xml /tmp/output.txt
3 new entries appended to 'appended_math.sem'.
Segmentation fault
I strongly suspect that what is supposed to go in the .ini and .sem files
have changed, but the documentation has not been updated. Anyone know what
needs to change to get the tests back to running? Once I get the existing
tests to at least run, I will add my MathCAT tests.
Neil
On Sat, May 14, 2022 at 6:17 AM Michael Whapples <
dmarc-noreply@xxxxxxxxxxxxx> wrote:
Quickly on the ASCIIMath to MathML or it could be any other language to
MathML. As far as I know there are parsers for going ASCIIMath to MathML,
but not the other way.In BrailleBlaster we did create such a parser, it has
some limitations and also creates a slightly modified ASCIIMath which we
use in BrailleBlaster, so strictly speaking it does not create normal
ASCIIMath. Other languages the situation may be different (eg. pandoc seems
to be able to go MathML to LaTeX).
Also in some cases conversion between formats is not possible as the
source may be able to encode things not representable in the target
language. Certainly would be the case for MathML to ASCIIMath. What should
be done with that unrepresentable content?
I raise this because Mike is looking at both forward and back translation.
So if he wanted to back translate Braille to ASCIIMath, then going via
MathML would need a MathML to ASCIIMath parser.
Also does any of the MathML to Braille stuff support back translation? The
two main ones I am thinking at the moment are LibLouisUTDML and mathcat.
Michael Whapples
On 14/05/2022 00:47, Neil Soiffer wrote:
A few answers to some things that came up:
1. "What became of the math meeting"
This was about whether incorporating MathCAT (which generates its own
Nemeth and UEB from MathML and is much less buggy) into
libouis/liblouisutdml makes any sense. The feeling was liblouis needs to
remain small and MathCAT is too big at 1.4mb (it could be shrunk a little
since speech isn't needed, but not much).
2. "What's wrong with just using the ASCII part of ASCIIMath"
ASCIIMath is a language to represent math in much the same way as LaTeX
is. "(a-b)/2" in ASCIIMath represents a 2D fraction. "(a-b)//2" is a linear
fraction. They have different encodings in both Nemeth and UEB. Same is
true for non-ascii letters like "β". In ASCIIMath, it is "beta", but in
Nemeth and UEB, it is dots 4-6 followed by dots 1-2 (greek letter b). Since
I don't read braille, I'm in no position to say what's better. My point is
that they aren't the same and someone who expects Nemeth or UEB math won't
be getting it just like passing through LaTeX won't be Nemeth or UEB math.
There exist open source ASCIIMath to MathML translators. It seems to be
that using one of those and improving the MathML to UEB (and Nemeth)
translations kills two birds (four if you include Nemeth) with one stone
and is a better solution.
I'm a huge believer in writing tests. You can't know something is broken
if you don't have a test for it. When I wrote my UEB translation, I took
many (most?) of the examples from both the UTM Technical guide
<https://iceb.org/guidelines_for_technical_material_2014.pdf>and from BANA's
guidance
<http://www.brailleauthority.org/ueb/ueb_math_guidance/final_for_posting_ueb_math_guidance_may_2019_102419.pdf>.
Because there are many ways to express the same thing in UEB (due to the G1
and cap indicators), BANA' s and ICEB's guidance differ in a few places and
the guidance doesn't meet what a software developer would call a spac
[James: we really need to meet to resolve these and a few other issues I
turned up].
I hope that this helps a little and doesn't muddy the water,
Neil Soiffer
On Fri, May 13, 2022 at 2:25 PM Michael Hunsaker <
hunsakerconsulting@xxxxxxxxx> wrote:
I think the issue arises with general fraction indicators and the like.
They are intuitive if you use LaTEX but sometimes best practices or rules
regarding combination of literary+technical UEB gets hard to define (e.g.,
how many grade 1 indicators are needed). I transcribe a lot of this for
students and it definitely feels like more of an art than a science some
days.
Michael Ryan Hunsaker, M.Ed., Ph.D. (he/him)
NLS-LOC Certified UEB Transcriber
Teacher for Students with Visual Impairments
Davis School District
CONTACT
I will reply to communication between the hours of 7:15-15:00pm MST
Voice/Text
Office +1 (801) 402-5955
Google Voice +1 (385) 645-7021
(text message or call and leave a voicemail, and I will return your call
ASAP)
Email ryhunsaker@xxxxxxxxxxx
Mailing Addresses
(Primary)
Davis High School
325 South Main St
Kaysville, UT 84037
(Secondary)
Fairfield Jr. High
951 Fairfield Rd
Kaysville, UT 84037
——————————————————————————
FERPA/HIPPA CONFIDENTIALITY STATEMENT
Please keep in mind that communications via email over the internet are
not secure. Although it is unlikely, there is a possibility that
information you include in an email can be intercepted and read by other
parties besides the person to whom it is addressed.
The contents of this email message and any attachments are intended
solely for the addressee(s) and may contain confidential and/or privileged
information and may be legally protected from disclosure. If you are not
the intended recipient of this message or their agent, or if this message
has been addressed to you in error, please immediately alert the sender by
reply email and then delete this message and any attachments. If you are
not the intended recipient, you are hereby notified that any use,
dissemination, copying, or storage of this message or its attachments is
strictly prohibited.
<ryhunsaker.vcf>
On May 13, 2022, at 14:41, John Gardner <john.gardner@xxxxxxxxxxxx>
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 orpassage
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 haveparentheses
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 ofquestions.
I'm new to table development so I still don't have my head wrappedaround all
of concepts and opcodes. I'm looking at forward and backwardstranslations.
be
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
possible with the current opcodes, or would this require changes toLiblouis
itself?terms
Currently one of the biggest areas I'm running into some issues with is
complex and nested fractions. For example, a numerator with multiple
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 usingpossible
fraction begin and end indicators but was wondering if this would be
to do with Liblouis. Does anyone have an ideas how this might beachieved?
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
