RE: [mathjax-dev] Embellished operators

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

 

From: mathjax-dev@googlegroups.com [mailto:mathjax-dev@googlegroups.com] On Behalf Of Frédéric WANG
Sent: Thursday, February 23, 2012 1:02 AM
To: www-math@w3.org; mathjax-dev@googlegroups.com
Subject: [mathjax-dev] Embellished operators

 

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