W3C home > Mailing lists > Public > www-math@w3.org > February 2012

Re: Embellished operators

From: Frédéric WANG <fred.wang@free.fr>
Date: Fri, 24 Feb 2012 09:21:43 +0100
Message-ID: <4F474897.7060100@free.fr>
To: Neil Soiffer <NeilS@dessci.com>
CC: "www-math@w3.org" <www-math@w3.org>, mathjax-dev@googlegroups.com
On 24/02/2012 07:47, Neil Soiffer wrote:
> I hope I'm stating this correctly:  the embellished operator rules are 
> clear with the exception of the case of an mrow that contains an 
> embellished operator and space-like elements (the last rule in 
> http://www.w3.org/TR/MathML3/chapter3.html#id.3.2.5.7.3).
>
> So for your two less trivial vertical stretching rules:
>
> 1.  the first should have the arrow stretch to 200px because it is 
> part of the inner munder. and the other part of the outer mover is 
> smaller.
>
> 2.   the second is slightly trickier.  The inner munder's initial 
> width is 100px, but because the arrow is at the "core" and is hence an 
> embellished operator, laying out the outer mover means that it needs 
> to stretch to cover the 200px.  Hence this too should be 200px.  This 
> is based on the following from the spec for *horizontal* stretching:  
> "...the |mo| element at its core, should stretch to cover the width of 
> the other direct sub-expressions in the given element..."
>
>
> For the vertical case, it is clear that if there was only one mrow, 
> then the maximum size would be used (200px).  But that's not the 
> case.  As your analysis in a subsequent email demonstrated,  the inner 
> mrow should cause that mrow to be 200px.  But since it should act as 
> an embellished operator, it is subject to further stretching.
>
> There are two possibilities:
> 1.  We ignore the stretching caused by the inner mrow and consider the 
> "normal" height to be be that of the unstretched "|".  In this case, 
> the answer should be that the result is 100px because it should 
> stretch to the height f the space in the outer mrow.
>
> 2.  We consider the stretched height of "|" caused by the inner mrow's 
> stretching to be the normal height of the operator.  In this case, the 
> outer mrow doesn't stretch it further, so the answer is 200px.  If the 
> outer mrow had a larger stretch than the inner one, than the largest 
> value should be used.
>
> The spec is silent on what to do here (AFAIK) -- the rule mentioned 
> for horizontal stretching is not listed as part of the vertical 
> stretching rules.  I'm leaning towards '1' as being the correct 
> interpretation, so the result should be 100px.
>
> I haven't looked at the code, but I suspect that MathPlayer chooses 
> the inner one (even if the outer one is larger) because it doesn't 
> implement the "|mrow| whose arguments consist (in any order) of one 
> embellished operator and zero or more space-like elements" rule.
>
> I tried Mathematica and it behaves like MathPlayer (I didn't implement 
> this part of the code in MathPlayer, but did in Mathematica).  So both 
> are doing it wrong (probably because they didn't implement this rule).
>
> Based on what you reported, it sounds like MathJax is doing it wrong 
> under option '1' above, but correct under '2'.  Firefox sounds is 
> doing the opposite:  correct under option '1', but wrong under '2'.
>
> If there is a clear consensus on what should happen, we can add an 
> errata to the spec to clear up this case.
>
> Neil Soiffer
> Senior Scientist
> Design Science, Inc.
> www.dessci.com <http://www.dessci.com/>
> ~ Makers of MathType, MathFlow, MathPlayer, MathDaisy, Equation Editor ~
>
>
> On Thu, Feb 23, 2012 at 1:02 AM, Frédéric WANG <fred.wang@free.fr 
> <mailto:fred.wang@free.fr>> wrote:
>
>     Hi all,
>
>     I'm thinking again about the rules for embellished operators and
>     it seems to me that some elements are particular. For example if
>     we ask how to determine the stretching of something like:
>
>     <math>
>     <mover>
>     <mo>&#x2192;</mo>
>     <mtext>over</mtext>
>     </mover>
>     </math>
>
>     The obvious answer is that the arrow should stretch to cover the
>     over script. OK. However one can also say that the <mover> is an
>     embellished element as a whole. Since is has no siblings, the
>     arrow should have its default size.
>
>     To give slightly less trivial examples, what should be the size of
>     the arrows (100px or 200px?) in these examples:
>
>     <math>
>     <mover>
>     <mspace width="100px"/>
>     <munder>
>     <mo>&#x2192;</mo>
>     <mspace width="200px"/>
>     </munder>
>     </mover>
>     </math>
>
>     and
>
>     <math>
>     <mover>
>     <mspace width="200px"/>
>     <munder>
>     <mo>&#x2192;</mo>
>     <mspace width="100px"/>
>     </munder>
>     </mover>
>     </math>
>
>     An example with vertical stretching rules:
>
>     <math>
>     <mrow>
>     <mspace height="50px" depth="50px"/>
>     <mrow>
>     <mo>|</mo>
>     <mspace height="100px" depth="100px"/>
>     </mrow>
>     </mrow>
>     </math>
>
>     (I wonder if an attribute like embellishedop = "false" could help
>     to prevent this kind of ambiguity?)
>
>     I noticed this because implementing the complete embellished op
>     rules caused a regression in Mozilla with MathML code generated by
>     MathJax:
>     https://bugzilla.mozilla.org/show_bug.cgi?id=687807
>
>
Thanks for your answer, Neil.

It seems that we all agree on the results of munderover, however it is 
not consistent with Option '1' for the vertical case with mrow's 
(consider what you said for the first non-trivial case). Firefox is 
(more or less) using option '1' and now it supports all the embellished 
op rules, that's even causing a bug for the trivial test case when an 
<mrow> is added around the <mover> (reported by MathJax folks).

Karl's interpretation and MathJax's implementation seems to be option 
'2'. I don't really mind between '1' and '2' in the vertical case 
(although I suspect '2' will be more work to implement it in Firefox) 
but to be consistent with the horizontal case, I would rather propose 
option '2'.

-- 
Frédéric Wang
maths-informatique-jeux.com/blog/frederic
Received on Friday, 24 February 2012 08:20:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 24 February 2012 08:20:55 GMT