Re: lmoustache/rmoustache as stretchy delimiters

I believe that the entry in http://www.w3.org/TR/xml-entity-names is wrong.

I wrote an example in LaTeX and 23B0 & 23B1 are *not* the glpyhs that LaTeX
produces. Not surprisingly, the characters that LaTeX uses look like the
left and right sides of a mustache. I've attached a source file and PDF
file, but I don't know if the w3 mailer will pass these on through. I also
attached an image of the PDF because I don't know if pdflatex embedded the
fonts it used into the PDF file.

It is good to have renderers be consistent, but MathJax is not consistent
with what it is trying to emulate. Making Gecko be consistent with that
mistake seems like an additional mistake.

Neil Soiffer
Senior Scientist
Design Science, Inc.
www.dessci.com
~ Makers of MathType, MathFlow, MathPlayer, MathDaisy, Equation Editor ~


[image: Inline image 1]

On Sun, Aug 30, 2015 at 1:14 AM, Frédéric WANG <fred.wang@free.fr> wrote:

> 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, stretchy and
> 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 Wangmaths-informatique-jeux.com/blog/frederic
>
>