Embellished operators

RESOLVED FIXED in mozilla5

Core
MathML
RESOLVED FIXED
18 years ago
6 years ago

Tracking

(Blocks: 1 bug, {helpwanted})

Trunk
mozilla5
x86
Other
helpwanted
Points:
---
Dependency tree / graph

Attachments

(6 attachments, 4 obsolete attachments)

 4.84 KB, image/gif Details 1.02 KB, application/xhtml+xml Details 814 bytes, application/xhtml+xml Details 13.17 KB, image/png Details 1.18 KB, application/xhtml+xml Details 44.50 KB, patch Details | Diff | Splinter Review
(Reporter)

Description

18 years ago
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>

[/itex]
(Reporter)

Comment 1

18 years ago
Created attachment 3404 [details]
Screenshot for a tentative rendering of the MathML fragment
(Reporter)

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 2

17 years ago
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
(Reporter)

Comment 3

17 years ago
Created attachment 25759 [details]
testcase
(Reporter)

Comment 4

17 years ago
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.

Comment 5

17 years ago
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.
(Reporter)

Comment 6

16 years ago
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 [itex]. The plain usage of [itex] has some
limitations w.r.t. stretchy elements due to the fact that [itex] 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.
(Reporter)

Comment 7

16 years ago
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.

Comment 8

16 years ago
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
[itex], though I do agree with comment #7 that some of my markup was amateurish.
(Reporter)

Comment 9

16 years ago
>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.


Updated

8 years ago
QA Contact: ian → mathml
(Assignee)

Updated

8 years ago
Assignee: rbs → nobody
(Assignee)

Comment 10

8 years ago
Created attachment 438125 [details]
testcase

Add a doctype to the original testcase
Attachment #25759 - Attachment is obsolete: true
(Assignee)

Comment 11

8 years ago
Created attachment 438126 [details]
testcase 2
(Assignee)

Comment 12

8 years ago
Created attachment 438127 [details]
Screenshot testcase 2
(Assignee)

Comment 13

8 years ago
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.
(Assignee)

Comment 14

7 years ago
Created attachment 439765 [details] [diff] [review]
Experimental patch

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

Comment 15

7 years ago
Created attachment 439766 [details]
testcase 3
(Assignee)

Comment 16

7 years ago
BTW, it seems that the operator is does not always stretch to the exact size.
Keywords: helpwanted
(Assignee)

Comment 17

7 years ago
Created attachment 441538 [details] [diff] [review]
add rules for mstyle, mphantom, mpadded and mrow
Assignee: nobody → fred.wang
Attachment #439765 - Attachment is obsolete: true
Attachment #441538 - Flags: review?(karlt)
(Assignee)

Comment 18

7 years ago
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.
Depends on: 556767
(Assignee)

Updated

7 years ago
Priority: P3 → --
(Assignee)

7 years ago
Blocks: 562460
(Assignee)

Comment 19

7 years ago
(In reply to comment #17)
> Created attachment 441538 [details] [diff] [review]

Karl, can you please have a look to this patch before it becomes too old?

Comment 20

7 years ago
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 21

7 years ago
Comment on attachment 441538 [details] [diff] [review]

>+!= 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.)
(Assignee)

Comment 22

7 years ago
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 23

7 years ago
Comment on attachment 441538 [details] [diff] [review]

// 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).
Attachment #441538 - Flags: review?(karlt)
Attachment #441538 - Flags: review-
Attachment #441538 - Flags: feedback+
(Assignee)

Comment 24

7 years ago
Created attachment 520883 [details] [diff] [review]

Thanks again Karl.
I've update the patch and added reftests for vertical operators (the pages use an outer mrow because of bug 585347).
Attachment #441538 - Attachment is obsolete: true
Attachment #520883 - Flags: review?(karlt)

Comment 25

7 years ago
Comment on attachment 520883 [details] [diff] [review]

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.
Attachment #520883 - Flags: review?(karlt) → review+
(Assignee)

Comment 26

7 years ago
Created attachment 521124 [details] [diff] [review]
Final Patch [pushed]
Attachment #520883 - Attachment is obsolete: true
(Assignee)

Updated

7 years ago
Depends on: 610267

Comment 27

7 years ago
Comment on attachment 521124 [details] [diff] [review]
Final Patch [pushed]

http://hg.mozilla.org/mozilla-central/rev/109cfae74006
Attachment #521124 - Attachment description: Final Patch → Final Patch [pushed]

Updated

7 years ago
No longer depends on: 610267
(Assignee)

Updated

7 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.2

Updated

6 years ago
Keywords: dev-doc-needed

Comment 28

6 years ago
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.
Keywords: dev-doc-needed

Updated

6 years ago
Depends on: 657279
You need to log in before you can comment on or make changes to this bug.