Bug 133603 – Use OpenType MATH fonts by default

• Component: MathML
• Status: RESOLVED FIXED

[Frédéric Wang (:fredw)]

Firefox 31 (to be released in July) will recommend to use OpenType MATH fonts for MathML. I hope this will allow to get these fonts more popular and to get some bugs fixed (The GUST group said they will try to fix the bugs but I didn't get any feedback from the STIX consortium yet). For example "Cambria Math" is installed by default on Windows 7 or higher. I have opened enhancement requests for Mac OS (problem 16841023 for STIX and 17021145 for Latin Modern) and iOS (problem 16843041). On Linux, the texlive package is generally available and contains appropriate fonts (e.g. Latin Modern Math). For details, see https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/Fonts

Currently, our mathml.css stylesheet contains the following rules:

#if defined(WTF_PLATFORM_IOS) && WTF_PLATFORM_IOS
    /* We explicitly include the font Symbol as it's the iOS equivalent of font STIXGeneral. */
    font-family: STIXGeneral, Symbol, "Times New Roman", sans-serif;
#else
    font-family: MathJax_Main, STIXGeneral, STIXSizeOneSym, "DejaVu Sans", "DejaVu Serif", Cambria, "Cambria Math", "Lucida Sans Unicode", "Arial Unicode MS", "Lucida Grande", OpenSymbol, "Standard Symbols L", Times, serif;
#endif

I have already tested the OpenType MATH support on Linux and I think we could use at least add Latin Modern Math as the first default font.

On Windows, Gurpreet gets the best results with "Cambria Math" but I don't remember exactly if there were other serious rendering problems. I think "Cambria Math" should be the suggested as the default font on Windows. Firefox 31 for Windows also has some bugs with the other fonts at the moment.

On Mac, we need to fix bug 133569 first. Hopefully the enhancement requests I submitted for Mac OS and iOS will be addressed and we could change the default font-family.

One small problem is that MATH fonts generally only have a "Regular" style since the italic/bold/bold-italic are supposed to be picked from the math alpha num symbols (http://en.wikipedia.org/wiki/Mathematical_Alphanumeric_Symbols), and we don't do that yet (see bug 108778). Since we use CSS for these mathvariants, the rendering might not be as beautiful as if we would have used the math alpha num symbols.

[Frédéric Wang (:fredw)]

See also https://gerrit.wikimedia.org/r/#/c/134362/ for the MediaWiki bug to add WOFF Latin Modern Math.

[Frédéric Wang (:fredw)]

Created attachment 233511 [details]
Patch

Could someone please update the text and image references for

mathml/opentype/opentype-stretchy.html
mathml/opentype/opentype-stretchy-horizontal.html

?

[Frédéric Wang (:fredw)]

Comment on attachment 233511 [details]
Patch

Sorry, wrong bug.

[Frédéric Wang (:fredw)]

Dropping the dependency on bug 108778 as we don't really need to wait for the patch there to change the font-family (although having the fix for bug 155018 landed would be nice).

[Frédéric Wang (:fredw)]

Created attachment 276707 [details]
Patch

First attempt (to check that it does not change test rendering on iOS & OS X.)

[Build Bot]

Comment on attachment 276707 [details]
Patch

Attachment 276707 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/1185393

New failing tests:
mathml/opentype/large-operators.html
mathml/opentype/vertical.html
accessibility/math-multiscript-attributes.html

[Build Bot]

Created attachment 276708 [details]
Archive of layout-test-results from ews103 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews103  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 276707 [details]
Patch

Attachment 276707 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/1185403

New failing tests:
mathml/opentype/large-operators.html
mathml/opentype/vertical.html
accessibility/math-multiscript-attributes.html

[Build Bot]

Created attachment 276709 [details]
Archive of layout-test-results from ews107 for mac-yosemite-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews107  Port: mac-yosemite-wk2  Platform: Mac OS X 10.10.5

[Frédéric Wang (:fredw)]

Created attachment 276710 [details]
Patch

second attempt

[Build Bot]

Comment on attachment 276710 [details]
Patch

Attachment 276710 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/1185496

New failing tests:
mathml/opentype/large-operators.html
mathml/opentype/vertical.html
accessibility/math-multiscript-attributes.html

[Build Bot]

Created attachment 276712 [details]
Archive of layout-test-results from ews107 for mac-yosemite-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews107  Port: mac-yosemite-wk2  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 276710 [details]
Patch

Attachment 276710 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/1185548

New failing tests:
mathml/opentype/large-operators.html
mathml/opentype/vertical.html
accessibility/math-multiscript-attributes.html

[Build Bot]

Created attachment 276713 [details]
Archive of layout-test-results from ews101 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews101  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Frédéric Wang (:fredw)]

Created attachment 276714 [details]
Patch

[Frédéric Wang (:fredw)]

More explanation:

I've essentially kept the fonts that are currently installed on the systems and used by the tests:

- STIXGeneral, Symbol, Times New Roman for iOS
- STIXGeneral, STIXSizeOneSym for OS X
- Cambria Math for Windows
- Latin Modern Math for Linux

The removed/new fonts are not installed and on iOS/OSX/Linux they are filtered out by the test framework anyway.

[Frédéric Wang (:fredw)]

https://trac.webkit.org/changeset/199773

[Darin Adler]

Comment on attachment 276714 [details]
Patch

Here are some of the things that I don’t like here:

1) Indenting. It seems strange to add all those spaces to line up with the colon from font-family. WebKit coding style explicitly recommends against this kind of formatting in C++ code and I would make the same recommendation here for the same reason.

