Radical glyphs from TeX fonts and some of the radical glyphs from Mathematica fonts are drawn below the baseline so that their ascent contains information about the thickness of the overline. Most fonts (including STIXGeneral STIXSize* CambriaMath), however, have radical glyphs above the baseline so no such assumption can be made about the meaning of their ascent.

Even with the glyphs from Mathematica's Math2, the overline rule and the right hook from the radical glyph sometimes don't have the same thickness (if font sizes are chosen carefully/poorly), so I see no need to continue to use this method.

is this a regression? suggestions for priority?

(In reply to comment #3) Strictly, this it not a regression as this never worked for "normal" fonts. However the "special" fonts now don't work either, which is a regression. I've prioritized P1 as this blocks fixing that regression (by using more modern fonts, bug 400938).

Just using GetRuleThickness for overline thickness, and shifted some code around so that radical height is stretched using the adjusted overline thickness and rounded clearance. With this change, there is no need for specifying special fonts for sqrt, hence the change to the mathfont.properties file.

There are still some issues with the overline rule and the right hook from the radical top not lining up perfectly. This may be due to rounding in FillRect or aligning the glyphs to pixels. Perhaps the correct fix is to use glyphs from the font (where available) for the overline rule. An alternative is to just use verticals for the radical top and position the overline based on the right bearing rather than the advance width. Fixing that can be an enhancement for later.

Checked in: 1.18 mozilla/layout/mathml/base/src/mathfont.properties 1.132 mozilla/layout/mathml/base/src/nsMathMLChar.cpp 1.55 mozilla/layout/mathml/base/src/nsMathMLmrootFrame.cpp 1.47 mozilla/layout/mathml/base/src/nsMathMLmsqrtFrame.cpp Filed bug 403958 for perfecting the issues mentioned in the previous comment.