Re: [EXTERNAL] Interpretation of DisplayOperatorMinHeight parameter from the MATH table

Thanks Murray!

To be honest, after reading your answer I see that LineServices requires 
more arguments that I expected but I'm still not sure I understand its 
internal algorithm.

In any case, my question should perhaps be reformulated as:

A. We have a base glyph for an n-ary operator and want to render it 
larger in display mode.
B. The corresponding MathGlyphConstruction for this glyph provides a 
list of variantGlyphs (of increasing heights) -- perhaps a GlyphAssembly 
too but I'll ignore that to simplify the discussion.
C. Among the various glyphs provided, how do we determine the one to use?

The MATH table spec proposes the displayOperatorMinHeight value, defined 
as follows:

"Minimum height of n-ary operators (such as integral and summation) for 
formulas in display mode (that is, appearing as standalone page 
elements, not embedded inline within text)."

First, note that it has nothing to do with delimiters you mention as 
(2), perhaps the LineServices API internally relies on the parameter 
delimitedSubFormulaMinHeight for this case? Anyway, let's focus on (1) 
for issue #126.

A naive algorithm would be to try the different sizes provided by the 
MathGlyphConstruction and pick the one that has height (i.e. 
MathGlyphVariantRecord.advanceMeasurement) at least 
displayOperatorMinHeight. For Cambria Math, we have:

- summation.advanceMeasurement=1862
- summation.vsize1.advanceMeasurement=2312
- summation.vsize2.advanceMeasurement=3911
- summation.vsize3.advanceMeasurement=5911
- summation.vsize4.advanceMeasurement=8590
- integral.advanceMeasurement=2218
- integral.vsize1.advanceMeasurement=2769
- integral.vsize2.advanceMeasurement=4406
- integral.vsize3.advanceMeasurement=6583
- integral.vsize4.advanceMeasurement=9460

and displayOperatorMinHeight=2500 so the naive algorithm provides glyph 
summation.vsize2 and integral.vsize1 for summation and integral 
characters respectively. The former is ok but the latter is too small in 
Edge and other Chromium-based engines.

WebKit, Gecko and XeTeX all use that algorithm but in addition force 
displayOperatorMinHeight to be at least f times the height of the base 
glyph. More precisely, XeTeX uses f=5/4, WebKit uses f=√2 and Gecko uses 
f=√2 in general but f=2 for integrals. This is an easy tweak, with the 
minor issue that the spec would need to define integrals if we follow 
Gecko's approach (per your explanation that seems to be what 
LineServices requires too). The tweaked displayOperatorMinHeight become:

- max(2500, 5/4 * 1862) ≈ 2500
- max(2500, √2 * 1862) ≈ 2633
- max(2500, 5/4 * 2218) ≈ 2772
- max(2500, √2 * 2218) ≈ 3137
- max(2500, 2 * 2218) = 4436

and XeTeX, Gecko, WebKit would continue to pick summation.vsize2 for the 
summation but now correctly select integral.vsize2 for the integral.

Finally, the MATH table spec mentions that parameters with Height in 
their name "specifies a distance from the main baseline". So an 
alternative is to interpret "Height" as ink ascent and to pick the glyph 
that has ink ascent at least displayOperatorMinHeight. With that 
interpretation we correctly obtain summation.vsize2 (ink ascent ≈ 2540) 
and integral.vsize2 (ink ascent ≈ 2790). However, this is a bit less 
efficient since we now have to measure that ink ascent for each glyph 
instead of just reading MathGlyphVariantRecord.advanceMeasurement.


On 25/02/2023 01:51, Murray Sargent wrote:
> The RichEdit math display implementation uses lDisplayOperatorMinHeight in two places, both in display mode (not inline).
>
> 1) For large ops, which we call n-ary ops
> 2) For delimiters like [ ]
>
> Basically LineServices (a shared library used by Word, PowerPoint, OneNote, Notepad, WordPad, and many other apps) asks for math font n-ary parameters, one of which is pdvrMinHeightForDisplayStyle, and it asks for the delimiter min height. LineServices calculates the ascent and descent of the object base argument. For delimiters (an object like MathML <mfenced>), there's only one argument. For n-ary objects, there are three arguments, upper and lower limits and the "n-aryand", e.g., integrand or summand. No MathML counterpart, although clearly there should have been one. Sigh. In any event, if the ascent + descent < min height, the min height is used for the height; else ascent + descent is used.
>
> Sergey and/or Victor might have more info about exactly how to use the min height.
>
> Thanks,
> Murray
>
> -----Original Message-----
> From: Frédéric Wang <fwang@igalia.com>
> Sent: Friday, February 24, 2023 1:06 AM
> To: www-math@w3.org
> Cc: Murray Sargent <murrays@exchange.microsoft.com>; Sergey Malkin <sergeym@microsoft.com>
> Subject: [EXTERNAL] Interpretation of DisplayOperatorMinHeight parameter from the MATH table
>
> Hello,
>
> As discussed in a previous meeting the DisplayOperatorMinHeight does not seem enough to get the proper size of large operators in display style.
> At least WebKit, Gecko and XeTeX implementations had to perform heuristics to work around issues with existing math fonts. In the past, something similar was in the MathML Core specification but was removed until we get clarification from Microsoft about the correct way to interpret DisplayOperatorMinHeight.
>
> Now that MathML is shipped in Chrome, Edge, Opera, etc (all of them implementing DisplayOperatorMinHeight as per current version of MathML Core, without extra heuristics) this known issue showed up again, even with Microsoft's own Cambria Math font:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Fdetail%3Fid%3D1408038&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7C74825ab34b834b0f333808db16465c40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638128263700487995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gZ8tJl2DqrJ%2B67qYkAD6OsyPY4z%2BKRq8F14leg8nW6Q%3D&reserved=0
>
> Two weeks ago I tried to summarize the status and observation on the dedicated spec issue:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fmathml-core%2Fissues%2F126%23issuecomment-1425804878&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7C74825ab34b834b0f333808db16465c40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638128263700487995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XtRYS5wqBq%2FFebW1rtRXupv4MPn%2Fn6UW4cPw0UDzx%2FA%3D&reserved=0
>
> I'd really appreciate feedback from Microsoft on this, so we can progress on the spec issue and decide how to fix the chromium bug!
>
> Thanks,
>
> PS: As a completely unrelated issue,
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fmathml-core%2Fissues%2F121%23issuecomment-1082761758&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7C74825ab34b834b0f333808db16465c40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638128263700487995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=58Ol0yWzcxq4g8LFQ8zaggari8li9ZtIMfa6GgGX2f0%3D&reserved=0
> has also remained unanswered for a while.
>
> --
> Frédéric Wang
>

-- 
Frédéric Wang

Received on Saturday, 25 February 2023 09:39:19 UTC