Dear all, It seems that lmoustache/rmoustache have been used as MathML stretchy operators for a long time. For example, itex2MML provides the \lmoustache & \rmoustache commands to generate these delimiters: https://golem.ph.utexas.edu/~distler/blog/itex2MMLcommands.html#itex2MMLDelim and Gecko has entries for U+23B0 and U+23B1: https://dxr.mozilla.org/mozilla-central/source/layout/mathml/mathfont.properties?offset=300#1137 However, the MathML Operator dictionary does not contain any mention of lmoustache/rmoustache: http://www.w3.org/TR/MathML3/appendixc.html Should they be added to the official MathML dictionary or are they excluded on purpose? Frédéric

On 28/08/2015 16:05, Frédéric Wang wrote: > Dear all, > > It seems that lmoustache/rmoustache have been used as MathML stretchy operators for a long time. For example, itex2MML provides the \lmoustache & \rmoustache commands to generate these delimiters: > > https://golem.ph.utexas.edu/~distler/blog/itex2MMLcommands.html#itex2MMLDelim > > and Gecko has entries for U+23B0 and U+23B1: > > https://dxr.mozilla.org/mozilla-central/source/layout/mathml/mathfont.properties?offset=300#1137 > > However, the MathML Operator dictionary does not contain any mention of lmoustache/rmoustache: > > http://www.w3.org/TR/MathML3/appendixc.html > > Should they be added to the official MathML dictionary or are they excluded on purpose? > > Frédéric > I'm fairly sure they were not excluded on purpose. { and } have <operator-dictionary priority="20" form="prefix" symmetric="true" fence="true" stretchy="true" lspace="0" rspace="0"/> <operator-dictionary priority="20" form="postfix" symmetric="true" fence="true" stretchy="true" lspace="0" rspace="0"/> so I suspect exactly the same entries could be added to [lr]moustache? David [speaking personally, not a WG decision] ________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Microsoft Office 365. ________________________________

Hi www-math, On the MathJax issue tracker <https://github.com/mathjax/MathJax/issues/1228> we had a discussion revolving around embellished operators and line breaks. The example from a user was <math xmlns="http://www.w3.org/1998/Math/MathML"> <mtext>A</mtext> <mo>+</mo> <mtext>B</mtext> <mspace linebreak="newline" /> <mtext>C</mtext> </math> which won't have a line break in MathJax rendering because the spec seems to say it's one big embellished operator. My question is: shouldn't a pure linebreak end the scope of an embellished operator instead? Personally, I find it odd that mtext is considered space-like. It does not seem to meet the criteria of the spec ("typically render as whitespace", "do not affect the mathematical meaning" -- neither is typical for mtext). It seems even more problematic in an HTML5 context, where mtext is one entry point for HTML mixing. Best regards, Peter.

On 03/08/2015 15:46, Peter Krautzberger wrote: > Hi www-math, > > On the MathJax issue tracker > <https://github.com/mathjax/MathJax/issues/1228> we had a discussion > revolving around embellished operators and line breaks. > > The example from a user was > > <math xmlns="http://www.w3.org/1998/Math/MathML"> > <mtext>A</mtext> > <mo>+</mo> > <mtext>B</mtext> > <mspace linebreak="newline" /> > <mtext>C</mtext> > </math> > > which won't have a line break in MathJax rendering because the spec > seems to say it's one big embellished operator. > > My question is: shouldn't a pure linebreak end the scope of an > embellished operator instead? > > Personally, I find it odd that mtext is considered space-like. > > It does not seem to meet the criteria of the spec ("typically render as > whitespace", "do not affect the mathematical meaning" -- neither is > typical for mtext). It seems even more problematic in an HTML5 > context, where mtext is one entry point for HTML mixing. > > Best regards, > Peter. > Hmm partly the problem may be that the text that pulls in adjacent "space like" elements into the embellished operator comes from mathml 1.0 which didn't have the linebreak= attribute (introduced in mathml2 ) or the more general linebreak controls introduced at mathml3. So there is room for some creative interpretation I think. In particular does the spec actually say that you can not break within an embellished operator? That's not to say we shouldn't consider an adjustment of the text here but just as a matter of current interpretation. David [most definitely speaking for myself not giving the formal WG position here...] ________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Microsoft Office 365. ________________________________

> does the spec actually say that you can not break within an embellished > operator? No, the spec is silent on how line breaks interact with embellished operators. But in terms of spacing around embellished operators, it is clear that the operator is to be treated as a unit. So, for example <math> <mi>A</mi> <mrow> <mtext>B</mtext> <mo>+</mo> <mtext>C</mtext> </mrow> <mi>D</mi> </math> has an embellished operator "B+C" and the space for that operator goes outside the <mrow>, giving "A B+C D" (rather than "AB + CD"). So if you had <math> <mi>A</mi> <mrow> <mtext>B</mtext> <mo linebreak="true">+</mo> <mtext>C</mtext> </mrow> <mi>D</mi> </math> I would expect to see the line break to be outside the embellished operator B+C, so it should occur between the A and the B giving A B+C D by default. (This is, in fact, what MathJax does.) The spec is silent on this topic, but that is what seems most in line with the spirit of embellished operators. It is less clear what <math> <mi>A</mi> <mrow> <mtext>B</mtext> <mo>+</mo> <mtext>C</mtext> <mspace linebreak="newline"/> <mtext>D</mtext> </mrow> <mi>E</mi> </math> should do. Should it be A B+C D E which breaks up the embellished operator? Should it be A B+CD E which doesn't? Or something else? The spec doesn't say one way or the other. Going back to whether it makes sense for <mtext> to be space-like, it doesn't seem right for the spacing to change depending on whether there is just one operator followed by an <mtext> versus an operator followed by an <mtext> and an <mi>. Should the + in <math> <mrow> <mtext>A</mtext> <mo>+</mo> <mtext>B</mtext> </mrow> </math> really have such different spacing from <math> <mrow> <mi>X</mi> <mtext>A</mtext> <mo>+</mo> <mtext>B</mtext> <mi>X</mi> </mrow> </math> so that the spacing of the + is determined by the X's that are several elements away? That doesn't seem very intuitive. And Peter's point about <mtext> being the entry point for HTML5 elements is a good one, I think, as that may make <mtext> more widely used. I'm sure there are use-cases where it makes sense for <mtext> to be space-like, but I can't think of any off the top of my head (other than when the content of the <mtext> is actually just space characters). Davide