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

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

Received on Saturday, 25 February 2023 00:52:09 UTC