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

Status: RESOLVED DUPLICATE of bug 236963

(Core :: MathML, defect, P3)

Description

[SamyDagan]

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.

Comment 1

[SamyDagan]

Attachment: Examples of the bug including mathml expresssions.

The test case contains also texts of clarification for each MathML expression.

Comment 2

[SamyDagan]

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

Comment 3

[Karl Tomlinson (:karlt)]

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.

Comment 4

[SamyDagan]

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  

Comment 5

[SamyDagan]

Attachment: Modified example of the bug by a work-around.

The work-around was suggested by comment #3. See comment #4 for more clarifications.

Comment 6

[Karl Tomlinson (:karlt)]

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.

Comment 7

[Samuel Sidler (old account; do not CC)]

Karl, any update to this bug?

Comment 8

[Karl Tomlinson (:karlt)]

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.

Comment 9

[Frédéric Wang (:fredw)]

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)

Comment 10

[Frédéric Wang (:fredw)]

I mark this as a duplicate of bug 415413. It also contains the issue from bug 236963 for which there is already a workaround.