Vertical Alignment of <mo> delimiters

[ronkok]

I propose two edits to MathML-Core section 3.2.4.3 Layout of operators.

The first edit is shown below in bold.

2. If the operator has the stretchy property or has the minsize attribute:

There is a current problem with <mo> delimiters in both Chromium and WebKit. This problem affects a parenthesis which does not have stretchy="true" but has been up-sized with a minsize attribute. Such delimiters should be vertically aligned to be centered on the math axis. Both Chromium and WebKit fail to make that adjustment.

You can see an example if you navigate to the Temml Mozilla tests and scroll down to line 14. There are more examples in the Wikipedia tests, in lines 178 & 179.

I propose a second edit after the line which reads “Otherwise, the stretch axis of the operator is block. The following steps are performed.”

I propose to insert item 2 below.

2. If the size of in-flow children make it unnecessary to shape a stretchy glyph in the block direction, then fallback to the layout algorithm of 3.2.1.1 Layout of <mtext>.

This problem also occurs in both Chromium and WebKit. An example can be seen here. Those parentheses do not need to stretch, and they don’t. So far, so good. The problem is that they do not need an adjustment to their vertical alignment. But the alignment has been changed. They are placed too high.

My first proposal is related to Chromium Issue 1468676. My second proposal is related to Chromium Issue 1350167.

[davidcarlisle]

I don't think the first edit is needed, as minsize only applies to stretchy operators (which may implicitly have that property via the operator dictionary).

eg

https://www.w3.org/TR/MathML3/chapter3.html#presm.presatt says

minsize ... Specifies the minimum size of the operator when stretchy;

https://www.w3.org/TR/mathml-core/#operator-fence-separator-or-accent-mo

Finally the minsize and maxsize attributes add additional constraints over the stretch size.

[ronkok]

I don't think the first edit is needed, as minsize only applies to stretchy operators …

That’s a reasonable position. My aim was to eliminate ambiguity. If everyone agrees with David’s interpretation of the current specification, then the first edit is superfluous.

[brucemiller]

Is the underlying problem with the first chromium issue, that chromium does not set stretchy=true (from the operator dictionary)?

[ronkok]

The delimiters do change size when a minsize attribute has been set. Looking at it from the outside, that's as much as I know. Perhaps some internal switch is not properly flipped.

[NSoiffer]

We discussed this at the core meeting today. The feeling was that the problem is that the symmetric property isn't being respected.

So I would suggest that @ronkok's proposal be tweaked:

In 3.2.4.3, the second clause should be changed to (change is in bold):
2. If the operator has the stretchy property or has the symmetric property:

This change means that clause 4 of the "Otherwise" part kicks in and ascent and descent are set correctly:

4. If the operator has the symmetric property then set the target sizesTascent andTdescent toSascent andSdescent respectively...

[fred-wang]

I haven't checked things in details, but I agree with @davidcarlisle that per MathML full symmetric, maxsize, minsize only have effects when the operator is stretchy per https://w3c.github.io/mathml/spec.html#presm_mo_dict_attrs so I don't think the second clause "If the operator has the stretchy" should be modified to force handling symmetric, maxsize or minsize.

[davidcarlisle]

A related mo alignment issue is shown at
https://w3c.github.io/mathml-docs/intent-examples/#id-1-afbf0c9d54fa697fee15f8c64feda4b2
where chrome sets the ] far too low, I meant to report that at the chromium tracker but haven't done so yet.

firefox

chrome

[NSoiffer]

