Closed
Bug 557478
(mrow-1-arg)
Opened 14 years ago
Closed 10 years ago
mrow of one argument should be treated as this single argument occurring alone
Categories
(Core :: MathML, defect)
Core
MathML
Tracking
()
RESOLVED
FIXED
mozilla31
People
(Reporter: fredw, Assigned: jkitch)
References
()
Details
(Keywords: helpwanted)
Attachments
(3 files)
The REC says: "MathML renderers are required to treat an mrow element containing exactly one argument as equivalent in all ways to the single argument occurring alone, provided there are no attributes on the mrow element's start tag. If there are attributes on the mrow element's start tag, no requirement of equivalence is imposed." The attachment gives a testcase where stetching is different with some useless 1-argument <mrow/>'s. I don't know whether there are other cases that should be fixed. I guess one solution is to add a special case in nsMathMLmrowFrame::InheritAutomaticData (when the mrow has no attribute and a single child) where we use the same technique as for embellished operator.
Comment 1•14 years ago
|
||
http://www.w3.org/TR/MathML3/chapter3.html#id.3.2.5.7 The precise definition of an "embellished operator" is: * an mo element; . . . * or an mrow whose arguments consist (in any order) of one embellished operator and zero or more space-like elements.
Reporter | ||
Comment 2•14 years ago
|
||
Yes, the particular case I give in comment 0 is mentioned below: "Note that an mrow containing a single argument is an embellished operator if and only if its argument is an embellished operator. This is because an mrow with a single argument must be equivalent in all respects to that argument alone (as discussed in Section 3.3.1 Horizontally Group Sub-Expressions <mrow>). This means that an mo element that is the sole argument of an mrow will determine its default form attribute based on that mrow's position in a surrounding, perhaps inferred, mrow (if there is one), rather than based on its own position in the mrow in which it is the sole argument." BTW, it seems that we are not dealing with all these cases. We should probably work on this, as well as the case of mrow considered as embellished operator, in a separate bug (bug 21479 seems to be opened for that). I keep this bug opened in case we find other cases where mrow-with-1-argument and argument-alone behaves differently.
Reporter | ||
Comment 3•13 years ago
|
||
An embellished mfrac adds the spaces around it in nsMathMLmfracFrame.cpp. But if it is the single child of an mrow element, the spaces are added again in nsMathMLContainerFrame.cpp
Assignee | ||
Comment 4•10 years ago
|
||
There were two causes to this bug from the previous comment. 1. mfrac always adds lspace and rspace, even if it isn't the outermost embellished operator. This is particularly noticeable in the case of nested fractions. The attached patch only adds lspace % rspace if the mfrac is the outermost embellished operator. There has been a change in the behaviour of default spacing to ensure consistency between the cases where the mfrac is and is not the outermost embellished operator. Now the leading and trailing spaces are added to the default, rather than choosing the larger of the two values. 2. The frame type of an mrow is different to that of an mfrac for interframe spacing purposes. To solve this, an mrow with a single child returns the frame type of its child.
Reporter | ||
Updated•10 years ago
|
Attachment #8402647 -
Flags: review?(fred.wang) → review+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 5•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/78578b6e6821
Keywords: checkin-needed
Comment 6•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/78578b6e6821
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
You need to log in
before you can comment on or make changes to this bug.
Description
•