2) Continuing to use a different list on iOS than on every other platform. The main argument about listing all these fonts seems to be that they do no harm if you list them on systems that don’t have the fonts. Why isn’t that also true of the Symbol and Times New Roman fonts? A conditional here is unpleasant and needs a rationale.

3) Removal of many of the font names that were already listed without rationale explaining their removal. This is probably the right thing to do, but it would be nice to explain more why they were on the list before and why it will do no harm to remove them now? This is such a long list; I’d really like to understand what makes it the right list and why this is the right order.

4) Is it really OK to set the font-family without taking font size into consideration. In the past I have found that different font families vary greatly in how big the text is at each font size. Are these typefaces all really interchangeable without any adaptation of font size.

5) Overriding the font-family but still inheriting the many other font-related properties. Is that really OK? Things like bolding, underlining, font features, etc.? I’d like to see tests covering these things.

I don’t think the comment about the wish to have more built-in fonts on OS X and iOS adds much here. It’s fine to discuss that with the others on the WebKit project but I’m not sure it’s helpful to have it here in this source file.

Is the change in behavior on OS X really carefully considered? Seems that it will now use "serif" and before would have used "Lucida Grande" or maybe "Arial Unicode MS"?

[Frédéric Wang (:fredw)]

> 1) Indenting.

The idea was that it would make more readable addition/removal of a font when one uses line-by-line diff, but I can revert that.

> 2) Continuing to use a different list on iOS than on every other platform.

Indeed it does not harm to make Symbol and Times New Roman available on all platforms. I can do this change if you want, the only reason why I kept the conditional was that it was already present and that I wanted to minimize the changes from the current status. But keep in mind that these fonts are not of much use on other platforms than iOS.

> 3) Removal of many of the font names that were already listed without rationale explaining their removal.

Some of the fonts like "Arial Unicode MS" were just copied from Gecko by someone who worked on WebKit in the past but his intention was to keep the list up-to-date with respect to Gecko (that's the comment left). In this patch and in Gecko the list is now first some fonts with an OpenType MATH table giving the best rendering and next some fallback pre-installed fonts to provide minimal unicode support (e.g. STIX General).

The order of OpenType MATH fonts is more or less arbitrary it depends on people's preference, Unicode coverage, bugs in existing fonts, etc. Again, I'm trying to keep consistent with Gecko here. I can provide more details, but it's likely to change over time. Ideally, this list should be configurable as it is in Gecko.

> 4) Is it really OK to set the font-family without taking font size into consideration.

So you have the choice between either 1) inheriting the font which is very likely to be a non-math font and so provide poor rendering or 2) changing to known math fonts which may give inconsistent style or size of formulas with respect to the surrounding text.

1) is much worse than 2) in all but trivial formulas. Again, I follow what Gecko does here and do not change WebKit's current behavior.

On Gecko bugzilla, someone proposed automatically converting a text to its math companion (e.g. STIX => STIX Math) which would probably be the ideal to get consistent font style and size, but that's unlikely to work at the moment given that the number of such math fonts are very limited.

To avoid 2), customization is suggested in http://trac.webkit.org/wiki/MathML/Fonts#CustomizingMathFont, but contrary to Firefox we don't have a menu to configure the math font.

> 5) Overriding the font-family but still inheriting the many other font-related properties. Is that really OK? Things like bolding, underlining, font features, etc.? I’d like to see tests covering these things.

Probably we should reset the font-related properties too (Gecko does that for more properties and we already started it in bug 155433). Separate bugs can be opened for that. But again I'm just preserving WebKit's current behavior for now.

> I don’t think the comment about the wish to have more built-in fonts on OS X and iOS adds much here. It’s fine to discuss that with the others on the WebKit project but I’m not sure it’s helpful to have it here in this source file.

The point was to highlight that fonts with an OpenType MATH table are important for the math rendering and that other fonts are really to be considered as fallback. The old comment for iOS was confusing "We explicitly include the font Symbol as it's the iOS equivalent of font STIXGeneral." while the Symbol font on iOS has ridiculously small unicode coverage compared to STIXGeneral. And even STIXGeneral is not enough for good math rendering. I believe more explanation is better for someone who updates this list in the future and wonder why we add these fonts on Mac/iOS, but I can remove it if you feel it does not help.

> Is the change in behavior on OS X really carefully considered? Seems that it will now use "serif" and before would have used "Lucida Grande" or maybe "Arial Unicode MS"?

STIXGeneral / STIXNonSizeOne are pre-installed on OS X and have much better unicode coverage for math symbols than the removed fonts that were listed after them, so it's unlikely that these would have been used.

