radicalDegreeBottomRaisePercent doesn't leave any space between smallest radical and its degree

[kevinbarabash]

This is output from Safari's MathML render (Chrome and Firefox output looks the same). Was the design intent to have the degree touching the radical?

[tiroj]

No, that definitely looks wrong.

The font contains a precomposed cube root sign, but I think it is not used in this situation. I’ll need to investigate the rendering during v2.20 MATH table work.

Can you please provide the MathML for this example, so I can see how the input is encoded?

Are you able to test this equation in other, non-MathML environments such as –TeX or MS Word? It would be helpful to identify if this is specific to MathML or also affects other typesetting.

[firai]

The degree also seems to be touching the radical sign in both XeLaTeX and Word (STIX Two Math v2.12 b168a):

XeLaTeX from TeX Live 2020, via Overleaf:
Word 16 (a.k.a. Office 365):

Also, despite regular square roots seeming to work correctly in Word (see the screenshot I posted in the other thread about the regular square root sign), the radical sign seems to be very slightly out of alignment for nth roots for some reason. Not sure these two scenarios can be tweaked separately or if it's just a Word quirk.

[kevinbarabash]

@tiroj that's correct, this isn't the precomposed cube-root. I should note that this collision doesn't happen with the large variants.

Here's the MathML source. It's a little verbose because I'm experimenting with ways to allow screen-readers to drill down into sub-expressions.

<math 
  xmlns="http://www.w3.org/1998/Math/MathML" 
  style="font-size: 60px; opacity: 1; font-family: STIX2;"
>
  <mrow>
     <mi>x</mi><mo>=</mo>
     <mfrac>
        <mrow>
            <mrow><mo>-</mo><mi>b</mi></mrow><mo>±</mo>
            <mroot>
                 <mrow>
                    <msup><mi>b</mi><mn>2</mn></msup><mo>-</mo>
                    <mrow>
                        <mn>4</mn><mo>⁢</mo><mi>a</mi><mo>⁢</mo><mi>c</mi></mrow>
                    </mrow>
                 <mn>8</mn>
            </mroot>
         </mrow>
         <mrow><mn>2</mn><mo>⁢</mo><mi>a</mi></mrow>
      </mfrac>
   </mrow>
</math>

@firai thanks for confirming the layout in other renderers.

As a side note, I found that the description of radicalDegreeBottomRaisePercent in the OpenType spec doesn't seem to align with the layout algorithm for radical degrees as described in the MathML Core spec. I opened MicrosoftDocs/typography-issues#766 to try to get more answers about this difference.

[tiroj]

I investigated this to see if it might be a simple fix that could be rolled into the imminent v2.13 bug fix release (mostly targeting interpolation and mark positioning bugs in the text fonts). This is how the RadicalDegreeBottomRaisePercent setting displays in the MS MathFont table editor:

So that looks correct, but obviously the data is not being interpreted in the same way in all environments. I think the issue is further complicated by the fact that there are two different height settings for the radical sign: RadicalVerticalGap (which looks to me quite tight):

and RadicalDisplayStyleVerticalGap (in which the sign sits much higher relative to the following characters:

but only the one RadicalDegreeBottomRaisePercent, which makes me wonder how the height of the degree is supposed to be adjusted for the differing heights of the radical sign.

The image of the MathML output in the original post appears to be using the RadicalVerticalGap height, but is still getting the degree height wrong.

The images of the –TeX and Word output seem to be using something closer to the RadicalDisplayStyleVerticalGap height, but if you look closely and compare with my image here, it is actually even higher, so I really don’t know what is affecting this.

Definitely punting to v2.20

[kevinbarabash]

The unfortunate thing about this since there's only one number for RadicalDegreeBottomRaisePercent there isn't really a way to just change that number and have things work with the Word/MathML layout algorithm. I'm kind of surprised that they didn't use GPOS table for this instead.

I'm working on a wysiwyg math editor for the web. I ended up implementing two different layout algorithms for this: one that follows the OpenType spec and one MathML spec. Here are some screenshots that compare the two algorithms using STIX and Gyre Schola.

STIX2

OpenType	MathML/Word

Gyre Schola

OpenType	MathML/Word

Since there exists both software and fonts that using an interpretation that differs from the OpenType spec, the spec could "solve" this by adding another math constant that specifies which of these two different interpretations should be used.

[tiroj]

I'm kind of surprised that they didn't use GPOS table for this instead.

GPOS is too restrictive for math layout: it works only in glyph space, so has no way to adapt to growing forms and dynamic arrangement of glyphs in multiple levels within an equation.

[davidmjones]

See also #184