Bug 130326 - Improve preferred width computation of stretchy operators
Summary: Improve preferred width computation of stretchy operators
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: MathML (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 121416 130322
Blocks:
  Show dependency treegraph
 
Reported: 2014-03-17 03:05 PDT by Frédéric Wang (:fredw)
Modified: 2016-07-13 22:35 PDT (History)
1 user (show)

See Also:


Attachments
testcase (1.92 KB, text/html)
2015-12-15 08:05 PST, Frédéric Wang (:fredw)
no flags Details
testcase 2 (530 bytes, text/html)
2015-12-15 11:35 PST, Frédéric Wang (:fredw)
no flags Details
testcase 3 (2.33 KB, text/html)
2016-02-15 03:05 PST, Frédéric Wang (:fredw)
no flags Details
testcase 3 (2.88 KB, text/html)
2016-02-15 06:37 PST, Frédéric Wang (:fredw)
no flags Details
Testcase (1.97 KB, text/html)
2016-07-13 22:35 PDT, Frédéric Wang (:fredw)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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.