[Webkit-unassigned] [Bug 179682] Incorrect bounds inside <mover>/<munder> when a stretchy operator is present

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=179682

--- Comment #39 from Frédéric Wang (:fredw) <fred.wang at free.fr> ---
Created attachment 328081

  --> https://bugs.webkit.org/attachment.cgi?id=328081&action=review

Tetscase with different widths

Thanks for the perseverance on this bug. For your information, I'm working on other projects right now so obviously I don't have time to read and test things in details or to reply to each C++ build error, sorry. I'm really willing to help to provide guideline and review MathML patches though, so please continue your effort!

As indicated on the WebKit wiki, the rule of thumb to get changes accepted more easily is to try and split the work in small tasks so that it's easier for people to understand and to avoid breaking things. Also as I said you can also start with smaller bugs like bug 158937, bug 180029 or bug 161306 to get more familiar with C++ and WebKit code/process (BTW, check Tools/Script/webkit-patch --help to upload a patch without asking for review).

Regarding this bug, the initial goal was to fix the logical width of stretched operators in munderover. You are right that things are getting more complicated that I thought with embellished operators (they are actually not completely implemented yet, see bug 124831 ; Gecko has bugs too) so maybe you should not spend too much time thinking on it. By far, the most important use cases is when there are no embellished operators (row 1 in the attached test case) and in that case the behavior is clear: They should stretch to the maximum width of base/under/over and this is how the spec & Gecko behave and how WebKit must remain. In practice, there is one non-stretchy element giving the width to use so the things in the spec ("other", "unstretched size") or even skipping stretchy operators (as for vertical operators) does not really affect the value of the stretch width.

When we have embellished operators, one has to include them in the width calculation (this is the comment "Skipping the embellished op..." in WebKit code) and then the spec is not really clear about how to calculate their unstretched width (do we include unstretched <mo> width? embellishement width?) and their actual stretch width (e.g. Gecko ignores embellishments and just stretch the <mo> at the core to the target size as you can see in the testcase). Again, I think these use cases are rare and in general embellishments are small (row 2 and 3 in the testcase). So I think we have some freedom on what to do here, for example if we want to cover the use cases of horizontal braces with some long text labels. However, we should try to keep the code 1) Simple and readable 2) Close to the spec, Gecko and to the base case with no embellishments 3) Efficient, especially for the base case.

That's all I can say for now, I hope this is helpful.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20171201/638cda84/attachment.html>