Clarify layout of large operators algorithm #276
Conversation
There was a problem hiding this comment.
I didn't check the details of the math, but that looks good overall. I wonder whether we could factor out some logic that is shared with the vertical stretching? Maybe that can simplify things...
Also, I believe this is actually changing current behavior, so we would need to check whether the WG is ok with that.
icesfont
force-pushed
the
fix/largeop-clarification
branch
from
d2a3cff to
0948a91
Compare
icesfont
force-pushed
the
fix/largeop-clarification
branch
from
0948a91 to
9e704e9
Compare
icesfont
force-pushed
the
fix/largeop-clarification
branch
from
9e704e9 to
0bfc043
Compare
|
We discussed this with Harry last week and probably we can merge it if the WG is happy with this change. However, Harry is still experimenting a patch on this change in Chromium and will write new WPT tests / update existing ones, so we may also wait a bit to be sure there is no unexpected side effect. |
@fred-wang / @icesfont can you update us on the status here as relates to this PR? |
The change is out in Chromium as part of this bugfix: https://issues.chromium.org/issues/40889877 |
|
I believe this can me merged if the Math WG is happy with that. Harry wrote mathml/presentation-markup/operators/symmetric-largeop.html to check it. |
Please see #250.
For now, if the largeop doesn't have the symmetric property, then the center of the stretchy glyph is not shifted towards the center of the target. I'm not sure how common of a case largeop without symmetric is; the operator dictionary has no such cases, and the issue linked only concerns symmetric + largeop. If this turns out to be a problem then perhaps the center should be shifted to the center of the original unstretched glyph.
This PR should be complemented by changes to MathML Full too -- c.f.:
https://www.w3.org/TR/MathML/chapter3.html#presm.table-mo
https://www.w3.org/TR/MathML/chapter3.html#presm.op.stretch
https://www.w3.org/TR/MathML/chapter3.html#id.3.2.5.8.2