\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.)

[physikerwelt]

The new rendering https://en.wikipedia.beta.wmflabs.org/wiki/T375960 looks better in Chrome now, but is still broken in FF. Are you aware of a ticket for the problem in FF?

[tmke8]

If you use set minus (like Temml does) instead of the backslash, then it seems to work in Firefox, but then it doesn't work in Chrome anymore...

[physikerwelt]

Maybe there is char that works in both Chrome and Firefox?

[davidcarlisle]

@dginev's observation that stretchy default is only specified for the delimiter case not infix is good and is somehow related to historical development here in that classic tex only had \left and right to stretch delmiters, e-tex added \middle in the mid 1990s but even now it is less well used in most tex packages.

The question of whether it's possible to change the operator dictionary defaults at all has just been raised in #260

Related to that, MathML can not specify any character stretches, it can only specify that it may stretch if implemented by the font.

Guidance on which characters a math font should specify as stretchy (which basically means the opentype tables within the font have to specify the glyphs for the component parts and how they are combned in vertical or horizontal direction) comes from Unicode report TR25 and in particular its associated data file MathClass-15

https://unicode.org/Public/math/revision-15/MathClassEx-15.html

which currently says

The C[lose], O[pen], and F[ence] operators are stretchy. In addition, some binary operators such as U+002F [/] are stretchy as noted in the descriptive comments.

So, again in line with @dginev's comment above anything that is marked as an open or close delimiter or fence (which can be used as either open or close) should be expected to be stretchy, but binary operators are considered individually.

MathClass-15 specifys three stretchy B operators

U+002F /

U+005C \

U+2044 ⁄

It then specifies a further 60 characters that are categorised as C, O or F

0028;O
0029;C
005B;O
005D;C
007B;O
007C;F
007D;C
2016;F
2308;O
2309;C
230A;O
230B;C
231C;O
231D;C
231E;O
231F;C
2772;O
2773;C
27E6;O
27E7;C
27E8;O
27E9;C
27EA;O
27EB;C
27EC;O
27ED;C
27EE;O
27EF;C
2980;F
2982;F
2983;O
2984;C
2985;O
2986;C
2987;O
2988;C
2989;O
298A;C
298B;O
298C;C
298D;O
298E;C
298F;O
2990;C
2991;O
2992;C
2993;O
2994;C
2995;O
2996;C
2997;O
2998;C
2999;F
299A;F
29D8;O
29D9;C
29DA;O
29DB;C
29FC;O
29FD;C

If we want any changes to any of these classifications we should raise with the Unicode group maintaining UTR 25 for consideration in any future MathClass-16. (There is some overlap of members between the relevant groups here)

[physikerwelt]

Ok. If I got this right, there is a bug in firefox that prevents U+005C \ from stretching, but it's the only reasonable char for the LaTeX command \backslash. So I think there is nothing left to do here (except for Mozilla). Thank you all for your help.