How to represent brackets equivalent to \big( and friends

[physikerwelt]

The input

\big( \Big( \bigg( \Bigg( \dots \Bigg] \bigg] \Big] \big]

can be represented using

<mo maxsize="1.2em" minsize="1.2em">(</mo>
<mo maxsize="1.623em" minsize="1.623em">(</mo>
<mo maxsize="2.047em" minsize="2.047em">(</mo>
<mo maxsize="2.470em" minsize="2.470em">(</mo>
<mo>…</mo>
<mo maxsize="2.470em" minsize="2.470em">]</mo>
<mo maxsize="2.047em" minsize="2.047em">]</mo>
<mo maxsize="1.623em" minsize="1.623em">]</mo>
<mo maxsize="1.2em" minsize="1.2em">]</mo>

Note: That the em values are defined in orinate from #75.
While this renders well in Firefox at least, the following example fails

<mo maxsize="2.470em" minsize="2.470em">|</mo>
<mo maxsize="2.047em" minsize="2.047em">|</mo>
<mo maxsize="1.623em" minsize="1.623em">|</mo>
<mo maxsize="1.2em" minsize="1.2em">|</mo>

Maybe there is another UTF-8 symbol which better stretches compared to |.

However, this would require special treatment for any argument of the \big macros. Thus I wonder if there is a MathML inherent way to model the LaTeX construct.

See also

• percentage of minsize/maxsize mathml-core#103
• TeX2MathML converter implementation guidelines mathml-docs#39
• https://phabricator.wikimedia.org/T320910
• https://phabricator.wikimedia.org/T350738
• https://phabricator.wikimedia.org/T351907
• https://phabricator.wikimedia.org/T352735

[fred-wang]

Note that w3c/mathml-core#103 is about percentage values, it does not change the interpretation of em values.

[fred-wang]

(edit: the fix to make sure minsize/maxsize preserves symmetry may still be relevant though)

[physikerwelt]

@fred-wang thank you. I feel that this is not the most intuitive way to implement \big I would prefer something like <mo style="font-size: larger;">.

[davidcarlisle]

@physikerwelt I don't think font-size is a good mechanism for implementing larger delimiters, \big and stretching generally isn't usually implemented by using a larger font (which would imply heavier stroke weights ,and expanding width in proportion to height) but by choosing or constructing a larger delimiter within the same font.

[physikerwelt]

@davidcarlisle I didn't mean to change the implementation (in the browser). My goal was to find a better way to find a synonym (or equivalent concept) for the tex concept in MathML. Using maxsize and minsize simultaneously feels like abusing implementation details to achieve the goal. When we update MathML (at least the unfrozen parts), I think, it makes sense to discuss how frequently used concepts in Tex (as most content originates from Tex) can be expressed in MathML. Or do we think that the \big concepts should be avoided in most cases in tex? From a semantics perspective, I would in almost all cases prefer \bigl which makes putting superscripts like \bigr)^2 easier.

[dginev]

On a purely MathML ergonomics side, I suspect the missed opportunity is using a single attribute as a shorthand for setting minsize and maxsize to the same value.

You can see something similar in CSS, which has min-height and max-height, but you also have a standalone height property (and similarly for width), which avoids some pain.

Since the behavior here relies on the stretching algorithm (which was very good to learn and keep in mind), maybe we would have needed a new stretchsize attribute in a MathML-only formulation.

In a CSS world one would have wished for some new properties. Possibly math-stretch-size to use as

<mo style="math-stretch-size: 2.047em">(</mo>

for precise stretch sizing using matching min+max values. And likely also wish for the MathML minsize and maxsize getting matching CSS properties, maybe math-stretch-min-size, math-stretch-max-size.

I took inspiration for some of that from Fred's suggestion in w3c/mathml-core#218 for new CSS properties doing the job of lspace and rspace.

[davidcarlisle]

@physikerwelt

I think, it makes sense to discuss how frequently used concepts in Tex (as most content originates from Tex) can be expressed in MathML. Or do we think that the \big concepts should be avoided in most cases in tex? F

That's my point though: TeX does not change fonts for \big or \left etc :it selects delimters from the same font (in unicode tex) or the same font or its extension font (in classic tex) it never chooses a delimiter from a font of larger nominal design size.

[brucemiller]

The formulation certainly feels awkward, but as @davidcarlisle points out, there are two distinct cases: choosing a glyph from a font of a certain size vs choosing/stretching/synthesizing a glyph from the current font to be of a certain size.

The problem with your 2nd example, using "|" in Firefox, appears to be that under certain circumstances, Firefox is not defaulting "|" to be stretchy; adding an explicit stretchy="true" fixes that. It feels like a bug, but may be just an question of what form it is using and how it has looked up "|" in the dictionary.

[physikerwelt]

I am starting to realize that I need to understand the implementation details better. If I had to implement stretching I had no idea how to do that for a general utf-8 char. I encountered similar problems with horizontal stretching (brucemiller/LaTeXML#2317 (comment)). How would for example \big A look like, would there be an exception?

[davidcarlisle]

Stretching is implemented by the font, so from a math renderer point of view there is nothing to do for "a general utf-8 char" you just ask the font for the character if the font doesn't contain a recipe for extending the character you just get it at normal size. As classic tex can't look in to the font the macro set has to declare which characters are extendable (by giving them a non zero \delcode) so typically A has not got a \delcode so \big A is an error.

[dginev]

Here is a codepen reproducing some of the discussion so far:
https://codepen.io/dginev/pen/LYvQBXM

The default stretching of | doesn't seem to work in Firefox, but despite that a set minsize is respected. Curious.

As per David's explanation A is inert to stretching in STIX Two Math, which is probably a good feature. There are fonts where people may get tempted to use a highly decorative version of say the Latin letter L, instead of the math-oriented ⌊ (U+230A), if it was possible to stretch any char.

[physikerwelt]

That's good. In texvc, we define a set called DELIMITER, which can follow BIG. So expressions like \big A would not even pass the security check.

[NSoiffer]

A general suggestion for people posting codepen.io examples: include some text explaining what each example is meant to demonstrate. Each browser potentially displays the example differently (hopefully that comes to an end in my lifetime), so it isn't always clear what the example demonstrates, especially when coming back to it later.