Clarify layout of large operators algorithm #276
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fred-wang
reviewed
Jan 7, 2025
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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