-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vertical alignment of large operators #250
Comments
Thanks for the comment. It is certainly the case that firefox (or tex) centering of the symbol looks much better than the current baseline alignment in Chrome. We discussed this on a recent Working Group call. It would be most helpful if you could provide a Pull Request to the spec so that symmetric applied to bigop (as well as stretchy) characters. Then we could review the details. Otherwise given our current backlog of issues, it may not get addressed immediately, although it certainly seems a valid coment and we have added the needs specification update label. |
I also noticed that Libertinus Math's large integrals are not centered around the math axis on Chrome, so I opened this PR to center them (I couldn't find any other glyphs in Libertinus that are not centered): alerque/libertinus#559 Am I reading it right that it is not expected that this will be fixed soon in Chrome and that modifying the font instead is maybe worthwhile? (The font maintainers do not seem entirely convinced that this is something that should be changed in Libertinus.) |
First, as I read the MathML3 text, symmetric only applies to operators "streched vertically". It's a bit unclear to me whether this is meant to operator drawn larger because they are largeop in displaystyle mode, but MathML3's operator dictionary seems to use symmetric for summation and the like too. I don't have strong opinion on this, but given LaTeX always center and given many math fonts are designed based on the rendering in LaTeX, it probably makes sense to amend MathML Core / Full. The relevant part of MathML Core is step 3.2 of https://w3c.github.io/mathml-core/#layout-of-operators:
I think we can change step 2 to say that "if the operator has the stretchy property then the line-ascent=line-descent=half the glyph height and match the glyph ascent/descent otherwise." We also need to tweak step 3, to explicitly state the vertical paint offset, now that the baseline of the glyph and the baseline of the math box don't necessarily aligned. I don't think this change is difficult to implement and test. I can take a look when I have time, or maybe @icesfont can experiment that during his Igalia Coding Experience. This is probably also the remaining issue at https://issues.chromium.org/issues/40889877 |
Sorry it's actually centering with respect to the math axis, not baseline but you get the idea.
Harry has some promising WIP FWIW. |
I think it would make sense to amend the definition for symmetric in the MathML Full spec at https://www.w3.org/TR/MathML3/chapter3.html#presm.mo.dict.attrs (and the various other places that refer to it) to: "Specifies whether the operator should be kept symmetric around the math axis [i.e. same ink-height and ink-depth above and below the math axis] for vertically stretchy or large operators". Perhaps this definition could be extended to all operators or even more elements as well, but I'm not sure how much sense that would make. Then, in MathML Core, the steps for laying out a large operator would follow roughly the same steps as that of an operator stretched in the block axis, but with target dimension DisplayOperatorMinHeight. This would include the steps for symmetric operators and would also clarify the step "try and find a glyph of height at least DisplayOperatorMinHeight". I'll PR some changes to Core first that flesh this out in more detail -- then the changes could be propagated to Full too. |
I propose an addition to MathML Core specification Section 3.2.4.3 Layout of operators.
Currently, part 2 addresses operators with the
stretchy
andsymmetric
attribute and specifies that their vertical alignment should be adjusted. So far, so good.Part 3 addresses operators with the
largeop
attribute and has nothing to say about their vertical alignment. That is a mistake. An operator with thelargeop
andsymmetric
attributes should, whendisplay = block
, also have their vertical alignment adjusted around the math axis.We can see existing issues at the intersection of
All of those characters are listed in the MathML operator dictionary as having the attributes:
symmetric
,largeop
, andmovablelimits
. STIX TWO places the large glyph of those characters above the baseline. They felt they could do that because LaTeX always centers them vertically. That seems reasonable; otherwise why have asymmetric
attribute?For an example in the wild, I can point you here.
The text was updated successfully, but these errors were encountered: