Square root rendering too large in MathML

NEW
Unassigned

Status

()

Core
MathML
--
minor
10 years ago
4 years ago

People

(Reporter: David Arnold, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3

See: http://msemac.redwoods.edu/~darnold/math50c/matlab/dderiv/index.xhtml

Scroll to the heading "Directional Derivative."

Note the displayed math that appears shortly thereafter with vector u. Try various zoom levels and note the incorrect rendering of the square roots at most magnifications.

The look like this here:

http://msemac.redwoods.edu/~darnold/math50c/matlab/dderiv/dderiv.gif



Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Component: General → MathML
Product: Firefox → Core
QA Contact: general → mathml
So the radical glyphs in the square roots are too big.

I'm guessing that the reason why this shows up on this page, is because the document specifies the font-family for the math elements, and this font has smaller square root glyph.  The user agent style sheet specifies STIXGeneral font-family for <math> (as a default) ,and this font has a larger square root which normally works better (see file:///home/karl/moz/mozilla-org/html/projects/mathml/demo/texvsmml.xhtml).

I'm guessing that the square root in the author-specified family (which is "serif") is being considered too small.  The next a larger glyph considered is in STIXSize1, but this much too big.

This could probably be easily fixed by considering the STIXGeneral glyph as another size smaller than the glyph in STIXSize1.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Square root rendering incorrectly in MathML → Square root rendering too large in MathML
The scale-stretchy patch fixes this bug.
Depends on: 414277
Fixed by bug 414277, but I'm not sure it is a correct solution...
OS: Mac OS X → All
Hardware: PowerPC → All
Version: unspecified → Trunk

Comment 4

4 years ago
It looks like the issue is not quite fixed. I am now seeing the same bug (radical sign extending too far down on the left) on Firefox V31 (Mac) in numerous places; for instance in the Firefox MathML Torture Test page itself (Item 13) at 
https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/MathML_Torture_Test
What I see is shown here:
http://www.zweigmedia.com/radicalsBug.png
as well as in various places in my own pages 
(see for instance http://www.zweigmedia.com/tuts/tutExponentsB.html?lang=en Scroll down to "Radicals of Products and Quotients and look at the third and fourth items). 
Curiously, radicals of single digits and letters appear to render correctly. Also,
<msqrt><mfrac><mrow><mi>a</mi></mrow><mrow><mi>b</mi></mrow></mfrac></msqrt> renders correctly, but
<msqrt><mfrac><mrow><mn>2</mn></mrow><mrow><mn>24</mn></mrow></mfrac></msqrt>  does not.


Details:
Mac OS 10.8.5
Firefox V31.0
Yes, the scale transform was removed in bug 960115, when math fonts are available (to follow TeX rendering, which does not do that). As I said in comment 3, I'm not sure it was the correct solution anyway...
(In reply to Stefan from comment #4)
> What I see is shown here:
> http://www.zweigmedia.com/radicalsBug.png

Actually, this is the "expected" behavior per the TeX / OpenType MATH rendering. You system seems to use the "Cambria Math" font. The difference might be less important with other fonts, though.

Comment 7

4 years ago
Interesting, and, yes, it does appear to be font-related. Specifying the font family as sans-serif appears to remove the problem completely (although I prefer math to be typeset in a serif font), whereas specifying "serif" as the font-family for math as I have just now done on

http://www.zweigmedia.com/tuts/tutExponentsB.html?lang=en

(there was previously no font specification for math) corrects the problems for square roots of some complex expressions involving letters (see the last multiple choice item under Radicals of Products and Quotients) but still not for square roots of simple fractions of numbers. So I would guess that there may be something irregular going on in calculating the height of a fraction inside a radical.
I'm not sure what your "sans-serif" font is (I suspect no math fonts are found, so the square does not stretch at all). Note that it depends on what is installed on the visitor's computer. You can get many WOFF math fonts at

http://fred-wang.github.io/MathFonts/
https://github.com/fred-wang/MathFonts

that you can use as Web fonts. Unfortunately many of affected by bug 1014498 on Windows at the moment, so we'll have to wait that the problem is fixed in these fonts.

Comment 9

4 years ago
Yes; I had tried Geneva, Helvetica, and Arial with varying results on square roots of purely numerical fractions (it does not effect <mi> as it is likely the case that no math fonts are available, as you say) but it does effect purely fractions of the form 
<msqrt><mfrac><mrow><mn>2</mn></mrow><mrow><mn>24</mn></mrow></mfrac></msqrt>. 
The square root symbol is stretched in all cases with varying results, but not as bad as with the serif fonts Times, Cambria, CMU, etc. 

I would be interested to see how the above radical of a fraction looks on your font test-page in display style (you have a more complex in-line fraction in a radical along the lines of the last one in the page I mentioned).
(In reply to Stefan from comment #9)
> Yes; I had tried Geneva, Helvetica, and Arial with varying results on square
> roots of purely numerical fractions (it does not effect <mi> as it is likely
> the case that no math fonts are available, as you say) but it does effect
> purely fractions of the form 
> <msqrt><mfrac><mrow><mn>2</mn></mrow><mrow><mn>24</mn></mrow></mfrac></
> msqrt>. 

These are not fonts with a MATH table, so I suspect the square root will just be stretched with the scale transform and so get the exact size. Also, they don't have mathematical italic, so this does not affect <mi>.

For Cambria (or other serif font fallbacking to Cambria), the OpenType MATH construction is used, which doesn't necessarily allow to get "perfect size". After bug 960115, we no longer correct the error via a scale transform. So this is arguably either a bug in the font or in the TeX / OpenType MATH layout, or perhaps this is debatable whether the scale should apply to this case. Some people complain that we didn't follow TeX, here so I don't know if there is a best choice.

Normally, it is recommended to use OpenType MATH fonts for the mathematics, see
https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/Fonts#Fonts_with_a_MATH_table

> I would be interested to see how the above radical of a fraction looks on
> your font test-page in display style (you have a more complex in-line
> fraction in a radical along the lines of the last one in the page I
> mentioned).

This depends of the math font selected and on whether you use Windows (because of bug 1014498)

Comment 11

4 years ago
Once I am able to test on a PC I will probably move to one of the the OpenType fonts listed on your page.

The issue with the radicals is not that serious, but it remains aesthetically troubling when - for instance in Cambria and the other serif fonts I have tried -- the radical of, say, 8/27 is rendered notably differently from the radical of a/b (or from the radicals of 8 and 27 individually), as seen in
http://www.zweigmedia.com/radicalsBug.png

Frederic, thank you for your helpful comments and more importantly for the tons of development work you and your colleagues have done to improve MathML in Firefox, which is, as a consequence, far ahead of its competitors in this regard.

Comment 12

4 years ago
Sorry -- that link supposed to be http://www.zweigmedia.com/radicalsBug2.png
(In reply to Stefan from comment #11)
> Once I am able to test on a PC I will probably move to one of the the
> OpenType fonts listed on your page.
> 

I think for now, XITS gives the best result on Windows as the other have font metric bugs :-(

> The issue with the radicals is not that serious, but it remains
> aesthetically troubling when - for instance in Cambria and the other serif
> fonts I have tried -- the radical of, say, 8/27 is rendered notably
> differently from the radical of a/b (or from the radicals of 8 and 27
> individually), as seen in
> http://www.zweigmedia.com/radicalsBug.png

That might be a font metric problem with Cambria. I also see that the size "errors" are much larger than with other math fonts. Would be good to check how XeTeX/LuaTeX/ConTeXt/Microsoft Word handle that.

> 
> Frederic, thank you for your helpful comments and more importantly for the
> tons of development work you and your colleagues have done to improve MathML
> in Firefox, which is, as a consequence, far ahead of its competitors in this
> regard.

Thanks for the kind words!
Note the original bug is probably due to the fact that ASCIIMath uses the obsolete fontfamily="serif" on the <math> elements, which confuses the math font selection (I no longer see the big radical though). So I'd rather mark this bug as WONTFIX and handle the issue with Cambria Math in bug 1045263. Karl, what do you think about that?
Flags: needinfo?(karlt)
I'm guessing the original issue would have also happened with CSS font-family, so
I don't think we need to mark the bug WONTFIX because it uses obsolete fontfamily.

I think the issue originally reported here may have been particularly bad due to not considering the base size as a stretch candidate.  For fonts with OpenType MATH tables, nsMathMLChar now considers the 0th variant, which is usually the base size, so this bug is kind of fixed.  I don't think mathfontSTIXGeneral.properties has the same fix, so this bug could be left open for that, until the properties file is removed, if that issue still exists.  If that issue no longer exists, and it's not clear what fixed it, then WORKSFORME is appropriate.

The more recent issue reported by Stefan, with helpful screenshots thank you, though very similar, is happening with slightly larger sqrt contents, and I assume is the same issue as bug 1045263 and so can be addressed there, perhaps copying links to the same screenshots.
Flags: needinfo?(karlt)

Comment 16

4 years ago
Thank you all -- I have just now switched some of the online material to XITS (with Cambria only as a fallback:  font-family: XITS Math, Cambria). The result is excellent (Mac) and, from Fred's comments, it ought to be fine in Windows as well (will test when I am next on a windows machine).

http://www.zweigmedia.com/tuts/tutExponentsB.html?lang=en

Thank you, Fred, for the CSS for XITS.
(In reply to Karl Tomlinson (:karlt) from comment #15)
> I'm guessing the original issue would have also happened with CSS
> font-family, so
> I don't think we need to mark the bug WONTFIX because it uses obsolete
> fontfamily.
> 
> I think the issue originally reported here may have been particularly bad
> due to not considering the base size as a stretch candidate.  For fonts with
> OpenType MATH tables, nsMathMLChar now considers the 0th variant, which is
> usually the base size, so this bug is kind of fixed.  I don't think
> mathfontSTIXGeneral.properties has the same fix, so this bug could be left
> open for that, until the properties file is removed, if that issue still
> exists.  If that issue no longer exists, and it's not clear what fixed it,
> then WORKSFORME is appropriate.

Yes, I really just meant to repeat what Khaled said somewhere else, that "setting the font-family to a non-math font is wrong" (via CSS or the obsolete fontfamily attribute). So WORKSFORME sounds fine, but we can keep this open for now.
(In reply to Stefan from comment #16)
> Thank you all -- I have just now switched some of the online material to
> XITS (with Cambria only as a fallback:  font-family: XITS Math, Cambria).
> The result is excellent (Mac) and, from Fred's comments, it ought to be fine
> in Windows as well (will test when I am next on a windows machine).
> 
> http://www.zweigmedia.com/tuts/tutExponentsB.html?lang=en
> 
> Thank you, Fred, for the CSS for XITS.

OK, great to hear that. Since you have a mac, you might want to give a try to the other fonts too. However as I said they don't work well on Windows for now and moreover XITS seems the right choice to go with the Times font-family of your document anyway.
You need to log in before you can comment on or make changes to this bug.