Re: Embellished operators

Sorry for not following up.  I was at a conference during the last working
group meeting and this didn't get discussed.  I'll bring it up and see if
we can get some official position on it at our meeting next week.

Based on what you and Dave said, I lean towards option 2.  Actually, I
rather remove the rule (which I think Dave wants too), but that's not an
errata and would need to be done in a spec revision.  In any case, I doubt
this comes up in real life and I suspect it is near the bottom of the heap
in importance in bug reports for Firefox, MathPlayer, etc.  Still, it's a
hole in the spec and needs to be filled...

   Neil


On Tue, Mar 27, 2012 at 12:47 PM, Frédéric WANG <fred.wang@free.fr> wrote:

>  Any update on this issue?
>
> From the previous discussion, It seems to me that a clarification would be
> to say that the "base size" of an embellished op includes stretching that
> has already taken place in the subexpression. This would be consistent for
> both vertical and horizontal stretching rules. That's how I plan to solve
> the Firefox's bug.
>
>
> On 25/02/2012 02:51, Dave Barton wrote:
>
> 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 Wangmaths-informatique-jeux.com/blog/frederic
>
>
>
> --
> Frédéric Wangmaths-informatique-jeux.com/blog/frederic
>
>