Ink ascent/descent

[fred-wang]

This one is a bit tricky... It was mentioned in #139 and https://github.com/mathml-refresh/mathml/issues/52#issuecomment-514016715 at least. But it needs clear explanation.

When drawing a box, one can distinguish its normal size (the space it occupies) from its "ink" size (smallest enclosing rect for the painted content). For example, a white space has nonzero width/height but an empty ink box.

First the ink size is involved in the OpenType MATH spec when computing vertical gaps [1]. If I'm correct, it is not involved for horizontal placement during layout of math box, so I think we can don't need "ink left/right bearings" and can focus on ink ascent/descent below.

Using CSS baseline concepts, the MathML Core specification defines two new baselines "ink-over baseline" and "ink-under baseline" which delimitate the ink ascent/descent of a box [2]. All the boxes/baselines in the SVG schemas of the spec are drawn with dashes but the ink boxes are suggested with a background.

The status in browser is the following:

• All MathML boxes in Gecko have ink metrics, both vertical and horizontal.
• WebKit does not use ink metrics. For token elements, it calculate box metrics of the text specially [3] which means that it will somewhat work with basic constructions.
• For Blink, @rwlbuis started to implement the concept of the core spec but it's still very experimental and incomplete. It at least somewhat works for text and fractions.

In order to understand this properly, we need a non-trial test case. I uploaded a test case [4] with basic text/fraction/square root examples and the interesting one which is AAA/√CCC (square root as a denominator).

The font is built like this [5]:

• all font ascents/descents are 1em and the "use typo metrics" bit is set.
• Glyphs for A, B, C are 1em squares (respectively 1em ink ascent, 1em ink descent and .5em ink ascent/descent). They are respectively drawn in red, green and blue.
• Glyph for U+221a (radical symbol) is 1em width, 1em ink ascent, 1em ink descent. It can be repeated with 1em overlap to build a glyph assembly.
• fraction and radical rulethickness are 1em
• num/denom min gaps are 1em
• num/denom shifts are 2em
• radical vertical gap is 1em
• radical extra ascender is 2em

Exercise: Deduce the vertical positions of AAA, fraction bar, radical overbar and CCC.

Gecko, WebKit, Blink, XeLaTeX and LuaLaTeX render this last example inconsistently. Analysis is complicated by the fact that there are some unrelated bugs and that I was not able to make XeLaTeX/LuaLaTeX use my custom glyphs for the text.

Two questions for the CG:

(1) Is it important to have this concept of ink ascent/descent for all boxes? Or only male ascent/descent of token elements match the text ink ascent/descent? As I understand the MATH spec, it is important to have it for all boxes...

(2) If it is important, is the MathML Core description correct? For example, is the "radical vertical gap" included in its ink box or not? I guess we should ask Microsoft people about this.

[1] https://docs.microsoft.com/en-us/typography/opentype/spec/math
[2] https://mathml-refresh.github.io/mathml-core/#box-model
[3] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/css/mathml.css#L19
[4] https://github.com/mathml-refresh/ink-metrics
[5] https://github.com/mathml-refresh/ink-metrics/blob/master/create-font.py

[fred-wang]

@SergeyMalkin Do you know how Microsoft Word would render something equivalent to https://github.com/mathml-refresh/ink-metrics/blob/master/index.tex#L53 or https://github.com/mathml-refresh/ink-metrics/blob/master/index.html#L105 with the font https://github.com/mathml-refresh/ink-metrics/blob/master/ink-ascent-descent-test.otf ? Can you explain how the different fraction / radical parameters are interpreted?

@khaledhosny @jfkthame Do you know why XeLaTeX (and LuaLatex) fails to use my custom glyph for A, B, C in https://github.com/mathml-refresh/ink-metrics/blob/master/index.tex ? Are you able to explain the rendering of https://github.com/mathml-refresh/ink-metrics/blob/master/xelatex.pdf (1.9 specifically).

Thanks!

[fred-wang]

From left to right: Gecko, WebKit, Blink, XeLaTeX, LuaLaTeX (as I said I was not able to use my custom glyph in the latex document...)

[fred-wang]

Gap between the fraction bar and radical bar seems to be 3em (radical ascender + denominator gap) in Webkit, Blink and LuaLatex. It is only 1em (denominator gap) in Gecko since the radical ascender is not considered part of the msqrt ink box. I don't understand XeLaTeX's result, the gap seems about 3.5em but I don't understand why.

[khaledhosny]

@khaledhosny @jfkthame Do you know why XeLaTeX (and LuaLatex) fails to use my custom glyph for A, B, C in https://github.com/mathml-refresh/ink-metrics/blob/master/index.tex ?

They need to be in math ltalic slots (LaTeX by default using ASCII in math mode as shorthand for math italic) or switch math alphabet to uptright roman (\mathup I think).

[khaledhosny]

switch math alphabet to upright roman (\mathup I think).

\symup actually, \mathup witches to the text font (don’t ask me why).

[fred-wang]

@khaledhosny Thanks. I had tried \mathup but that didn't help..

Here is the updated result (xelatex: left, lualatex: right). So it seems xelatex uses a 2em gap (radical ascender) > 1em gap (denominator gap).

[fred-wang]

Actually xelatex's behavior is weird, even after setting all the gaps/shifts to 0, I still have a 1em gap between the two bars. RadicalExtraAscender does not seem to have any effect.

[SergeyMalkin]

This is how Word renders this formula:

I can't immediately explain it, though. Will need a bit more time to give you exact calculations (correct or not) that produced this result.

Thanks,
Sergey

[fred-wang]

Sergey

Thanks, this looks consistent with WebKit, Chromium and LuaLaTeX, except that I don't understand why the "radical vertical gap is" between the blue and radical bar is not 1em. Looking forward to getting more information.

[fred-wang]

We discussed this during the two previous meetings and Murray mentioned that Microsoft Word does not distinguish ink VS non-ink boundaries for radicals.

Consensus seems to be that this difference is not fundamental and only Gecko does it. So probably we can remove it and keep the simple form: only use ink extents when calculating the metrics of text-only (only text content without forced line break or soft wrap opportunity) token elements.

[fred-wang]

I've committed some changes to remove the distinction between and non-ink metrics for most of the elements (including radical elements mentioned above).

There are some things that I'm not sure.

First, I wonder if we still need to keep a distinction for token elements (rather than claiming the metrics are just the ink ones). For example for MINUS SIGN (U+2212) <mo>−</mo> whose ink bounding box is typically a thing horizontal bar above the baseline and the "ink descent" is negative. I think negative values still work well with the definition of baseline / alignment. However, the background won't be visible if ink and non-ink boxes match. This is same for any rectangle glyph, which is probably why Gecko keeps the distinction.

If we keep the distinction, I believe this has other consequences:

• Do we want a distinction for mrow too? For example, the ink bounding boxes of <mrow><mn>−</mn></mrow> or <mrow><mn>−</mn><mn>−</mn></mrow> should probably be the same as − and −−? But if we distinguish ink and non-ink for token elements, we should probably keep the same distinction for mrow.

• Similar question for other mrow-like element (merror, mphantom, etc) as well as menclose or mpadded.

Additionally, a nonzero border increases ink size while nonzero margin/padding don't. This means that margin/padding can be used to force different ink and non-ink metrics for any element. This is a bit similar to mpadded but for that element the spec currently always says the ink and non-ink metrics match (even if you add some lspace for example).