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)
Tracking
()
RESOLVED
INVALID
People
(Reporter: stacey, Unassigned)
Details
Attachments
(3 files)
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.
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
Reporter | ||
Updated•13 years ago
|
Component: General → MathML
Product: Firefox → Core
Comment 2•13 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 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•13 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
> 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?
Comment 6•13 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•13 years ago
|
||
Comment 8•13 years ago
|
||
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.
Description
•