[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 #17 from Minsheng Liu <lambda at liu.ms> ---
Here is my latest solution:

1. layout all sub-expressions and set the stretchWidth to be the maximal logical width
2. stretch base() or the embellished op at base()’s core to stretchWidth
3. stretch under()/over() or the embellished ops at their cores to base()’s logical width

It satisfies and violates the standard in the following way:
* This algorithm’s output only stretches stretchy operators to non-stretchy parts’ maximal width. This can be proven inductively. After step 1, each sub-expression satisfies the invariant so those sub-expressions’ logical width is the same as the maximal width of non-stretchy parts. Subsequent stretching operations only stretch stretchy operators to the maximal width of the logical width of those sub-expressions, i.e. non-stretch parts’ maximal width.
* This algorithm violates the "other direct sub-expressions" condition we discuss earlier. More specifically, it stretches an embellished operator inside base() to the maximal width of not only over()/under()—which are “other direct sub-expressions”—but also base() itself. The motivation is for the following test case:

<mrow>
  <mi> x </mi>
  <mover>
    <munder>
      <mo> &#x2192;<!--RIGHTWARDS ARROW--> </mo>
      <mtext> some long long text </mtext>
    </munder>
    <mtext> maps to </mtext>
  </mover>
  <mi> y </mi>
</mrow>

If we look at the outer <mover>, then the operator should stretch to as wide as the shorter text “maps to”, which I found quite strange. How do you think?

Note that Firefox does not follow my algorithm’s behavior and sticks with the standard in this situation. In any case, my algorithm could be easily changed to follow Firefox’s practice: in step 1, just set the stretchWidth to be max(over()->logicalWidth, under()->logicalWidth()).

<mover>
  <mrow>
    <mi>x</mi>
    <mo>+</mo>
    <mo>...</mo>
    <mo>+</mo>
    <mi>x</mi>
  </mrow>
  <mover>
    <mo>⏞</mo>
    <mtext>some long over text goes here, really long</mtext>
  </mover>
</mover>

Namely, the brace is as wide as the equation but shorter than the text comment.

* For under()/over(), this algorithm violates the "other direct sub-expressions" condition as it really just stretches the embellished operators to the width of the base, the motivation behind which is justified by the attachment “<munderover> with narrow base”.

-- 
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/20171128/5c20b766/attachment.html>