Created attachment 573446 [details] Screenshot4.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.
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.
(Reporter)  
Updated•6 years ago

Comment 2•6 years ago


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


(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 > correctlyplaced (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?
Comment 6•6 years ago


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


Created attachment 580738 [details]
correct markup, with movablelimits="false"
Comment 8•6 years ago


I close this bug, because this is the correct behavior per the MathML REC
Description
•