Closed Bug 851835 Opened 11 years ago Closed 11 years ago

Acid3 MathML: mac gets more errors than linux/windows

Categories

(Core :: MathML, defect)

Product:
Core
Component:
MathML
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: xfsunoles, Assigned: fredw)

References

(
URL
)

Details

Failed 50 tests.
    Test 08 failed: semantics size should be the one of the annotated child
    Test 09 failed: maction should have first child visible (tooltip)
    Test 10 failed: element should have the same size as child (mrow)
    Test 16 failed: bad size of lquote/rquote
    Test 18 failed: bad superscriptshift (msup)
    Test 19 failed: bad alignment (munder_center)
    Test 22 failed: bad column alignment
    Test 23 failed: bad column width
    Test 25 failed: bad rowspacing
    Test 26 failed: bad label position
    Test 27 failed: bad label spacing
    Test 28 failed: bad framespacing on the right and left
    Test 29 failed: equalcolumns not satisfied
    Test 31 failed: bad mathsize
    Test 32 failed: bad mathvariant (script)
    Test 43 failed: bad lspace/rspace
    Test 48 failed: bad lspace/rspace for minus sign (infix form)
    Test 49 failed: prefix form should be used
    Test 53 failed: bad size for mo0 (mtd)
    Test 54 failed: parenthesis should stretch symmetrically (mtd)
    Test 55 failed: bad size for stretchy operator (mtd)
    Test 57 failed: bad size for mo0 (mtd)
    Test 64 failed: bad spacing around operator 1
    Test 69 failed: bad position of inner mpadded element
    Test 73 failed: should break before the plus (auto)
    Test 74 failed: should break after the comma (auto)
    Test 75 failed: should break before the plus (newline)
    Test 76 failed: should break before the plus not after the comma (nobreak)
    Test 77 failed: should break before the plus not after the comma (badbreak & goodbreak)
    Test 78 failed: bad lineleading
    Test 79 failed: bad indentalign
    Test 80 failed: bad indentshift
    Test 81 failed: bad alignment (malignmark)
    Test 82 failed: bad alignment (groupalign)
    Test 83 failed: bad alignment (groupalign=center, malignmark)
    Test 84 failed: bad alignment (groupalign=decimalpoint, malignmark)
    Test 85 failed: bad alignment (several rows)
    Test 86 failed: bad alignment (several alignment groups in cells, mtd@groupalign)
    Test 87 failed: bad alignment (mtr@groupalign)
    Test 88 failed: bad alignment (mtable@groupalign)
    Test 89 failed: bad vertical position in mstack
    Test 90 failed: 123 should be above 456, with enough space to draw the line
    Test 91 failed: bad horizontal position (msgroup, shift)
    Test 92 failed: bad mslinethickness
    Test 93 failed: bad alignment (stackalign=left)
    Test 94 failed: bad font size in mscarries
    Test 95 failed: bad positions in mlongdiv
    Test 96 failed: bad positions in mlongdiv (longdivstyle=stackedrightright)
    Test 98 failed: mtext elements should have the width of their SVG/HTML content
    Test 99 failed: bad font size (@id99)
    Total elapsed time: 2.06s
The acid 3 tests uses a special Web font to determine accurate metrics of glyphs. I'm not sure if at the moment the Web font is always downloaded before the tests start, and if not that can make the tests fail. However, I expect the font to be downloaded when you arrive at test 99 and that one is very simple (it does not really involve MathML but rather CSS).

Could you clone the git repository:

https://github.com/fred-wang/AcidTestsMathML

