Define fallback for OpenType MATH parameters

[fred-wang]

This is needed when MathML is rendered without a font with an OpenType table.

Gecko, WebKit, OpenType MATH and TeX have some values. We need to check whether they are consistent and easily usable: https://mathml-refresh.github.io/math-constants.html

I think this might be difficult to test as some parameters interact between each other in the layout but we don't have much freedom to set independent values without a MATH font (most of the suggested fallbacks are based on font em or x-height IIRC).

[dani31415]

Some publishers (specially K12 oriented), would like to use any font for the mathematics. In this regards, be able to render a font without OpenType table where formulas look great, would be appreciated.

In addition, in the above context usually the font of the text and the font of the mathematics are the same.

[fred-wang]

In this regards, be able to render a font without OpenType table where formulas look great, would be appreciated.

As someone mentioned in a previous call, "look great" is not possible without a math font unless you have very low expectation on the quality of the math rendering (which might be the case for K12 people). This issue is just about about providing sensible fallback values. I would oppose any choice that makes implementation too complicate or non-interoperable (e.g. custom per-font tables as in early firefox implementation).

In addition, in the above context usually the font of the text and the font of the mathematics are the same.

I guess this is off topic for this discussion, authors are free to specify the font-family they want via CSS, like for any HTML elements whether or not we provide acceptable fallback values. There is w3c/mathml#37 though to improve default font selection.

[NSoiffer]

I disagree that you can't achieve good layout unless you have font tables. What you need is access to the bounding box of the characters to know the math axis. MathPlayer, which predates math tables, used the context's font for common characters; it falls back on specialized math fonts for stretchy chars and chars not in the base font. Its output looks quite good. It is able to do good layout because it can measure properties of characters based on the bounding box. E.g, the axis height is precisely determined by the "-" or "=" character's bounding box. Other properties are based on the font size, x-height, or ems. All of these things are part of a OS's standard API for fonts. There is no magic in the math font's parameters, they are based on properties of the font and some characters in the font and can be closely estimated if you look at those properties.

@fred-wang: are you able to get to these properties? If so, I can provide some default values for script shifts, etc., based on them.

[fred-wang]

I disagree that you can't achieve good layout unless you have font tables.

You can't achieve "great look" without proper math font. There is also much more parameters in the OpenType than what is suggested in TeX, there are stretchy variants/constructions in the MathVariant table, OpenType rtlm, ssty, mathvariant characters etc Anyway, it's probably not worth discussing this as good math rendering is subjective. What I can say for sure is that several people have reported bugs in the Firefox implementation that could only be solved by more OpenType math support, not simple heuristics. So I strongly disagree with some of the claims made in this thread.

What you need is access to the bounding box of the characters to know the math axis. MathPlayer, which predates math tables, used the context's font for common characters; it falls back on specialized math fonts for stretchy chars and chars not in the base font. Its output looks quite good. It is able to do good layout because it can measure properties of characters based on the bounding box. E.g, the axis height is precisely determined by the "-" or "=" character's bounding box. Other properties are based on the font size, x-height, or ems. All of these things are part of a OS's standard API for fonts. There is no magic in the math font's parameters, they are based on properties of the font and some characters in the font and can be closely estimated if you look at those properties.

Again Firefox was implemented in the past without MATH table support and users complained about rendering bugs. A long time ago, I think it also had per-font TeX parameters, suggesting that the simple heuristics you mention was not enough back to that time. I guess Murray and @davidcarlisle can comment better about the TeX / MATH parameters and why standard font metrics is generally not enough.

