daisy / ebraille

Repository for developing use cases and standard for digital braille
16 stars 5 forks source link

handling of braille math and MathML #239

Open ManfredMuchenberger opened 1 month ago

ManfredMuchenberger commented 1 month ago

In the First Public Working Draft https://daisy.github.io/ebraille/published/1.0/FPWD-ebraille-20240725/ 6.2.1 Character encoding MathML is mentionend in a Note to be embedded in eBraille.

This issue could also be related to Georgs Issue "TVI wants to see the original graphic and original math #32".

I think at some point we need to define best practice for handling of Math formulas (if I didn't miss it and some of you already did this?)

Ideally I think we should put the braille math in the braille rendition and add an ink print rendition of the eBraille book that contains the same formula in MathML (and maybe also an image of the formula). The single line display user can continue reading the math formula in the braille rendition without further requirements to the reading system. But an advanced reading system could switch between the two renditions if it is required by the user to use an optical/graphical/tactical representation of the math formula.

GeorgeKerscher commented 1 month ago

Richard and I presented at CSUN on the reading and writing of math. The focus was on reading MathML in EPUB and in HTML. We copied the expressions using MathCAT and pasted it into Word. We then proceeded to create expressions in the Word equation editor.

There is a group working on the improvement to MS Word and linear math writing. This is very promising.

I wanted to make this point so braille readers can integrate more easily into mainstream education. The braille reader uses Word to create their math and it gets submitted as perfectly formatted math for the visual reader and is readable with a braille display. I do not know how the systems interact, but it seems that the preservation of the MathML would be good.

mattgarrish commented 1 month ago

There may be other options here, too, than relying on multiple renditions. You could embed mathml using an object tag and have the braille math equivalent as the inner fallback, for example.

wfree-aph commented 1 month ago

MathML could be out of scope for eBraille. Wouldn't it rely on the reading system having some kind of translator? Material that uses MathML is the trickiest material to properly translate, so it could set a high bar for support.

ManfredMuchenberger commented 1 month ago

I think wo should not put MathML out of scope as this is becoming more and more the main standard to handle accessible math formulas. Especially in combination with using MathCAD. Our partners from the Nordic countries are doing great work there: https://www.youtube.com/watch?v=J2ba5JPvkY0

But anyway, there is also traditionally produced braille math that we must support. This is why I thought that braille math should go into the braille rendition and MathML into an ink print rendition. I don’t know if something like Matts suggestion to use other fallback mechanism would be easier to implement for reading systems. I think we should right now allow both in the eBraille standard and then define best practice for handling math formulas at some point in the future.

mattgarrish commented 1 month ago

MathML is a default part of HTML, so unless we normatively prohibit it in the specification we need to account for it, or at least set people's expectations for how it can be used. It might be better handled in the tagging best practices guide, where you could mention that while mathml is allowed, it may not have the expected results in braille reading systems. I don't know that you need to get into the weeds of whether to use html's intrinsic fallback capabilities or multiple renditions, but you might want to state that publishers should thoroughly test any use of mathml before assuming it will work for readers.