Last Comment Bug 701315 - Placement of accents via mover on mo elements is offset in textstyle
: Placement of accents via mover on mo elements is offset in textstyle
Status: RESOLVED INVALID
:
Product: Core
Classification: Components
Component: MathML (show other bugs)
: 7 Branch
: x86_64 Linux
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Anthony Jones (:kentuckyfriedtakahe, :k17e)
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-10 01:26 PST by Andrew Stacey
Modified: 2011-12-11 06:44 PST (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Screenshot-4.png (19.82 KB, image/png)
2011-11-10 01:26 PST, Andrew Stacey
no flags Details
testcase (1.33 KB, application/xhtml+xml)
2011-11-10 21:56 PST, distler
no flags Details
correct markup, with movablelimits="false" (1.44 KB, application/xhtml+xml)
2011-12-11 06:43 PST, Frédéric Wang (:fredw)
no flags Details

Description Andrew Stacey 2011-11-10 01:26:48 PST
Created attachment 573446 [details]
Screenshot-4.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928221858

Steps to reproduce:

In MathML, using <mover> to place an accent on top of an <mo> element results in an offset accent when the maths is in "textstyle".  In "displaystyle" it renders correctly.

Sample code:

<math display='inline' xmlns='http://www.w3.org/1998/Math/MathML'><mover><mo>⊗</mo><mo>^</mo></mover></math>

<math display='inline' xmlns='http://www.w3.org/1998/Math/MathML'><mstyle displaystyle='true'><mover><mo>⊗</mo><mo>^</mo></mover></mstyle></math>

<math display='block' xmlns='http://www.w3.org/1998/Math/MathML'><mover><mo>⊗</mo><mo>^</mo></mover></math>

<math display='inline' xmlns='http://www.w3.org/1998/Math/MathML'><mstyle textstyle='true'><mover><mo>⊗</mo><mo>^</mo></mover></mstyle></math>

The middle two render correctly, the outer two do not.  See attached screenshot.


Actual results:

The accent is offset from the character.


Expected results:

The accent should have been placed directly over the character.
Comment 1 distler 2011-11-10 21:56:58 PST
Created attachment 573746 [details]
testcase

Testcase added.

This is a Gecko Core/MathML bug, not a Firefox bug. Doesn't seem that I have the privileges to reclassify it.
Comment 2 Frédéric Wang (:fredw) 2011-11-11 02:36:38 PST
Is this bug related to bug 567718?

> This is a Gecko Core/MathML bug, not a Firefox bug. Doesn't seem that I have
> the privileges to reclassify it.

You may want to ask Gerv to upgrade your Bugzilla privileges:
https://developer.mozilla.org/en/What_to_do_and_what_not_to_do_in_Bugzilla
Comment 3 distler 2011-11-11 07:57:32 PST
> Is this bug related to bug 567718?

Probably. I see two things going on.

1. The accent (U+005E) is displaced.
2. It is unstretched.

The base (U+2297), in this case, is not a combining character. Moreover, changing the base, from an mo to an mi, makes the accent appear correctly-placed (as does setting displaystyle=true).

The behaviour, that we're seeing here, is a little like what you expect fron msub/msup/msubsup applied to "large operators", like Sum. There, the placement of the subscript/superscript changes from display to inline mode.
Comment 4 Frédéric Wang (:fredw) 2011-11-11 08:36:59 PST
(In reply to distler from comment #3)
> > Is this bug related to bug 567718?
> 
> Probably. I see two things going on.
> 
> 1. The accent (U+005E) is displaced.
> 2. It is unstretched.
> 
> The base (U+2297), in this case, is not a combining character. Moreover,
> changing the base, from an mo to an mi, makes the accent appear
> correctly-placed (as does setting displaystyle=true).
> 
> The behaviour, that we're seeing here, is a little like what you expect fron
> msub/msup/msubsup applied to "large operators", like Sum. There, the
> placement of the subscript/superscript changes from display to inline mode.

OK, so that's probably not bug 567718, rather this happens just because U+2297 is in the operator dictionary with movablelimits=true. One should verified this carefully, but I think the behavior is correct (according to the MathML REC). One can get the correct rendering by forcing movablelimits=false via an explicit attribute.
Comment 5 distler 2011-11-11 09:03:25 PST
Ah.

I was expecting the movablelimits attribute to apply to msub/msup/msubsup, but not to munder/mover/munderover.

Was that expectation incorrect?
Comment 6 Frédéric Wang (:fredw) 2011-11-11 09:35:28 PST
(In reply to distler from comment #5)
> Ah.
> 
> I was expecting the movablelimits attribute to apply to msub/msup/msubsup,
> but not to munder/mover/munderover.
> 
> Was that expectation incorrect?

It's the contrary, the purpose of the movablelimits is to draw munderover like msubsup to save vertical space in inline formulas.

http://www.w3.org/TR/MathML/chapter3.html#presm.munderover
Comment 7 Frédéric Wang (:fredw) 2011-12-11 06:43:38 PST
Created attachment 580738 [details]
correct markup,  with movablelimits="false"
Comment 8 Frédéric Wang (:fredw) 2011-12-11 06:44:24 PST
I close this bug, because this is the correct behavior per the MathML REC

Note You need to log in before you can comment on or make changes to this bug.