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

Status: RESOLVED WORKSFORME

(Core :: MathML, defect)

Description

[Frédéric Wang (:fredw)]

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

Comment 1

[Frédéric Wang (:fredw)]

Attachment: Testcase

Comment 2

[Frédéric Wang (:fredw)]

Attachment: Screenshot

Comment 3

[Karl Tomlinson (:karlt)]

Looks like displaystyle="true" is also being ignored re moveablelimits.

Comment 4

[Frédéric Wang (:fredw)]

(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.

Comment 5

[Frédéric Wang (:fredw)]

Attachment: Testcase

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.

Comment 6

[Frédéric Wang (:fredw)]

Attachment: Testcase

Comment 7

[Frédéric Wang (:fredw)]

Attachment: 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.

Comment 8

[Frédéric Wang (:fredw)]

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".

Comment 9

[Frédéric Wang (:fredw)]

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

Comment 10

[Karl Tomlinson (:karlt)]

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.

Comment 11

[Frédéric Wang (:fredw)]

	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.

Comment 12

[Frédéric Wang (:fredw)]

Karl, do you have a testcase for this bug?

Comment 13

[Frédéric Wang (:fredw)]

(In reply to comment #12)
> Karl, do you have a testcase for this bug?

Sorry, I meant for bug 584332.

Comment 14

[Frédéric Wang (:fredw)]

This bug should be fixed now we have a complete support for STIX fonts and implement the workaround of the scale-stretchy bug.