Illustration of the newly added support for embellished operators. More feedback is needed about the semantics in order to ensure that the code does what it is supposed to be doing. I will be attaching a screenshot for the MathML fragment hereafter. The screenshot shows different rendering of <mover> and <munder>. Which one is the expected rendering, while considering that a particular subset can again be wrapped within various other tags. For example, what should then be the rendering of <msup> <mover>...</mover> <mi>x</mi> </msup> <msub> <mover>...</mover> <mi>x</mi> </msub> <math xmlns="http://www.w3.org/1998/Math/MathML"> <mover> <mi>vectorrrrrrrrrrrrr</mi> <msubsup> <mo>&RightArrow;</mo> <mi>a</mi> <mi>b</mi> </msubsup> </mover> A special family of &Delta;-vector denoted as <mover> <mi>vectorrrrrrrrrrrrr</mi> <msub> <mo>&RightArrow;</mo> <mo>&Delta;</mo> </msub> </mover> <munder> <mi>vectorrrrrrrrrrrrr</mi> <msubsup> <mo>&RightArrow;</mo> <mi>a</mi> <mi>b</mi> </msubsup> </munder> A special family of &Delta;-vector denoted as <munder> <mi>vectorrrrrrrrrrrrr</mi> <msub> <mo>&RightArrow;</mo> <mo>&Delta;</mo> </msub> </munder> </math>

This bug has not been touched for more than nine months. In most cases, that means it has "slipped through the net". Please could the owner take a moment to add a comment to the bug with current status, and/or close it. Thank you :-) Gerv

The current behavior is that, given the markup: <munder> <mi>vectorrrrrrrrrrrrr</mi> <msub> <mo>&RightArrow;</mo> <mo>&Delta;</mo> </msub> </munder> The <mo>&RightArrow;</mo> is stretched to cover the base <mi>vectorrrrrrrrrrrrr</mi>, then <msup> is constructed using the stretched arrow, and so, after placing the superscript, the resulting width of the <msup> is wider than the initial <mi>vectorrrrrrrrrrrrr</mi>, and therefore when the two boxes are combined vertically by <munder>, they are centered by default on the widest width, and we get what we see. If there was an align attribute to disable the centering, the arrow could have been aligned on the left edge of <mi>vectorrrrrrrrrrrrr</mi>. Haven't got further feedback.

I feel that the current behavior is correct. Centering is consistent and works in general. Any other scheme suffers difficulties once we leave the realm of trivial examples. Interestingly, the MathML spec. doesn't seem to specify anything about rendering and the example they give only illustrates an unusual case.

Other examples provided by Steve: http://www.hipnt.com/MathML/embells.xml Steve, do you now understand what is happening? Your examples had some questions. These boil down to the explanation I gave earlier in comment #4. In each case in your series, the thing to always keep in mind is that the stretchy element (if taken in isolation) is sufficient to cover its base. Then, when combined with the embellishments (scripts, etc), you get another box, and it is the resulting box that is used subsequently for the centering. That's why the stretchy element looks like it was "big". If the box was positioned differently, the stretchy element would neatly sit above (or below) its base and there wouldn't be any visual defect. But there is no model that will allow doing such positioning in a consistent manner with complex markups as you noticed yourself in your previous comment. In your series, the cases where not much seems to happen are just because there is no surrounding <mrow> beneath <math>. The plain usage of <math> has some limitations w.r.t. stretchy elements due to the fact that <math> offers linebreaking to the detriment of other MathML specific functions such as balanced stretching of dangling pieces during linebreaking. A trade-off that I have deemed okay for now.

There are some invalid examples such as the one with the question "Labeled arrow. Why did it shrink?" The markup for that doesn't entitle the inner arrow to stretch from outside its containing <mrow>. And BTW, it didn't shring -- it retained its default size.

Replying to #6: yes, I now understand what's happening here (after building a large matrix of examples). The last thing to be understood what that the stretchy operators (arrows, at least) also make sure they are bigger than any embellishments they might have. This behavior (which seems right) was interfering with my interpretation of other factors. I didn't observe any different behavior after adding an <mrow> inside the outer <math>, though I do agree with comment #7 that some of my markup was amateurish.

>The last thing to be understood what that the stretchy operators (arrows, at >least) also make sure they are bigger than any embellishments they might have. This was a side-effect of the complex nature of the problem. It has been improved by the tune-up that I checked in. Now, embellishments are selectively included or excluded during size calculations whenever appropriate. Hence stretchy operators are not always as big as any embellishments they might have, unless in a situation where they should cover their embellishments as well.

Add a doctype to the original testcase

In addition to the alignment issue, here is what we should treated as embellished operators according to http://www.w3.org/TR/MathML3/chapter3.html#id.3.2.5.7.3 - first element of a semantics - mstyle, mphantom, or mpadded used as mrow. - mrow whose arguments consist (in any order) of one embellished operator and zero or more space-like elements.

