Open Bug 464592 Opened 16 years ago Updated 9 months ago

Square root rendering too large in MathML

Categories

(Core :: MathML, defect)

Product:
Core
Component:
MathML
Type:
defect

Tracking

()

People

(Reporter: david-arnold, Unassigned)

References

Details

Attachments

(3 files)

Firefox <msqrt> descend seems too large
12.98 KB, image/png
Details
Chrome <msqrt> for comparison
28.22 KB, image/png
Details
same equation in LaTeX for comparison
9.91 KB, image/png
Details 
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: scale-stretchy
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
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.
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.
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)
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.
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)
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.

I realize this bug is stale, but if Chromium really does start to support MathML, then MathML will become relevant and this bug will be worth fixing.

To begin, this bug is not limited to Cambria Math. It also occurs with Latin Modern, just not quite as noticeably.

I believe the problem derives from a mismatch in font glyph and math layout. Math fonts have several radical glyphs. Their sizes vary to enable different enclosed math heights. The fonts in general have followed Computer Modern, which has radical glyphs in sizes Regular, Size1, Size2, Size3, and Size4.

A Size1 radical glyph is sized to surround a TeX exponent, as in \sqrt{f^2}. But TeX and Firefox differ in how they locate exponents. TeX exponents, when inside a radical or a denominator, are created in "cramped" style. A cramped exponent is not quite as high as a regular exponent. Firefox does not have a cramped style for exponents. All Firefox exponents are placed at the same height.

So the Size1 radical glyph is no longer quite tall enough to surround a Firefox \sqrt{f^2}. So Firefox does not use the Size1 radical glyph and instead uses the Size2 glyph. The Size2 glyph is too tall. This is true both in Latin Modern and in Cambria Math. It looks worse in Cambria Math because its jump from Size1 to Size2 is so large. You can easily see this by navigating to https://temml.org/ and typing \sqrt{f^2} into the input box.

I see two possible fixes:

  1. Long term fix: Use a "cramped" style for exponents inside radicals and denominators.
  2. Quick fix: Change the criterion at which Firefox changes from a Size1 radical to a Size2 radical. Make the criterion big enough that \sqrt{f_c'} will get a Size1 radical. This will not look quite as good as in TeX, but will be much better than a Size2 radical.

I hope this bug gets some attention. I would like to enable a local font in web math and this is the only Firefox bug that for which I cannot find a work-around. And hopefully MathML will gain relevance soon.

It may be worth noting one other nuance. TeX and Firefox also differ in how they handle descenders. TeX uses the Regular size radical glyph for \sqrt f but Firefox jumps to Size1. This is true both in Cambria Math and in Latin Modern.

Again, you can verify this by navigating to https://temml.org/ and typing \sqrt{f}\sqrt M into the input box.

Firefox also prematurely jumps to Size2 in display mode integration symbols. The root cause is probably closely related to the radical issue.

Severity: minor → S4
<h1>math-style: normal</h1>
<math xmlns="http://www.w3.org/1998/Math/MathML" style="math-style: normal">
  <msqrt>
    <msup>
      <mi>x</mi>
      <mn>2</mn>
    </msup>
    <mo>+</mo>
    <msup>
      <mi>y</mi>
      <mn>2</mn>
    </msup>
  </msqrt>
</math>
<h1>math-style: compact</h1>
<math xmlns="http://www.w3.org/1998/Math/MathML">
  <msqrt>
    <msup>
      <mi>x</mi>
      <mn>2</mn>
    </msup>
    <mo>+</mo>
    <msup>
      <mi>y</mi>
      <mn>2</mn>
    </msup>
  </msqrt>
</math>

In Firefox <sqrt> left descend is too large with STIX Two font and math-style: normal

Screenshot:
Firefox
Chrome

Like Firefox, the equation is higher for displaystyle, but size of √ is not enlarged as in Firefox
texlive

\documentclass{article}
\usepackage{stix2}
\begin{document}
textstyle

\(\sqrt{x^2+y^2}\)

displaystyle

\(\displaystyle\sqrt{x^2+y^2}\)
\end{document}
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: