Native MathML rendering problems

[MurrayIII]

Native MathML rendering differs from TeX/MathJax/Word in a number of ways. Here's a short list of differences.

<​math display="block"> often doesn't center the equation
𝑎²+𝑏² displays the superscript ² for the 𝑏 too high (should be at the same height as for the 𝑎)
Adjacent fractions need to be separated by a small space instead of being contiguous
𝑎 sin 𝜃 needs a space between the 𝑎 and the sin 𝜃 and between the sin and the 𝜃
|x| displays the vertical bars too high
√𝜋 displays the square root too low
Parentheses around matrices are too large
Displaying a fraction in block mode is centered, but the fraction bar length equals the display width instead of the width of the larger argument

Here's a link to a document that illustrates the differences:
Native MathML Display Bugs.docx

[bkardell]

@MurrayIII can you clarify if you are speaking about a particular implementation? I assume you mean chromium?

[MurrayIII]

Yes, chromium since Edge uses chromium for rendering. You can see the problems using Chrome too. Try running https://murrayiii.github.io/UnicodeMathML/playground/ and type in some equations. In the settings ensure that MathJax isn't the default rendering agent. Or look at the attached docx.

[MurrayIII]

Another issue is that a hat (^) accent over a math-italic f (𝑓) is displayed too far to the left. It's placed correctly for a math-italic x (𝑥), although it would be nice to use a smaller hat for the x.

[NSoiffer]

I have created a codepen for these. I rearranged the examples to group them a bit based on similarities. Here's my take on them:

<​math display="block"> often doesn't center the equation

I don't see this in the codepen. @MurrayIII can you come up with a reproducible example and create a codepen for it?

Maybe font related issues -- for these I created a table that uses Cambria Math and STIX Two Math (if you have them installed). Both should have good Open Type math tables, so any poor quality display is because of the spec or a bug in the implementation...

𝑎²+𝑏² displays the superscript ² for the 𝑏 too high (should be at the same height as for the 𝑎)

TeX uses a superscript shift that is a based on at least two conditions as does the spec. TeX's values were chosen so that in simple cases such as this, the scripts are aligned vertically. I haven't compared the spec to TeX, so I can't say whether the spec should be fixed or it is an implementation bug.
@fred-wang: do you remember if you tried to follow TeX's script rules when you wrote the spec algorithm?

|x| displays the vertical bars too high

I added ()s to the example and they do the same thing. Firefox displays them well. I suspect this happens because symmetric=true is not being respected for non-stretchy versions of the characters.
The spec is problem here:

If it is not possible to shape a stretchy glyph corresponding to c in the inline direction with the first available font then fall back to the layout algorithm of 3.2.1.1 Layout of .

I believe this is not correct. If the mo has symmetric=true, then that should still apply. I'll hold off opening an issue for that based on feedback to my claim this needs spec improvement.

√𝜋 displays the square root too low

This might be another case of the non-stretched version being drawn wrong. Or it could be that the implementation is prioritizing the drawing so that the RadicalGap is set to the value from the OpenType math table. The spec details are here.
@fred-wang: do you remember whether you tried to emulate TeX with the radical layout rules?

Parentheses around matrices are too large

This is the subject of #238 and would be solved by changing to using 90% of the content size.

Adjacent fractions need to be separated by a small space instead of being contiguous
𝑎 sin 𝜃 needs a space between the 𝑎 and the sin 𝜃 and between the sin and the 𝜃

For both of these, I think the spec and implementation are correct. There should be U+2061 or U+2062 used (I added them to the codepen). On these characters, the lspace or rspace value should be set to be a thinspace (0.166em). I believe the default lspace/rspace rules get things normally right, but like TeX, there are places where you need to manually tweak them.

Displaying a fraction in block mode is centered, but the fraction bar length equals the display width instead of the width of the larger argument.

I couldn't reproduce this.
@MurrayIII: can you come up with a codepen that reproduces this?

There is another issues: the interline spacing is too tight in Chrome. Here is a rendering in chrome that shows the interline gap is bad (seems to be 0):

This image was created using consecutive math elements (display="block") with no tagging between them. In Firefox, the spacing looks good.

[khaledhosny]

Adjacent fractions need to be separated by a small space instead of being contiguous
𝑎 sin 𝜃 needs a space between the 𝑎 and the sin 𝜃 and between the sin and the 𝜃

For both of these, I think the spec and implementation are correct. There should be U+2061 or U+2062 used (I added them to the codepen). On these characters, the lspace or rspace value should be set to be a thinspace (0.166em). I believe the default lspace/rspace rules get things normally right, but like TeX, there are places where you need to manually tweak them.

In TeX, \sin is a \mathop, so to get similar spacing in MathML, I think something like this would be needed (I don’t know, if it is proper MathML use, though):

<math display="block">
  <mrow>
    <mi>𝑎</mi>
    <mo>sin</mo>
    <mi>𝜃</mi>
  </mrow>      
</math>

[NSoiffer]

I agree with what you say about what happens in TeX, but in MathML sin should be in an mi -- see https://w3c.github.io/mathml/#presm_mi_examples.

The markup (as in the codepen) should be something like:

<math display="block">
  <mrow>
    <mi>𝑎</mi>
    <mo>&#x2062;</mo>
    <mrow>
      <mi>𝑠in</mi>
      <mo>&#x2061;</mo>
      <mi>𝜃</mi>
   </mrow>
  </mrow>
 </math>

I haven't thought through the consequences, but maybe the default for U+2061 (invisible function application) is wrong and should be to have a lspace or rspace of 0.166em. That would deal with one of the cases. U+2062 (invisible times) definitely should be have zero spacing (e.g, $2ab$).

[runarberg]

I was experiencing similar issues with the mathup authoring tool. I decided against inferring function application and invisible times when authors write e.g. a sin theta^†, opting instead add inline start padding to the relevant elements. The CSS selector to target the correct elements was massive (the :has() selector was indeed very helpful here). If anyone is interested here is the relevant portion:

https://github.com/runarberg/mathup/blob/main/src/stylesheets/core.css#L1-L68

---

†: The reason being I cannot guarantee what authors mean so I would rather users of assistive technology not be lied to by bad inference. I still offer authors a way to be explicit by providing zero-width operators .$, .*, .+, and ., for function application, invisible times, invisible add, and invisible separator respectively. The above expression could be correctly written as a .* sin .$ theta.