Closed Bug 518330 Opened 15 years ago Closed 14 years ago

Large operators are not displayed larger when displaystyle="true"

Categories

(Core :: MathML, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: fredw, Unassigned)

References

Details

Attachments

(2 files, 3 obsolete files)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090923 Minefield/3.7a1pre Build Identifier: Large operators with implicit/explicit displaystyle="true" must be displayed larger (see testcase). The screenshot shows the expected result on the left (Amaya) and the rendering in Gecko on the right. Reproducible: Always
Attached file Testcase (obsolete) —
Attached image Screenshot (obsolete) —
Looks like displaystyle="true" is also being ignored re moveablelimits.
Depends on: scale-stretchy, 407101
(In reply to comment #3) > Looks like displaystyle="true" is also being ignored re moveablelimits. You're right. I'm almost sure that previous versions of Gecko interpret moveablelimits correctly. When I set the macro NS_MATHML_IS_DISPLAYSTYLE to true, then the limits are placed correctly but the sigma symbol is still small.
Attached file Testcase (obsolete) —
The previous testcase was not valid, (displaystyle was used as an attribute of mrow). With this new version, the explicit displaystyle="true" is now taken into account.
Attachment #402333 - Attachment is obsolete: true
Attached file Testcase
Attachment #402671 - Attachment is obsolete: true
Attached image Screenshot (Amaya)
OK, my testcase was not correct. So actually the rendering of movablelimits is good and the bug is really about the size of largeop.
Attachment #402334 - Attachment is obsolete: true
According to chapter 3, section "The Top-Level math Element": "When display="block", displaystyle is initialized to "true", whereas when display="inline", displaystyle is initialized to "false"; [...] When this attribute is missing, a rendering agent is free to initialize as appropriate to the context." So it is not a bug if Mozilla does not set displaystyle="true" in the second testcase (no explicit display attribute on the <math/> element) but it could be a desired feature. Currently, Mozilla set displaystyle="false", except when the user specifies that it should be true. In my opinion, the behavior of Amaya is better: when the <math/> is alone in a block element, displaystyle="true" but when the <math/> is among other elements (for instance text) displaystyle="false".
I've just checked the source code of Amaya. Here is how the displaystyle of the <math/> element is set : If the <math/> element has a display attribute, use its value. Otherwise, if the <math/> element is the root of the document or a child of an svg element, set displaystyle to true. Otherwise, if the <math/> element is the child of an html element, look to the context. If it is a child of a <body/>, a <div/> then set displaystyle to true. If it is the only child of a <p/> (or an internal object "pseudo paragraph" that seems to be used for editing features, so it doesn't matter here) then set displaystyle to true. In all other cases, set displaystyle to false. I wonder whether just adding some contextual checking in nsMathMLFrame to set displaystyle to true would be OK: http://mxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLFrame.cpp#229
If the display attribute of the math element didn't have the default "inline" specified, then perhaps the block/inline decision could have been made based on the context. But it would seem strange to me to have displaystyle initialized differently depending on whether display="inline" was explicitly specified or merely the default.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I still think a displaystyle="true" is only relevant when the <math/> element is surrounded by text inside the same paragraph. However, you're right that it's weird to have different behaviors for the implicit & explicit values (although the spec allows it), so let's not change it for the moment.
Depends on: 584332
Karl, do you have a testcase for this bug?
(In reply to comment #12) > Karl, do you have a testcase for this bug? Sorry, I meant for bug 584332.
This bug should be fixed now we have a complete support for STIX fonts and implement the workaround of the scale-stretchy bug.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: