Re: Embellished operators

I agree with Frédéric, that option 2 seems most consistent. The spec (mostly) says a stretchy operator should stretch to the maximum of the non-stretchy sizes that should influence it, if there are any. So in Frédéric's cases of a stretchy horizontal operator with nested under/over embellishments, or a stretchy vertical operator with nested embellishments to its left or right (i.e. purely space-like elements in a same <mrow>), the operator should stretch to the maximum of the sizes.

Actually, I really only agree with this for horizontal stretching, because I don't like the mrow rule that Neil mentions, and states is probably not implemented in MathPlayer or Mathematica. Currently mtext elements are defined to be space-like (http://www.w3.org/TR/MathML3/chapter3.html#id.3.2.7.4), so in

<math display="block" alttext='f(A/B)+∫\text"some differential"'>
<mrow>
 <mi>f</mi>
 <mrow>
  <mo>(</mo>
  <mfrac>
   <mi>A</mi>
   <mi>B</mi>
  </mfrac>
  <mo>)</mo>
 </mrow>
 <mo>+</mo>
 <mrow>
  <mo>∫</mo>
  <mtext>some differential</mtext>
 </mrow>
</mrow>
</math>

the final integral sign should stretch to cover the earlier tall fraction, according to the spec. This is clearly not intended by the author. I think the rules for embellished operators and space-like elements are too aggressive. One can now add spacing using CSS, so <mtext> elements are not usually just "space-like". Also without the <mrow> rule for embellished operators, an author could control stretching of e.g. this integral sign by choosing whether to put it in a nested <mrow> or not.

I am working on the MathML code in WebKit, as a volunteer. I haven't gotten to horizontal stretching or even all the rules for embellished operators yet, but this is my personal thinking so far.

Cheers, Dave B.

On Feb 24, 2012, at 12:21 AM, Frédéric WANG wrote:

> 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).
>> 
>> ...
>> 
>> 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).
>> 
>> ...
>> 
>> On Thu, Feb 23, 2012 at 1:02 AM, Frédéric WANG <fred.wang@free.fr> wrote:
>> ... 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> 
>> 
>> ...
>> 
> 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