Ink ascent/descent #78

fred-wang · 2019-08-23T11:03:40Z

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 · 2019-08-23T11:12:17Z

@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 · 2019-08-23T12:09:46Z

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

$mfrac-sqrt$

fred-wang · 2019-08-23T12:23:40Z

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 · 2019-08-23T13:07:57Z

@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 · 2019-08-23T13:16:19Z

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

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

fred-wang · 2019-08-23T13:33:44Z

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

$mfrac-sqrt-xelatex-lualatex$

fred-wang · 2019-08-23T13:42:59Z

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 · 2019-08-26T18:53:36Z

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 · 2019-08-26T19:03:42Z

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 · 2019-12-18T18:34:09Z

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 · 2020-01-21T14:50:01Z

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

fred-wang · 2022-03-02T10:22:21Z

To elaborate a bit more concretely, this is how browsers render the following example:

<p><math><mtext style="background: pink">−</mtext></math></p>
<p><math><mtext style="background: lightgreen">_</mtext></math></p>
<p><math><mtext style="background: lightblue">_−</mtext></math></p>

Gecko calculate both "normal" and ink metrics for all MathML boxes, so it's possible to properly positioned math stuff with ink metrics, while still using "normal" metrics for the background.

WebKit and Blink with WIP patch make normal and ink metrics match for token elements, so background may not be visible (or be very close the ink extent of the text).

Blink without the patch uses only normal metrics, so the background remains large but there are too many gaps in MathML formulas.

davidcarlisle · 2022-03-02T11:30:43Z

@fred-wang thanks for the nice explanation and image...

Looking just at your image in the last comment the Firefox one looks best but if implementation wise it adds a lot of complication it may be complication we might live without. Certainly in TeX usage people often don't like boxes that too closely mirror individual character height/depth as you end up with very ragged highlighting, and so you often end up with things like \colorbox{\strut .} \colorbox{\strut A} where the\strut` forces any content within a reasonable size range to have a minimal height and depth, so the boxed . and boxed A have the same vertical extents. If end users are explicitly hiding the character height to get even sized background boxes, then the finer points of how the default box size is obtained from the metrics may (??) not be so important.

That said the webkit one that is (from somewhere?) always showing a small part of the background seems to be harder to explain but may cause less confused end users than the blink+patch version, I can see many people asking where their backgrounds have gone. But it is I think explainable that the background is matching (and obscured by) the character,

fred-wang · 2022-03-02T12:28:27Z

For completeness, this is how Blink currently renders https://people.igalia.com/fwang/gamma.html:

and how it renders it when using ink metrics for token elements:

Notice that the former contains large vertical gaps, which is definitely not desired. I believe fixing this is more important than having not-very-visible background issue for rectangle glyphs, so I will probably do that for an initial implementation anyway.

This is normally what WebKit does too, but would need to check the details of the implementation to be sure:
https://webkit-search.igalia.com/webkit/rev/c0c0524829fd2bebfa47a7ffad327558fd5f2672/Source/WebCore/css/mathml.css#46
https://webkit-search.igalia.com/webkit/rev/c0c0524829fd2bebfa47a7ffad327558fd5f2672/Source/WebCore/rendering/mathml/RenderMathMLToken.cpp#609
In any case for WebKit, the logical metrics and ink metrics match, so if it shows a small part of the background, that also means it adds slightly more gaps in math formulas, which we probably don't want. Gecko does not have this problem since it stores both metrics for each MathML box (which is what the core spec also does for now) and even has more complicated rules as discussed above.

davidcarlisle · 2022-03-02T12:32:48Z

@fred-wang the second image is definitely much better and if that causes a few features about background colouring that need to be carefully explained I'd still say it looks like a win. The blink rendering is really starting to look nice. I'd support your initial implementation plan here.

clapierre · 2022-03-02T14:50:44Z

<p><math><mtext style="background: pink">−</mtext></math></p>
<p><math><mtext style="background: lightgreen">_</mtext></math></p>
<p><math><mtext style="background: lightblue">_−</mtext></math></p>

Be careful, it is not recommended to have inline styling as it can not be overridden by a person who may be color blind or need to adjust these colors, font sizes etc.

could the same thing be done instead with CSS?
IE:

<p><math><mtext class="background_pink">−</mtext></math></p>
<p><math><mtext class="background_lightgreen">_</mtext></math></p>
<p><math><mtext class="background_lightblue">_−</mtext></math></p>

[CSS]
.background_pink {background-color: pink;}
.background_lightgreen {background-color: lightgreen; }
.background_lightblue {background-color: lightblue;}

fred-wang · 2022-03-02T15:08:24Z

@clapierre yes sure, putting CSS in a separate style sheet is valid in MathML. I only used inline style attribute to make the example less verbose.

