\Big/ and \Big\backslash etc are too small

[physikerwelt]

As feedback to the MathML rendering in Wikipedia, it was realized that some large operators do not stretch the way they'd in LaTeX.

Current rendering:

Expected rendering:

As this problem exists in several browsers, it might be that the spec is too vague how to stretch operators.

[dginev]

@physikerwelt could you also attach the MathML snippets for the examples you're showcasing? I followed the link (2 levels in) and it's still hard to extract that.

It is very helpful to know the exact markup that encounters that rendering. I personally enjoy codepen.io to automate that when possible, but even a short snippet in the issue description helps.

[physikerwelt]

Sorry, I missed to add that we deal with constructs like <mo maxsize="1.623em" minsize="1.623em">|</mo>. I tried https://codepen.io/physikerwelt/pen/dyxYrNv does that help?

[davidcarlisle]

the codepen in firefox and edge

[davidcarlisle]

however the arrows do stretch in edge using Stix Two rather than Cambria Math

[dginev]

A good way to double-check one has STIX Two active over the example is to add in the CSS codepen tab:

@import url('https://fonts.cdnfonts.com/css/stix-two-math');

math {
  font-family: "stix two math";
}

I can reproduce both variants have the arrows stretching with STIX loaded, as with David's screenshots.

For the vertical bars at the end, interestingly they start stretching if you add an explicit stretchy="true" attribute. So I assume something is preventing that default to kick in here?

[physikerwelt]

I hope that by a clever choice of the "correct" UTF8 symbols, things will look good in most browsers, similar to the treatment of \overarc earlier this year.

[physikerwelt]

This is also the way it looks at the Wikipedia help page.

[dginev]

I think with a math font enabled almost all examples above react as expected.
The one case that still surprises me is the sizing of the vertical bars at the very end.

I distilled a smaller set of 4 tests for those, for more targeted discussion, all of which appear specific to | (U+007C). Three of the cases do not stretch in Chrome or Firefox, but - to an unsuspecting observer - should:
https://codepen.io/dginev/pen/KKOVNmy

On closer inspection I understand the cause - it is the Operator Dictionary, which lists "vertical line" as stretchy in the "prefix" and "postfix" form, but has no entry for "infix", which would be the form in these examples.

Still, we have two available techniques to forcing stretch on vertical line today -- adding an explicit stretchy="true" , or adding form="prefix" both of which work well when I test them.

I know people aren't too fond of updating the operator dictionary, and since there is a workaround - is there anything else remaining?

[physikerwelt]

Still, we have two available techniques to forcing stretch on vertical line today -- adding an explicit stretchy="true" , or adding form="prefix" both of which work well when I test them.

Ok, I'll add stretchy to everything that comes out of \big and friends, and it will be fine.

<mo maxsize="1.623em" minsize="1.623em" stretchy="true">|</mo>

PS:
LaTeXML also uses lspae=rspace=0. Moreover, it does not add stretchy for \backslash, which might not be relevant here.

For the test

/ \big/ \Big/ \bigg/ \Bigg/ \dots \Bigg\backslash \bigg\backslash \Big\backslash \big\backslash \backslash

the result

looks to me as if \Big/ > \bigg/ however minsize=maxsize=1.6em for Big and minsize=maxsize=2.1 for bigg.

[physikerwelt]

I updated the codepen (adding stretchy="true" symmetric="true") and added the latest code. The problem | seems to be fixed, but \ still renders incorrect. (This might be a browser bug rather than an issue to be discussed here, but I don't know.)