In any case, accessing font-size, x-height and ems is ok in web engines (Firefox/WebKit and Igalia's Chromium fork do that). Regarding measuring the bounding box of a character, Firefox does that for some characters (and there are source code comments saying it is a slow path) but at this point I don't know if that's an acceptable approach in all web engines and if Mozilla people are happy with that (remember this is very old code). So I'm not going to comment further on this... In general, I don't think we should add anything in the Core spec until someone knowledgeable with web engines' design can confirm it is ok (does not add complexity, performance issue, too much code etc).

@fred-wang: are you able to get to these properties? If so, I can provide some default values for script shifts, etc., based on them.

As I said in the initial comment, there are some stuff in Gecko/WebKit/OpenType MATH/TeX book so I can get the list of default values. https://www.scribd.com/document/74681377/OpenType-Math-Illuminated is also useful to compare TeX and OpenType MATH parameters.

[fred-wang]

The CSS definition of ex ( https://drafts.csswg.org/css-values-4/#ex ) contains the following:

One possible heuristic is to look at how far the glyph for the lowercase "o" extends below the baseline, and subtract that value from the top of its bounding box. In the cases where it is impossible or impractical to determine the x-height, a value of 0.5em must be assumed.

So it seems acceptable to rely on the bounding boxes of characters in some cases. I wonder what browser vendors consider "impossible or impractical" cases.

[khaledhosny]

CFF fonts do not define glyph bounding box, it has to be calculated on the fly from the glyph outlines which means the application needs a way to decode and parse the CFF table, and I can imagine that being a big task in some situations (but probably not for web browsers).

[fred-wang]

I created a table to compare the suggested default values: https://mathml-refresh.github.io/math-constants.html

[NSoiffer]

That's very useful. I'll try to see if I an add a column for MathPlayer which should provide an independent set of fallback values.

There is something wrong/poor with the display of the page. The left column (the header) takes up way too much space in Chrome and Firefox under windows, so the table values are way to the right. Scrolling them back on causes overlap with the header.

Neil

On Fri, Apr 26, 2019 at 2:42 PM Frédéric Wang notifications@github.com wrote:

I created a table to compare the suggested default values: https://mathml-refresh.github.io/math-constants.html

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mathml-refresh/mathml/issues/69#issuecomment-487210410, or mute the thread https://github.com/notifications/unsubscribe-auth/AALZM3B5LLYPZU2UBNDT37LPSNZK3ANCNFSM4G3YJSKA .

[fred-wang]

That's very useful. I'll try to see if I an add a column for MathPlayer which should provide an independent set of fallback values.

That would be great.

There is something wrong/poor with the display of the page. The left column (the header) takes up way too much space in Chrome and Firefox under windows, so the table values are way to the right. Scrolling them back on causes overlap with the header. Neil

Yes I noticed that too. Maybe @davidcarlisle knows why. I haven't changed the default layout.

[fred-wang]

@NSoiffer I removed the default style. Hopefully the table should now show up correctly.

[NSoiffer]

@Frédéric Wang fwang@igalia.com: much better!

On Thu, May 2, 2019 at 1:20 AM Frédéric Wang notifications@github.com wrote:

@NSoiffer https://github.com/NSoiffer I removed the default style. Hopefully the table should now show up correctly.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mathml-refresh/mathml/issues/69#issuecomment-488587978, or mute the thread https://github.com/notifications/unsubscribe-auth/AALZM3DNZZY6FQEWPEGCV23PTKP2ZANCNFSM4G3YJSKA .

[fred-wang]

The spec has an appendix but the fallback values still need to be defined:

https://mathml-refresh.github.io/mathml-core/#layout-constants-mathconstants

[fred-wang]

CSS inline has an appendix mentioning mathematical baseline: https://www.w3.org/TR/css-inline-3/#baseline-synthesis-fonts

[fred-wang]

As agreed last year, I added fallback for the values that are from the OpenType MATH spec. Microsoft opened https://github.com/MicrosoftDocs/typography-issues/issues/285 so I guess we can continue discussions there.

[faceless2]

The fallback values listed in the spec are:

• "fractionNumeratorShiftUp" fallback to "stackTopDisplayStyleShiftUp"
• "fractionNumeratorDisplayStyleShiftUp" fallback to ??

which are reversed from the recommendations from the OT MathConstants table.

[faceless2]

I should add it's not just the OT MathConstants recommendations they mismatch; they also don't match the values in your table at https://mathml-refresh.github.io/math-constants.html

The only other ones I could find are:

• "fractionDenominatorGapMin" is "3 x defaultRuleThickness" - should be simply "defaultRuleThickness"

• "subSuperscriptGapMin" is "3 x defaultRuleThickness" - slightly less sure about this one, but it's 4 x in every column in your table - 3x is not listed anywhere.

[fred-wang]

@faceless2 thanks, I fixed the mfrac. I guess I'll have to review this. I think https://mathml-refresh.github.io/math-constants.html is probably more reliable from the time being.

[faceless2]

Thanks - the good news is we didn't find any others!

Also wanted to flag up an OpenType font constant which may be applicable but isn't listed anywhere: post.underlineThickness, the thickness of an underline text-decoration. It might be a good choice as a value for"default rule thickness". It's HB_OT_METRICS_TAG_UNDERLINE_SIZE in Harfbuzz.

[fred-wang]

Thanks - the good news is we didn't find any others!

I fixed two more. Hopefully, these were the only ones remaing.

Also wanted to flag up an OpenType font constant which may be applicable but isn't listed anywhere: post.underlineThickness, the thickness of an underline text-decoration. It might be a good choice as a value for"default rule thickness". It's HB_OT_METRICS_TAG_UNDERLINE_SIZE in Harfbuzz.

Sounds a good idea. I see it is also supposed to match OS/2.yStrikeoutSize which might be another option. I'll add this to the agenda for next week.

[fred-wang]

Consensus from 2020/03/23: use 1/24em for spaceAfterScript. No clear consensus on default thickness (use post.underlineThickness or OS/2.yStrikeoutSize VS measure a glyph like minus sign).

[fred-wang]

Given that it is unlikely that there will be any progress or consensus on this in the short term, I propose to stick with a simple option to clean up the current text:

• default thickness: post.underlineThickness
• default constant: 0 (for all the other "??")

[fred-wang]

The text has been updated to always provide a fallback values. probably not ideal but we can improve later.

Additionally, I have updated the text for stretchy operator shaping to address feedback from Google during upstreaming (basically unify measuring & painting). The special handling of unicode-based fallback was causing issue during review, so it has not been upstreamed (and Igalia removed it from downstream). I've updated the spec so that the suggested unicode constructions are non-normative.

[fred-wang]

Writing tests for these is going to be difficult because values are highly dependent, you cannot just set arbitrary values like what we did for fonts using the OpenType MATH table.

[fred-wang]

consensus from 2020-06: consider a better fallback in level-2, for level-1, keep current text.

[davidcarlisle]

Having moved this I remmbered why we didn't move originally: potential link issues this from tests or elsewhere. I'll hold off moving more, although it would be good to get the issues in the mathml repository in a better state at some point