Math layout relies on vertical ink extents to position boxes [1]. When entering into the details, TeX engines, Microsoft Word, Firefox or WebKit currently don't have a consistent definition of these ink metrics [2]. However, they at least agree on the essential fact that vertical ink extents should be used when positioning text inside mathematical formulas so that large gaps don't show up: compare current implementation [3] and the one using ink metrics [4] for example. This CL implements this in Blink by forcing the block metrics to match ink metrics for MathML token elements containing only text [5], which the most common situation in practice. For more complex content (e.g. with embedded HTML elements) the behavior is unchanged. This is done by implementing a new NGMathTokenLayoutAlgorithm for such token elements. Note that one limitation with this approach is that bounding boxes are tighter to the ink extent, which may make background not very visible for rectangle glyphs like <mtext style="background: pink">−</mtext>. But this is considered less problematic than large gaps everywhere and can be worked around by authors with <mpadded> or CSS margin/padding. [1] https://docs.microsoft.com/en-us/typography/opentype/spec/math [2] w3c/mathml-core#78 [3] https://user-images.githubusercontent.com/567455/156359892-3f486e09-b3a8-4aa9-9832-acccfaa6372e.png [4] https://user-images.githubusercontent.com/567455/156359901-cebce02c-97b5-482f-a718-f426e0a08604.png [5] https://w3c.github.io/mathml-core/#layout-of-mtext Bug: 6606, 1125137 Change-Id: I884dcc4fbbed3155bb21e038d4a73a034559b476 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3497762 Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Commit-Queue: Frédéric Wang <fwang@igalia.com> Cr-Commit-Position: refs/heads/main@{#977550} NOKEYCHECK=True GitOrigin-RevId: 6a760d9906d71ab68fa37cc34b923c8830e52c87

dginev · 2023-01-08T13:49:31Z

re Fred's comment #78 (comment)

Notice that the former contains large vertical gaps, which is definitely not desired.

I've stumbled on the flip side of that issue, where there is no gap at all, in the root case. Fred cross-referenced this issue in my Chromium report, so back-referencing that report here: https://bugs.chromium.org/p/chromium/issues/detail?id=1395834

I'll inline the image for convenience:

I'm nowhere near informed enough to make any useful technical comments on how MathML Core should be improved here.

Jamesernator · 2023-02-26T11:06:14Z

I'm not sure if all of these problems are due to this cause, but it looks like the same issue. Basically pretty much all fonts (including the default) have weird behaviours with <msqrt> in the Chromium implementation:

Top and bottom of sqrts are not aligned:

Large gaps under sqrt are common:

The radical fails to line up with the overbar extender:

Both MathJax and Firefox (I have not checked Safari) have far more reasonable behaviour with their respective default fonts:

MathJax:

Firefox:

(Live demo of these issues, though you will need the fonts installed locally)

This is the first patch of the series that actually take border/padding/margin into account for MathML layout. One subtility is that Gecko distinguishes the ink nsBoundingMetrics box and the ReflowOutput box for accurate positioning of math components contrary to the current version of MathML Core [1]. For MathML Core and the WPT tests, it is assumed that border/padding are used to inflate the content box [2] [3] and it does not really matter whether we inflate the ink bounding box, or simply adjust its offsets inside the normal bounding box. We choose the former and introduce a helper function InflateReflowAndBoundingMetrics for that purpose, which will be reused in follow-up patches. After inflating these boxes, the offsets of children and painted items must also be adjusted by the left/top border+padding. Regarding margins, MathML Core says that we should use "margin boxes" and WPT tests simply check that the layout of MathML constructions containing mspace elements with margins is not changed if we move these margins inside the mspace's width/height/depth attributes. To pass these tests, we similarly need to inflate both the ink and non-ink bounding boxes by the margin. However, the margins can be negative possibly leading to negative dimensions of "margin boxes". To make the code more generic, we simplify adjust all usages of the children's nsBoundingMetrics and ReflowOutput to include these margins. When calling FinishReflowChild at the end, the offsets of children must be adjusted by these margins. This patch also reimplements the extra one-pixel padding around a fraction using rules from MathML Core's UA stylesheet at https://w3c.github.io/mathml-core/#user-agent-stylesheet [1] w3c/mathml-core#78 [2] https://github.com/web-platform-tests/wpt/blob/27c8d234ee83a4b15f36ad10cc26c951b1782fb6/mathml/relations/css-styling/padding-border-margin/border-002.html#L25 [4] https://github.com/web-platform-tests/wpt/blob/27c8d234ee83a4b15f36ad10cc26c951b1782fb6/mathml/relations/css-styling/padding-border-margin/padding-002.html#L26 [3] https://github.com/web-platform-tests/wpt/blob/27c8d234ee83a4b15f36ad10cc26c951b1782fb6/mathml/relations/css-styling/padding-border-margin/margin-003.html#L50 Differential Revision: https://phabricator.services.mozilla.com/D216670

davidcarlisle transferred this issue from w3c/mathml Jun 30, 2021

davidcarlisle added MathML 4 need tests opentype/tex labels Jun 30, 2021

fred-wang added needs-tests and removed need tests MathML 4 labels Jan 18, 2022

fred-wang mentioned this issue Mar 4, 2022

Agenda for Core Meeting w3c/mathml#8

Closed

dginev mentioned this issue Jan 25, 2023

MathML Core Meeting Jan 30, 2023 #185

Closed

fred-wang mentioned this issue Feb 16, 2023

Define what the content box is for MathML token elements #139

Closed

bkardell mentioned this issue Feb 24, 2023

MathML Core Meeting Feb 27, 2023 #189

Closed

bkardell mentioned this issue Apr 21, 2023

MathML-Core meeting, April 24, 2003 #192

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Ink ascent/descent #78

Ink ascent/descent #78

Ink ascent/descent #78

Ink ascent/descent #78

Comments