[Alejandro G. Castro]

(In reply to comment #19)
> > 1) Indenting.
> 
> The idea was that it would make more readable addition/removal of a font
> when one uses line-by-line diff, but I can revert that.
> 

Thanks for your clarifications, but I think Darin's points are sensible and this is not just a small change in the font selection but added multiple changes. So please try to:
   - Roll out the patch
   - Address style issues, comments and line indentation
   - Add comments about the rationale of the list
   - Check if we can remove the ifdef
   - Try to add tests for changes in the other font values to make sure we do not break anything with the test fonts
   - Divide the patch in small changes regarding the goals you want, for instance: Deprecating this font, or adding this new font, etc.
   - Get feedback from Apple devs before modifying their specific options

Thanks and sorry for the fast review.

[Darin Adler]

(In reply to comment #19)
> The idea was that it would make more readable addition/removal of a font
> when one uses line-by-line diff

Listing each item on a separate line is OK. I was objecting to the indenting style, not the "one family on each line".

> But keep in mind that these fonts are not of much use on other platforms than iOS.

I think I’m keeping that in mind. If listing the fonts has no effect, good, does no harm. If it does have an effect, I’d like to know exactly what it is.

> Ideally, this list should be configurable as it is in Gecko.

The list is configurable; this is CSS. Each port can supply a user-agent style sheet, can replace this list with whatever it likes. Or if we want to keep the user-agent style sheet for the app, then we could add another style sheet for each port.

On the other hand, the idea that end users should configure a font list so that math will look acceptable in their web browser is not consistent with my ideas about how to create good software.

> > 4) Is it really OK to set the font-family without taking font size into consideration.
> 
> So you have the choice between either 1) inheriting the font which is very
> likely to be a non-math font and so provide poor rendering or 2) changing to
> known math fonts which may give inconsistent style or size of formulas with
> respect to the surrounding text.

That’s not the only possibility. For example, we could figure out how the math font sizes relate to other font sizes and include code that tries to get the font size right.

> I follow what Gecko does here

I see.

> On Gecko bugzilla, someone proposed automatically converting a text to its
> math companion (e.g. STIX => STIX Math) which would probably be the ideal to
> get consistent font style and size, but that's unlikely to work at the
> moment given that the number of such math fonts are very limited.
>
> To avoid 2), customization is suggested in
> http://trac.webkit.org/wiki/MathML/Fonts#CustomizingMathFont, but contrary
> to Firefox we don't have a menu to configure the math font.

Who is the "we" here? If you mean Safari, then absolutely, yes, the developers of Safari have a very different idea about fonts on the web and the value of font preferences than the developers of Firefox.

But if you mean all WebKit web browsers, then I think that’s wrong!

> > 5) Overriding the font-family but still inheriting the many other font-related properties. Is that really OK? Things like bolding, underlining, font features, etc.? I’d like to see tests covering these things.
> 
> Probably we should reset the font-related properties too (Gecko does that
> for more properties and we already started it in bug 155433). Separate bugs
> can be opened for that. But again I'm just preserving WebKit's current
> behavior for now.

OK, I accept that this bad behavior is not new.

Lets fix it!

> The point was to highlight that fonts with an OpenType MATH table are
> important for the math rendering

OK, if that is the point, I would write a comment like this:

    // Fonts with an OpenType MATH table are important for math rendering.
    // As of this writing in April 2016, the font families listed after this point
    // do not have that table and so math rendering likely won't be acceptable
    // on platforms such as iOS where we fall back to these.

[Frédéric Wang (:fredw)]

(In reply to comment #21)

@Darin: Please check bug 156840 and the references and say if that addresses your concerns. Some replies below.

> On the other hand, the idea that end users should configure a font list so
> that math will look acceptable in their web browser is not consistent with
> my ideas about how to create good software.

I don't like it either. However, I'm not sure we can easily fix that given the math fonts are not widespread at the moment. Anyway that's out of the scope of this bug which was "try and use known OpenType MATH fonts when they are installed on the system".

> That’s not the only possibility. For example, we could figure out how the
> math font sizes relate to other font sizes and include code that tries to
> get the font size right.

Sure but that's will be a change of behavior with respect to expected CSS inheritance (that will probably needs discussion with other implementers and maybe standardization, but I'm not against that idea). Also, that won't really solve the issue that one can use text and math font belonging to different typeface families (say using Palatino text with Times text)... The only way I see is the suggestion in https://bugzilla.mozilla.org/show_bug.cgi?id=947654#c1

But again, this can be handled in follow-up bugs and is in my opinion the issue is much less serious than trying to render math equation with inappropriate fonts.

> Who is the "we" here? If you mean Safari, then absolutely, yes, the
> developers of Safari have a very different idea about fonts on the web and
> the value of font preferences than the developers of Firefox.
>
> But if you mean all WebKit web browsers, then I think that’s wrong! 

I meant Gecko's font preference based on text language, which I could not find in WebKit code. Of course, I agree that this can be provided in higher lever stylesheet.