and modify the javascript function for test 99 in AcidTestsMathML/acid3/index.html to get the values of e.g math.firstElementChild.getBoundingClientRect().width?
URL: http://www.wg9s.com/mathml/acid3/ → http://fred-wang.github.com/AcidTests...
Summary: mac gets more errors then linux/windows → mac gets more errors than linux/windows
I wonder if perhaps your system does not recognize the Mime Type application/font-woff.
I(In reply to Frédéric Wang (:fredw) from comment #1)
> The acid 3 tests uses a special Web font to determine accurate metrics of
> glyphs. I'm not sure if at the moment the Web font is always downloaded
> before the tests start

OK, I've modified the Acid3 page to verify whether the Web fonts have been downloaded before test 1. That might help you if your problem was a networking issue.
I have included the above fixes in the version on my server at http://www.wg9s.com/mathml/acid3/

I can duplicate this issue under Linux by specifying a zoom factor.  Have you tried resetting your zoom factor to default?
(In reply to Frédéric Wang (:fredw) from comment #1)
> The acid 3 tests uses a special Web font to determine accurate metrics of
> glyphs. I'm not sure if at the moment the Web font is always downloaded
> before the tests start, and if not that can make the tests fail. However, I
> expect the font to be downloaded when you arrive at test 99 and that one is
> very simple (it does not really involve MathML but rather CSS).
> 
> Could you clone the git repository:
> 
> https://github.com/fred-wang/AcidTestsMathML
> 
> and modify the javascript function for test 99 in
> AcidTestsMathML/acid3/index.html to get the values of e.g
> math.firstElementChild.getBoundingClientRect().width?

I get 50.05000305175781
> I get 50.05000305175781

OK, that's near the correct 50 result although still large compared to the epsilon error value I use. Just to be sure, if you remove the "visibility: hidden;" line here

https://github.com/fred-wang/AcidTestsMathML/blob/master/acid3/index.html#L96

you should see the MathML elements. Are they displayed with the Acid3MathML fonts (black boxes and shapes) or with normal fonts (letters etc)?

I've modified a bit the tests so that the default font size should be the same for everybody and I've also relaxed a bit some conditions to allow a small error.
(In reply to Frédéric Wang (:fredw) from comment #6)
> > I get 50.05000305175781
> 
> OK, that's near the correct 50 result although still large compared to the
> epsilon error value I use. Just to be sure, if you remove the "visibility:
> hidden;" line here
> 
> https://github.com/fred-wang/AcidTestsMathML/blob/master/acid3/index.html#L96
> 
> you should see the MathML elements. Are they displayed with the Acid3MathML
> fonts (black boxes and shapes) or with normal fonts (letters etc)?
> 
> I've modified a bit the tests so that the default font size should be the
> same for everybody and I've also relaxed a bit some conditions to allow a
> small error.

I have updated the test at http://www.wg9s.com/acid3/ to the latest.

I have also added a version with the line referenced above removed for testing fonts at http://www.wg9s.com/acid3/test.html
I uploaded one picture from http://www.wg9s.com/mathml/acid3/test.html is http://i.imgur.com/B3NWXky.png . I hope that picture can help you.
I also have issues where this gets unexpected errors on an Android Nexus 7 tablet that it does not get on a Samsung 7 inch table that has a slightly larger screen and that both devices get a far lower score when rotated to portrait mode. I think this test is way to sensitive to the width of the screen.
Or it has to do with the auto resizing on android to the screen width.
The measure can still be improved. I think using % values everywhere and measuring the default font size could help a bit. That way one could increase the font size in order to increase the precision and the test will work when the zoom is not reset or the screen is auto-resized. The "epsilon" error tolerance is currently absolute, perhaps it should be relative too (with respect to the normal or current font size). I must improve the tolerance for stretchy operators anyway (for the moment I think I use an arbitrary "10px" tolerance).

Jonathan: thanks for the picture. So it seems that the Web fonts are indeed loaded correctly and that seems a problem with the measure. Can you give the new result summary for the latest version? What about if you replace "epsilon = .0001" by "epsilon = .1"?
(In reply to Frédéric Wang (:fredw) from comment #12)
> The measure can still be improved. I think using % values everywhere and
> measuring the default font size could help a bit. That way one could
> increase the font size in order to increase the precision and the test will
> work when the zoom is not reset or the screen is auto-resized. The "epsilon"
> error tolerance is currently absolute, perhaps it should be relative too
> (with respect to the normal or current font size). I must improve the
> tolerance for stretchy operators anyway (for the moment I think I use an
> arbitrary "10px" tolerance).

Something like that is probably the only way to get the test to pass on mobile where the behavior is to auto zoom depending on the screen width.
(In reply to Frédéric Wang (:fredw) from comment #12)
 
> Jonathan: thanks for the picture. So it seems that the Web fonts are indeed
> loaded correctly and that seems a problem with the measure. Can you give the
> new result summary for the latest version? What about if you replace
> "epsilon = .0001" by "epsilon = .1"?

I have changed epsilon on the tests on my site form .0001 to .1

This has not helped at all with the Android issue.  Waiting for Jonathan to test on his MAC.
I changed epsilon to .1, I get 54 out of 100
A bit better but not quite 60.
I've started to do the changes suggested in comment 12. I'm not done yet, but I'm curious to see if you get better results. Currently, I'm getting a score between 58 and 62 tests according to the zoom level.
Assignee: nobody → fred.wang
Status: NEW → ASSIGNED
Summary: mac gets more errors than linux/windows → Acid3 MathML: mac gets more errors than linux/windows
I've continue the changes this morning (still not finished yet!). Now, I get the same score at all zoom levels. I realized that test 51 was too lax and incorrectly passed on Gecko. I fixed that and so our new expected score is 61/100.
Jonathan: can you please verify your score with the latest version:
http://fred-wang.github.io/AcidTestsMathML/acid3/
Flags: needinfo?(xfsunoles)
(In reply to Frédéric Wang (:fredw) from comment #19)
> Jonathan: can you please verify your score with the latest version:
> http://fred-wang.github.io/AcidTestsMathML/acid3/

To help Janathan, I know have the new version at updated at http://www.wg9s.com/mathml/acid3/

This gets 62/100 on both of my tablets in either portrait or landscape.

Bad new is I lost one point under Linux (from 63/100 to 62/100)
(In reply to Bill Gianopoulos [:WG9s] from comment #20)
>
> This gets 62/100 on both of my tablets in either portrait or landscape.
> 
> Bad new is I lost one point under Linux (from 63/100 to 62/100)

Yes, one test was incorrect (cf comment 18). So the result should be 61/100 (62/100 with the fix for bug 827713).
(In reply to Frédéric Wang (:fredw) from comment #21)
> (In reply to Bill Gianopoulos [:WG9s] from comment #20)
> >
> > This gets 62/100 on both of my tablets in either portrait or landscape.
> > 
> > Bad new is I lost one point under Linux (from 63/100 to 62/100)
> 
> Yes, one test was incorrect (cf comment 18). So the result should be 61/100
> (62/100 with the fix for bug 827713).

OIC that now.  I also now get 62/100 under Windows too!
I get 61/100 now.
Flags: needinfo?(xfsunoles)
Great.  So no real Mozilla code issue just an issue in the test it would seem.
I'm done with the test rewriting, so now all the tests use only relative sizes and allow a small error. I've found yet another test that was too lax and incorrectly passed on Gecko (one of the test checking horizontal stretching in mtd cells). So the expected score should be 60/100 (or 61/100 with the fix for bug 827713). Please tell me if you get the same and then I think we can resolve this bug as FIXED.
Matches what I get.  I can't test on Android because today's android builds are way to crashy.
(In reply to Frédéric Wang (:fredw) from comment #25)
> I'm done with the test rewriting, so now all the tests use only relative
> sizes and allow a small error. I've found yet another test that was too lax
> and incorrectly passed on Gecko (one of the test checking horizontal
> stretching in mtd cells). So the expected score should be 60/100 (or 61/100
> with the fix for bug 827713). Please tell me if you get the same and then I
> think we can resolve this bug as FIXED.

It matched with the current nightly for 60/100
Thanks. I close this bug.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.