Page MenuHomePhabricator

The MathML code for \not should not use <mpadded> hack
Closed, ResolvedPublic


In some particular case, \not followed by a character command will result in the correct generation of the negated character (for example \not\in), which is good.

In more general case (for example \not\operatorname{R} on, Mathoid will generate something like

<math xmlns="">

<mrow class="MJX-TeXAtom-REL">
  <mpadded width="0">
<mi mathvariant="normal">R</mi>


to display a slash bar on top of the character. This is strongly discouraged by the MathML spec:

In this particular case, there is an appropriate way to encode slash: use menclose with a strike notation. This is supported at least by NVDA+MathPlayer and Orca dev version, and I opened for VoiceOver.

Event Timeline

fredw created this task.Jul 9 2015, 11:24 AM
fredw raised the priority of this task from to Needs Triage.
fredw updated the task description. (Show Details)
fredw added projects: Math, Mathoid, Accessibility.
fredw added a subscriber: fredw.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 9 2015, 11:24 AM
Physikerwelt triaged this task as Medium priority.Jul 20 2015, 12:26 AM
Physikerwelt set Security to None.
Physikerwelt added subscribers: Pkra, Physikerwelt.
Pkra added a comment.Jan 25 2016, 9:40 PM

The handling of TeX's \not is quite complicated, as there is no proper way in MathML to handle it fully. For example, ideally one would convert to a Unicode character that is a combined character (like U+2284 for \not\subseteq) when that is available (and the math extension does so using mathjax). But many characters don't have negated Unicode versions. Next, it's most sensible to have the character followed by U+0338, e.g., <mi>R&#x338;</mi> for \not R. But already with \not\operatorname{R}, the R has a different mathstyle than the slash so it should be handled differently (or, I suppose, authored differently, e.g., \operatorname{\not R}). The OP's suggestion to use menclose in this situation would not produce acceptable rendering results which is why it is perfectly acceptable to use mpadded to produce the visual layout intended by the author.

Personally, I find it difficult to consider <menclose> to be more semantically meaningful. Ignoring the fact that Presentation MathML is not supposed to express semantics but to specify layout, <menclose> does not offer a "not" or "negated" notation, only "updiagonalstrike" which does not strike me as very semantic, even if ATs might have heuristics to make sense of it

In the end, the real problem is that Presentation MathML has no reasonable mechanism of marking up negations of arbitrary subexpressions so TeX's \not cannot always be converted sensibly. It seems specific examples are easier to improve on the authoring side.

fredw added a comment.Jan 26 2016, 7:07 AM

menclose updiagonalstrike represents some content that is struck out and
this can be exposed as it into the accessible tree. ATs do not need any
heuristics to transmit that presentation to the user and following's
Abraham Nemeth idea it is then up to the user to deduce the mathematical
meaning. This is the best you can do with presentation MathML to make
things accessible. As a comparison, MathJax's solution is really a
visual-only hack: a zero-width BIG SOLIDUS followed by the content.

Probably, this is better explained by quoting Neil Soiffer:

You also touched on a hot button topic for me: I'm strongly against
the idea that hacking solutions with mpadded or playing games with
tables to achieve a particular presentation is acceptable. It means
the result is not accessible and a certain percentage of the
population is excluded from using the material. I'm not arguing for
semantic usages, I'm just arguing that the presentation be able to be
audibly described to the user in a meaningful manner. E.g,. 'x minus
1' with a horizontal strike across it" is understandable and but not
semantic. However, playing games with mover and mpadded: "x minus 1
with a line above it that has a negative depth of 15 pixels" is
gibberish and if the mpadded is not spoken, (... with a line above
it), the result is very misleading.

Pkra added a comment.Jan 26 2016, 12:55 PM

Just to repeat my main point: I agree that the conversion should do the best it can from the actual content. But I think that it does. Constructions using TeX's \not cannot always be represented well in MathML leading to problematic edge cases, \not\operatorname{R} is one of those cases.

This issue seems either an upstream issue with MathJax or an issue to argue in favor of changing the math extension's TeX-to-MathML converter (i.e., drop MathJax). Neither kind of issue has been filed so I'm wondering what other point there might be for having this issue open.

Physikerwelt closed this task as Resolved.Jun 25 2018, 9:09 AM
Physikerwelt claimed this task.

@Pkra @fredw I agree that this should be fixed within mathjax, so I am closing this ticket here.