Re: Embellished operators

Actually, I think it does come up in practice:  in mtables that are  
used to produce commutative diagrams.  With cells that contain  
horizontal arrows with labels above using mover, should they stretch  
to match the label, or the maximum width of the column, or both?  If  
an arrow has a very wide label, as an embellished operator, is its  
natural width the width of the unstretched arrow, or the wide label?

Davide


On Mar 29, 2012, at 1:57 AM, Neil Soiffer wrote:

> 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 Wang
>>> maths-informatique-jeux.com/blog/frederic
>>
>
> -- 
> Frédéric Wang
> maths-informatique-jeux.com/blog/frederic
>