Embellished operators
Frédéric WANG
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>→</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>→</mo>
<mspace width="200px"/>
</munder>
</mover>
</math>
and
<math>
<mover>
<mspace width="200px"/>
<munder>
<mo>→</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
Paul Topping
I think you have touched the tip of an iceberg with your observations here. Robert Miner and I had many discussions of problems like this. Presentation MathML’s domain of description tries to allow precise formatting via specific dimensions and font and character choices as well as logical description of math constructs. It always seemed to me to be playing with fire. Left up to me, I would have had MathML elements and attributes map to concepts in math’s visual grammar in order to allow the formatter to do a better job. Unfortunately, this places a large burden on the author to get it right, something that is a big problem for Content MathML.
Paul
Patrick Ion
I am puzzled that it would be thought that the base, the first argument of
an element of type <mover>, <munder> or <munderover> might be expected
to change its size automatically depending on the embellishment. That
seems to be what's being asked for in the examples. If that isn't the intention
then I think the sizes to be expected are already well defined by the default
sizes of the construction's base elements.
See
http://www.w3.org/TR/MathML3/chapter3.html#3.1.3.2
Patrick
P.S. Murray's first message and example displayed perfectly for me in Thunderbird
10.0.2 on Mac OS X 10.7.3.
Frédéric WANG
(Tree1) :=
<mrow>
<mo>|</mo>
<mspace height="100px" depth="100px"/>
</mrow>
the | stretches to cover the height+depth of the mspace. That's the
vertical stretching rule for <mrow>:
http://www.w3.org/TR/MathML3/chapter3.html#id.3.2.5.8.2
But Tree1 is an mrow whose children is one embellished op <mo>|</mo> and
a space-like element <mspace/>. Thus it is itself an embellished op:
http://www.w3.org/TR/MathML3/chapter3.html#id.3.2.5.7.3
Now in
(Tree2) :=
<math>
<mrow>
(Tree 1)
<mspace height="50px" depth="50px"/>
</mrow>
</math>
the same vertical stretching rule applies: the core of the embellished
operator (Tree 1) stretches to cover the height+depth of the mspace.
Hence there are two possibilities for stretching the <mo>|</mo> element:
one in Tree1 (height+depth=200px) and one in Tree2 (height+depth=100px).
Which one do we choose?
I'm thinking I have to choose the outermost possibility (100px) or
stretch to the maximum possible size (200px)?
How do other rendering agents implement it?
Frédéric WANG
MathJax v2.0 beta: stretch to the maximum size of the mspace's
MathPlayer 3.0 beta 1: stretch to the size of the innermost mspace.
Firefox 10: stretch to the size of the outermost mspace. (probably like
MathPlayer in earlier versions when embellished op support was not
completely implemented)
--
Fr�d�ric Wang
maths-informatique-jeux.com/blog/frederic
Neil Soiffer
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
Frédéric WANG
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