Re: lmoustache/rmoustache as stretchy delimiters

On 08/30/2015 08:45 AM, Neil Soiffer wrote:
> Are you sure you have the mapping of lmoustache/rmoustache correct? It
> seems very strange to map them to a piece of a /vertical /delimiter.
The unicode.xml file from http://www.w3.org/TR/xml-entity-names/ defines
"moustach" LaTeX macros and entity names:

      <character id="U023B0" dec="9136" mode="math" type="other">
         <unicodedata category="Sm" combclass="0" bidi="ON" mirror="N"
mathclass="R"/>
         <afii>EEE7</afii>
         <latex>\lmoustache </latex>
         <mathlatex set="unicode-math">\lmoustache</mathlatex>
         <AMS>\lmoustache</AMS>
         <IEEE>\lmoustache</IEEE>
         <entity id="lmoust" set="STIX"/>
         <entity id="lmoust" set="9573-1991-isoamsc">
            <desc>/lmoustache</desc>
         </entity>
         <entity id="lmoust" set="9573-2003-isoamsc">
            <desc>/lmoustache</desc>
         </entity>
         <entity id="lmoustache" set="mmlalias">
            <desc>alias ISOAMSC lmoust</desc>
         </entity>
         <description unicode="3.2">UPPER LEFT OR LOWER RIGHT CURLY
BRACKET SECTION</description>
      </character>
      <character id="U023B1" dec="9137" mode="math" type="other">
         <unicodedata category="Sm" combclass="0" bidi="ON" mirror="N"
mathclass="R"/>
         <afii>EEE8</afii>
         <latex>\rmoustache </latex>
         <mathlatex set="unicode-math">\rmoustache</mathlatex>
         <AMS>\rmoustache</AMS>
         <IEEE>\rmoustache</IEEE>
         <entity id="rmoust" set="STIX"/>
         <entity id="rmoust" set="9573-1991-isoamsc">
            <desc>/rmoustache</desc>
         </entity>
         <entity id="rmoust" set="9573-2003-isoamsc">
            <desc>/rmoustache</desc>
         </entity>
         <entity id="rmoustache" set="mmlalias">
            <desc>alias ISOAMSC rmoust</desc>
         </entity>
         <font name="hlcrv" pos="123"/>
         <description unicode="3.2">UPPER RIGHT OR LOWER LEFT CURLY
BRACKET SECTION</description>
      </character>

and I didn't find another characters to represent moustaches in the
MathML Operator dictionary...
> Of course, there's nothing stopping you from adding them to Gecko's
> operator dictionary, but if we added these to the one in the spec, why
> not add all the other pieces?
To be clear: I'm only interested in making MathML work in concrete use
cases, not to extend the spec to cover non-practical cases via abstract
generalization as that happened when I raised the issue with menclose's
updiagonalstrike. Gecko and itex2MML have used these mappings for a long
time and I just checked that MathJax does the same, so that's a case
worth considering.
> In general, I suppose it's not an unreasonable assumption to assume
> that if a piece of a stretchy operator is used as an operator, then it
> has the properties of the entire delimiter.
That's what David says but I'm not sure we can make any assumption or
reject the operator just because Unicode defines it as a piece of
something else. I suspect what happened is that LaTeX/MathML people just
wanted to implement \lmoustache & \rmoustache operators and they just
took these two U+23B0 and U+23B1 characters because Unicode did not have
specific code points to represent these operators. Probably from a
"semantic" point of view it would have been better to create such
separate code points...
> On the other hand, if someone is using a piece of a stretchy char, I
> suspect they are making up their own operator and who knows what its
> default properties should be.
However when several popular applications use the same operators, adding
it to the operator dictionary will help to be consistent. Like Gecko,
MathJax treats 23B0 & 23B1 with default values fence, stretchyand
symmetric and no spacing around:

https://github.com/mathjax/MathJax/blob/master/unpacked/jax/element/mml/jax.js#L1761
https://github.com/mathjax/MathJax/blob/master/unpacked/jax/element/mml/jax.js#L1480

WebKit relies only on the official MathML operator dictionary so it will
use the default value (not fence, not stretchy, not symmetric and
thickmathspace around)

For "\left\lmoustache x \right\rmoustache", itex2MML generates

<mrow><mo>&lmoustache;</mo><mi>x</mi><mo>&rmoustache;</mo></mrow>

and MathJax generates the same with explicit fence and stretchy. So the
"symmetric" and surrounding spacing will be wrong in WebKit and in any
other MathML rendering engines that do not have "private" entries for
these two characters.

Also the same command does not work in TeXZilla, because it relies on
the official operator dictionary and so does not know that moustaches
are a stretchy fences. LaTeXML also fails to parse this expression.

Finally, when discussing with designers of OpenType fonts with a MATH
table, I often refers to the official MathML Operator Dictionary to
indicate which characters should be stretchable. At the moment existing
fonts do not have constructions for 23B0 & 23B1 while Gecko has it in
its private Unicode constructions so we again obtain inconsistent
results. For example, Gecko is able to stretch moustaches with the
deprecated STIX General but not the newest STIX Math (hopefully this
will be fixed in version 2, see
http://sourceforge.net/p/stixfonts/tracking/67/)

-- 
Frédéric Wang
maths-informatique-jeux.com/blog/frederic