We discussed this again at the meeting today. The feeling is that since the MathML full spec says stretchy must be true for symmetric, min, and max attributes to have an effect, we should "stay the course" and not make a change. Making a change has the potential to break existing MathML usage (although we don't know how much, if any, would break). It is always possible to set stretchy and adjust min or max to prevent stretching the chars, so there is a work-around.

For the record: @dginev mentioned that CSS has a method to set min/max width/height. As noted in the call, this sets the bounding box min/max, not the min/max of a stretchy char. So there is no conflict between these attributes/properties.

@ronkok: we propose to close this issue. Do you object to that?

[ronkok]

@NSoiffer, Thank you for the follow-up. I agree completely with a decision to forego the first edit that I suggested in this issue.

But the original post also contains a second suggested edit to MathML-Core section 3.2.4.3:

I propose a second edit after the line which reads “Otherwise, the stretch axis of the operator is block. The following steps are performed.”

I propose to insert item 2 below.

If the size of in-flow children make it unnecessary to shape a stretchy glyph in the block direction, then fallback to the layout algorithm of 3.2.1.1 Layout of <mtext>.

That edit is still worthwhile. Its adoption would eliminate a vertical mis-placement of parentheses as shown here.

I think closing this issue would be premature until that suggestion is at least considered.

Perhaps you think it should be a separate, stand-alone issue. I would be happy to open one if you prefer.

[NSoiffer]

I was initially confused by your example because it looked good to me. Then I realized it was because I was viewing it in Firefox. In Chrome, it looks bad as you mentioned:

Chrome:
Firefox:

This should be part of the next meeting (January due to the holidays). Hopefully some people will chime in your suggested spec change.

[dginev]

I have been asked by arXiv to raise awareness of the impact of this issue, cross-referencing arXiv/html_feedback#354 (comment)

[bkardell]

The working group discussed this yesterday, minutes follow:

BK: Fred suggested that he expects the spec might not need to be updated and that it is just a bug in chromium, but not firm

DG: the resolution was not to make changes.
DG: there are several things that break. It is hard to to know why. It could be the spec or bug. Needs to find a test showing the problem

DG: I need to read more of Fred's existing tests.

action: DG to find a test he wants to discuss or make one.

NS: we can close this issue if a chrome bug report has been filed.

action BK to identify whether there is a chromium bug for vertical alignment. If there is, close 205, adding a link to the chrome bug.

[ronkok]

I think that Chromium issue #40066018 is the one you seek.

[ronkok]

Chromium issue #40068339 may have the same root cause.

[fred-wang]

This is maybe unrelated to the present discussion, but https://w3c.github.io/mathml-core/#dfn-shape-a-stretchy-glyph takes the target size Tascent + Tdescent as a parameter (since the MATH table only provides advanceMeasurement) and then https://w3c.github.io/mathml-core/#layout-of-operators calculates a Δ to make sure the actual selected glyph and the ideal (Tascent, Tdescent) target would have their vertical centers aligned.

Below is an example, but without debugging more I'm not sure how to interpret the browsers's behavior here. I guess it would be interesting to check what TeX or Microsoft Word do for equivalent setup.

<!DOCTYPE html>
<link
 rel="stylesheet"
 href="https://fred-wang.github.io/MathFonts/LatinModern/mathfonts.css" />
<meta charset="UTF-8">
<style>
 math { font-size: 32pt; }
</style>
<math display="block">
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded height=".25em" depth="0" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded depth=".25em" height="0" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded height=".125em" depth=".125em" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded height=".5em" depth="0" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded depth=".5em" height="0" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded depth=".25em" height=".25em" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded height=".75em" depth="0" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded depth=".75em" height="0" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded height=".375em" depth=".375em" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded height="1em" depth="0" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded depth="1em" height="0" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded depth=".5em" height=".5em" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded height="1.5em" depth="0" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded depth="1.5em" height="0" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded depth=".75em" height=".75em" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded height="2em" depth="0" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded depth="2em" height="0" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded height="1em" depth="1em" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded height="2.5em" depth="0" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded depth="2.5em" height="0" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded depth="1.25em" height="1.25em" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded height="5em" depth="0" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded depth="5em" height="0" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
 <mrow>
  <mo symmetric="false">(</mo>
  <mpadded depth="2.5em" height="2.5em" width="5px" style="background: blue"><mn></mn></mpadded>
 </mrow>
</math>

[fred-wang]

Hi, as I commented on chromium's tracker, I verified that the three bugs https://issues.chromium.org/issues/332931380/blocking are fixed by https://chromium-review.googlesource.com/c/chromium/src/+/5402478 ; so I don't think we need any further changes besides what we agreed in #103

#205 (comment) is a bit more tricky, as it involves embellishment. I believe it should be handled separately. Per MathML Core, the mrow layout stretches the (maybe embellished) operators with the ascent/descent of the "2x" by calling layout with the corresponding block stretch constraints, so I don't see why the vertical alignment of the embellished op can't be correct. I suspect it's a bug in Chromium, but will need some debugging.

[ronkok]

I am closing this issue as complete. Chrome Canary now renders these delimiters at the correct vertical alignment.

A big thank you to @fred-wang. I this this is terrific and I have contributed $500 to MathML-Core-Support.

[fred-wang]

@ronkok you're welcome and thanks for your donation. I'm tentatively converting your original tests to WPT: https://chromium-review.googlesource.com/c/chromium/src/+/5433295 (I was not able to reproduce with custom web fonts used by MathML wpt tests, so I'm using the default font instead, which might not make the test very robust, but let's see).