Just a test to check that we can pass the width of embellishments.

BTW, it seems that the operator is does not always stretch to the exact size.

Here is a patch that allows to handle the case where mstyle, mphantom, mpadded or mrow should be treated as embellished op. It also fixes the case of maction and contains some reftests. As for Roger's initial issue, the MathML WG has chosen to make alignment according to the whole embellished op rather than the core (which is not too bad, since it will avoid us to complicate the code for very particular cases): http://monet.nag.co.uk/~dpc/draft-spec/chapter3.html#id.3.4.6.2 Hence the only remaining issue before closing this bug is the case of semantics, which won't be too difficult once bug 556767 is fixed.

(In reply to comment #17) > Created attachment 441538 [details] [diff] [review] > add rules for mstyle, mphantom, mpadded and mrow Karl, can you please have a look to this patch before it becomes too old?

I'll see what I can do, Frédéric. I'm sorry it's been so long, but I'll need a good chunk of time to understand how this automatic data / embellished operator stuff works.

Comment on attachment 441538 [details] [diff] [review] add rules for mstyle, mphantom, mpadded and mrow >+!= embellished-op-1.xhtml embellished-op-1-ref.xhtml >+!= embellished-op-2.xhtml embellished-op-2-ref.xhtml >+!= embellished-op-3.xhtml embellished-op-3-ref.xhtml The files in the "!=" tests each contain several subtests. For such "!=" tests to fail, all subtests would need to fail. "!=" tests need each subtest to be in a separate file. (I've started looking at the rest of the patch.)

Thank you Karl. FYI, I'm developing a test framework for the MathJax project, which uses the principle of Mozilla's reftest. Hence I've started to write MathML reftests and plan to merge them with our own tests at some point. In particular, I had already split embellished-op into separate files (even the == one, although it is not needed) and this change will be integrated in the next version of my patch.

Comment on attachment 441538 [details] [diff] [review] add rules for mstyle, mphantom, mpadded and mrow // By convention, the data that we keep in this struct can change depending // on any of our ancestors and/or descendants. If a data can be resolved // solely from the embellished hierarchy, and it remains immutable once // resolved, we put it in |nsEmbellishData|. The SPACE_LIKE property seems similar to embellished properties, so, on reading this, I wondered whether this bit should be stored on mEmbellishData rather than mPresentationData. But then even baseFrame is mPresentationData (perhaps it could be on mEmbellishData) and SPACE_LIKE is not exactly EmbellishData, so PresentationData seems fine. >+ PRBool >+ IsSpaceLike() { >+ return NS_MATHML_IS_SPACE_LIKE(mPresentationData.flags); >+ } I think I'd prefer to have this implementation on nsMathMLFrame, as having only the one function is simpler. >+ NS_IMETHOD >+ TransmitAutomaticDataForMrowLikeElement(); s/NS_IMETHOD/nsresult/ (NS_IMETHOD implies virtual and this doesn't need to be virtual.) TransmitAutomaticDataForMrowLikeElement should unset NS_MATHML_SPACE_LIKE and mPresentationData.baseFrame and mEmbellishData when the element becomes no longer space-like or no-longer embellished because of descendant changes. (InheritAutomaticData sets aPresentationData.flags = 0, but, looking at nsMathMLContainerFrame::RebuildAutomaticDataForChildren, it looks like InheritAutomaticData will not necessarily be called before TransmitAutomaticData.) Similarly for NS_MATHML_SPACE_LIKE in nsMathMLmactionFrame::TransmitAutomaticData. Would you mind adding a reftest to check that a vertically stretchy operator stretches when embellished with an mspace? IIUC I think that should render identically whether or not the mspace is inside an mrow enclosing the mspace and the stretchy operator. (Prior to this patch we wouldn't stretch the operator when in an mrow).

Thanks again Karl. I've update the patch and added reftests for vertical operators (the pages use an outer mrow because of bug 585347).

Comment on attachment 520883 [details] [diff] [review] add rules for mstyle, mphantom, mpadded and mrow (V2) Looks good, thanks! embellished-op-3-4(-ref).html are identical to embellished-op-3-5(-ref).html except for the comments. Just need to change mphantom to mpadded in 3-4. >+ // The element is not space-like >+ mPresentationData.flags &= ~NS_MATHML_SPACE_LIKE; Touch up the indentation on the second line here.

Comment on attachment 521124 [details] [diff] [review] Final Patch [pushed] http://hg.mozilla.org/mozilla-central/rev/109cfae74006

After reviewing this, it looks like it's just a rendering change rather than an API change, so I'm removing the doc-needed tag; please re-apply if there's an API or developer-impacting change I'm not seeing.