NSoiffer
Use Nemeth Indicators to Delimit Math Content in Text
MathCAT Version
MathCAT-0.6.6 (NVDA Add-On)
Current Behavior
When MathCAT encounters in-line math content and is set to render math as Nemeth, it inserts one space before the math and two spaces afterward to distinguish it from the surrounding text.
Proposed Change
Nemeth indicators would likely serve as better delimiters. Benefits include
- a more natural rendering of mixed content (text interspersed with math), since that is how such content would be brailled physically.
- more conspicuous indication of code switching (especially useful in STEM documents).
- easier identification of symbols (e.g., punctuation) directly following math content, as the Nemeth indicators occupy the full height of the cells they use.
- the ability (at least in theory) to use NVDA's braille output as (nearly) embosser-ready Unicode braille (since the standard is to use Nemeth indicators in UEB documents with Nemeth math content).
Perhaps an option could be given to toggle this behavior if desired.
Comparison
Mixed-Content Statement
In this case, $y$ is proportional to $x^2$.
Current Nemeth Output (Unicode)
⠠⠔⠀⠹⠀⠉⠁⠎⠑⠂⠀⠀⠰⠽⠀⠀⠀⠊⠎⠀⠏⠗⠕⠏⠕⠗⠰⠝⠁⠇⠀⠞⠕⠀⠀⠭⠘⠆⠀⠀⠲
Proposed Nemeth Output (Unicode)
⠠⠔⠀⠹⠀⠉⠁⠎⠑⠂⠀⠸⠩⠀⠽⠀⠸⠱⠀⠊⠎⠀⠏⠗⠕⠏⠕⠗⠰⠝⠁⠇⠀⠞⠕⠀⠸⠩⠀⠭⠘⠆⠀⠸⠱⠲
If Nemeth indicators were adopted, then the grade 1 symbol indicator would not be necessary before the $y$.
MathCAT deliberately does not include the Nemeth indicators. That is left to the code that calls MathCAT. Nemeth code is used in contexts beyond UEB and so the start/end indicators will likely differ.
It sounds like maybe a modification to NVDA is what is needed to optimize certain cases. Is that correct? If so, please file an NVDA issue with details on what should be changed.
I'll leave this open for now in case I have misunderstood what you are asking for.
Yes, delimiters depend on the surrounding code and the math code itself as well. It seems that whichever module would handle delimiters where appropriate would have to be aware of the surrounding code (handled by NVDA) and the math code (handled by MathCAT) in use. Since there are so many possible combinations of codes, perhaps it is best not to include the delimiters.
Is there a reason for one preceding space and two trailing spaces?
I don't know why NVDA is doing that other than "it doesn't know what it should do." I looked at the NVDA code and it seems to be adding a TEXT_SEPARATOR before the math and likely before what follows the math.
# used to separate chunks of text when programmatically joined
TEXT_SEPARATOR = " "
From what I can see, it does this regardless of the braille math code.
One problem with making the fix in NVDA is that NVDA doesn't know the braille math code in use. Maybe a fix would be changing the NVDA/MathCAT glue code to add appropriate characters and remove the addition of the space from the internal code if MathCAT is the braille math provider.
@NV-Codes (or someone else): If that sounds like a good path, could you let me know what the rules are for indicators when the outside text is:
- UEB Grade 1
- UEB Grade 2
and the math braille code is:
- UEB
- Nemeth
I knew them at one time, but have since forgotten them.
For using Nemeth within UEB contexts, the "opening Nemeth indicator" is ⠸⠩ (dots 4-5-6, dots 1-4-6), and the "closing Nemeth indicator" is ⠸⠱⠀(dots 4-5-6, dots 1-5-6))[^1]. It is my understanding that no such delimiters are needed for UEB math in a UEB document, as both are part of the same code; MathCAT already handles usage of the grade-1 passage and grade-1 word indicators for UEB math expressions as necessary.
[^1]: Source: https://nemeth.aphtech.org/lesson3.8