Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Placement of accents via mover on mo elements is offset in textstyle

RESOLVED INVALID

Status

()

Core
MathML
RESOLVED INVALID
6 years ago
6 years ago

People

(Reporter: Andrew Stacey, Unassigned)

Tracking

7 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

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

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

Updated

6 years ago
Attachment #573746 - Attachment mime type: application/octet-stream → application/xhtml+xml
(Reporter)

Updated

6 years ago
Component: General → MathML
Product: Firefox → Core
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

6 years ago
> 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.
(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

6 years ago
Ah.

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

Was that expectation incorrect?
(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
Created attachment 580738 [details]
correct markup,  with movablelimits="false"
I close this bug, because this is the correct behavior per the MathML REC
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.