Closed Bug 428906 Opened 14 years ago Closed 10 years ago

MathML: Closing curly brackets are not at the right position, after mtable/mtd without explicit mrow

Categories

(Core :: MathML, defect, P3)

defect

Tracking

()

RESOLVED DUPLICATE of bug 236963

People

(Reporter: dagan, Unassigned)

Details

(Keywords: regression, testcase)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041306 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041306 Minefield/3.0pre

This bug occurs with Windows and with Mac. In some occasions of closing MathML expressions of at least two rows with curly brackets, it happens that the the brackets are not far enough to the right, causing overlap with the math expressions. It seems that this happens if the rows have different widths, and the wider row is not taken fully in account. 


Reproducible: Always

Steps to Reproduce:
1.Write a mathml expression including rows with different widths closed with curly bracket stretched over all the rows. 
2.The bracket overwrites the right part of the wider row.
3.
Actual Results:  
See the steps above.

Expected Results:  
The closing bracket should be on the right of the row and not to overwrite it.

I could not find similar behaviour with different kind of brackets, but this is not a proof that other kind of brackets do not show the same bug. 

A test case showing the bug is attached. 
This is a regression. Firefox 2 behaves correctly with this test case.
The test case contains also texts of clarification for each MathML expression.
Component: General → MathML
Product: Firefox → Core
QA Contact: general → mathml
Version: unspecified → Trunk
Status: UNCONFIRMED → NEW
Depends on: 415413
Ever confirmed: true
Hi I am not sure that this bug depends on bug 415413. It looks to me that the width of the closing curly brackets is not taken in account. For instance if one adds a space equivalent to about twice the horizontal width of a closing bracket, everything could look normal. 
Of course I am not an expert and what I am saying could be pure none-sense. In such case sorry for my impertinence. Thanks, Samy
There are two issues here.

1) The widths of italic identifiers are calculated incorrectly (bug 415413).
   (Adding "mi {font-style: normal;}" to the style improves the widths slightly
    - but shows the wrong glyphs - not recommended!)

2) The mtd elements are not implemented with a mrow but with a block frame
   (bug 236963).  Corrections are made to child element spacing in
   FixInterFrameSpacing only during Reflow but not at GetIntrinsicWidth.
   (Using an explicit mrow inside each mtd works around this problem, which
    is the more significant in these testcases.)

Problem 2 should be able to be resolved easily by adding FixInterFrameSpacing calls to the appropriate GetIntrinsicWidth methods.
Summary: MathML: Closing curly brackets are not at the right position, if stretched over rows with different widths. → MathML: Closing curly brackets are not at the right position, after mtable/mtd without explicit mrow
Karl, thanks for the clarifications of comment #3.

I've tried the work-around of comment #3 (Second point). It works fine and does not influence the mathml rendering by other browsers in different platforms. The improvement for Minefield is enormous, although the problem with the size of italic fonts (first point of comment #3) is sometimes noticeable. I am attaching the same testcase (comment #1) modified by the work-around. Cheers, Samy  
The work-around was suggested by comment #3. See comment #4 for more clarifications.
Assignee: nobody → mozbugz
Flags: wanted1.9.0.x?
This is the most noticeable MathML issue that I know of at the moment.

(In reply to comment #3)
> 2) The mtd elements are not implemented with a mrow but with a block frame
>    (bug 236963).  Corrections are made to child element spacing in
>    FixInterFrameSpacing only during Reflow but not at GetIntrinsicWidth.
>    (Using an explicit mrow inside each mtd works around this problem, which
>     is the more significant in these testcases.)
> 
> Problem 2 should be able to be resolved easily by adding FixInterFrameSpacing
> calls to the appropriate GetIntrinsicWidth methods.

Actually the best fix here would be make sure children of mtd are wrapped in an anonymous mrow.
Flags: wanted1.9.1?
Keywords: regression, testcase
Priority: -- → P2
Karl, any update to this bug?
The best solution is a bit more complex than my first idea, and would be best to do on trunk first, at least.  Don't know when I'll get to that.
Flags: wanted1.9.0.x?
Flags: wanted1.9.1? → wanted1.9.1+
Decreasing bug priorities, to follow David's definition:
http://dbaron.org/log/20090120-bug-priorities
(i.e. make these MathML bugs not blocking any release)
Priority: P2 → P3
Status: NEW → ASSIGNED
I mark this as a duplicate of bug 415413. It also contains the issue from bug 236963 for which there is already a workaround.
Assignee: karlt → nobody
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
No longer depends on: 415413
Resolution: --- → DUPLICATE
Duplicate of bug: stretch-mtd-math
You need to log in before you can comment on or make changes to this bug.