Bug 133603

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

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 ?

Comment on attachment 233511 [details] Patch Sorry, wrong bug.

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).

Created attachment 276707 [details] Patch First attempt (to check that it does not change test rendering on iOS & OS X.)

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

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

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

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

Created attachment 276710 [details] Patch second attempt

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

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

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

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

Created attachment 276714 [details] Patch

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.

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"?

> 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.

(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.

(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.

(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.