Closed Bug 701315 Opened 13 years ago Closed 13 years ago

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

Categories

(Core :: MathML, defect)

7 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: stacey, Unassigned)

Details

Attachments

(3 files)

Attached image 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.
Attached file 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.
Attachment #573746 - Attachment mime type: application/octet-stream → application/xhtml+xml
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
> 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.
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
I close this bug, because this is the correct behavior per the MathML REC
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: