Bug 130326

Summary: Improve preferred width computation of stretchy operators
Product: WebKit Reporter: Frédéric Wang (:fredw) <fred.wang>
Component: MathMLAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: mrobinson
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on: 121416, 130322    
Bug Blocks:    
Attachments:
Description Flags
testcase
none
testcase 2
none
testcase 3
none
testcase 3
none
Testcase none

Description Frédéric Wang (:fredw) 2014-03-17 03:05:09 PDT
This issue has been known for a long time, I'm opening a bug for the record.

In general for delimiters (parenthesis, brackets...) the width of size variants and glyph assembly is the same as the base character, so the stretchy operator width does not depend on the stretch height and we can compute the preferred width without knowing the height. Also, for large operators in displaystyle (e.g. sums), we already know which glyph will be picked when we compute the preferred width, so that's not a problem either.

However, there are some cases where the glyph width strongly depends on the stretch height that will be used at the end. For example "FRACTION SLASH" in the STIX Math or the large operators when they have the "stretchy" property. Fortunately, these operators are not stretchy by default so the situation does not really happen in practice. However, it would be good to find a solution that does not reintroduce the security issue of bug 121416, perhaps following what Gecko does.

See also bug 122837 comment 2, for a related issue which seems specific to STIX fonts. I'll have to check if there are similar issues in MATH fonts.
Comment 1 Frédéric Wang (:fredw) 2015-12-15 08:05:11 PST
Created attachment 267370 [details]
testcase

This shows different parenthesis size. The width is slightly different. Actually, only the base size is significantly narrower than the others.
Comment 2 Frédéric Wang (:fredw) 2015-12-15 11:35:23 PST
Created attachment 267381 [details]
testcase 2
Comment 3 Frédéric Wang (:fredw) 2016-02-15 03:05:15 PST
Created attachment 271333 [details]
testcase 3
Comment 4 Frédéric Wang (:fredw) 2016-02-15 06:37:38 PST
Created attachment 271340 [details]
testcase 3
Comment 5 Frédéric Wang (:fredw) 2016-07-13 22:35:01 PDT
Created attachment 283599 [details]
Testcase

This is a new testcase with better explanation. The logical width computation is now correct in WebKit. However, the preferred width is sometimes overestimated. Gecko behaves the same and I'm not sure there is an easy way to solve this issue, though.