Bug 93073 - REGRESSION (r124512): Failures in MathML Presentation tests on GTK and EFL
Summary: REGRESSION (r124512): Failures in MathML Presentation tests on GTK and EFL
Alias: None
Product: WebKit
Classification: Unclassified
Component: MathML (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
Depends on:
Reported: 2012-08-03 00:18 PDT by Zan Dobersek
Modified: 2012-08-28 09:29 PDT (History)
14 users (show)

See Also:

Results on EFL port (709.00 KB, application/x-gzip)
2012-08-26 22:59 PDT, Chris Dumez
no flags Details
Patch (deleted)
2012-08-28 02:25 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Zan Dobersek 2012-08-03 00:18:03 PDT
After r124512[1] multiple mathml tests have begun to fail on both Mac and GTK. I counted 10 failures on Mac and 20 on GTK. For the latter port, I can confirm that out of those 20 tests 15 also have pixel mismatches which show severe regression.


Failures on builders:

[1] - http://trac.webkit.org/changeset/124512
Comment 1 Sudarsana Nagineni (babu) 2012-08-03 04:56:57 PDT
16 tests are failing on EFL bot too.
Comment 2 Dave Barton 2012-08-03 10:32:38 PDT
I am looking into this. I warned the GTK(?) folks that this was coming (I'm looking for the e-mail or bug note), and would be happy to warn EFL folks in the future also. I don't know why mac port tests would fail though. Thanks for all the info.
Comment 3 Dave Barton 2012-08-03 10:56:46 PDT
Sorry, it was Christophe Dumez of EFL that I warned in bug 89282. Please see that bug report, and I'd be grateful for any advice from experts now. Are the current mac failures probably due to the STIXGeneral font not being installed on some test bots? Can it be easily installed? Is this urgent? Sorry for my ignorance, I am just an outside volunteer. Thanks!
Comment 4 Dave Barton 2012-08-03 16:29:09 PDT
I've looked at the 10 failing Mac tests and they are all due to small differences (improvements) in STIX font metrics/handling between Snow Leopard and Lion. I've submitted bug 93163 with a patch to deal with this, splitting out *-expected.txt files between the two OS versions. Zan, the pixel regressions you're seeing should actually be progressions. If any look really bad please let me know. Someday I'd like to convert most of these old pixel tests to reference tests, but that will require some other MathML changes first. In the meantime, thanks for everyone's patience and help with MathML on GTK and EFL.
Comment 5 Dave Barton 2012-08-25 11:35:40 PDT
The Mac bots now pass all the MathML tests, after the patch for bug 94393 upgraded the Lion bots to OS X 10.7.4.

I don't know if you want to rebaseline the mathml tests on gtk and efl, or keep skipping them while MathML layout is still being improved.
Comment 6 Chris Dumez 2012-08-26 22:59:10 PDT
Created attachment 160642 [details]
Results on EFL port

On EFL port, the new results are *much* worse than the previous ones. I cannot do a simple rebaseline here. All the formulas are broken.

Attaching the results on EFL port.
Comment 7 Dave Barton 2012-08-27 10:47:55 PDT
Ouch. I think that -webkit-linebox-contain maybe doesn't work on the EFL port? Maybe the functions it calls to get glyph metrics don't work on that port? Or maybe the STIX fonts have problems on EFL?

Note that the old results on EFL may have been much worse than you see in the *-expected.png results here. People using MathML in general (e.g. in Firefox) are expected to download the STIX fonts so they can see various mathematical symbols. Apparently this was Alex Milowski's intention for WebKit MathML as well. Anyway, the STIX fonts didn't used to be enabled in the layout tests. So the old test results were showing better formatting than people were actually seeing, because the STIX fonts have large ascents and descents that were screwing up the old formatting in real use, even in the Apple/Mac port.

Thanks for uploading your attached test results. I will look into this further.
Comment 8 Dave Barton 2012-08-27 13:21:32 PDT
In the metrics files you uploaded, indeed -webkit-line-box-contain isn't working right. I believe it's worth looking at the 5 files LayoutTests/platform/*/fast/block/lineboxcontain/block-glyphs-replaced-expected.png. Of these 5, the 2 that show significant red are on efl and gtk. Also there are 3 lineboxcontain tests listed in efl/Skipped.

Is -webkit-line-box-contain supposed to work on efl and gtk? To work well, MathML needs either this CSS property or some equivalent. Will this be implemented on efl and gtk?
Comment 9 Eric Seidel (no email) 2012-08-27 13:32:04 PDT
I would expect that non-optional (#define guarded) CSS features work the same among all ports.

More likely font differences are to blame here?
Comment 10 Dave Barton 2012-08-27 13:42:33 PDT
But the lineboxcontain tests use the Ahem font. Also the posted efl mathml metrics give inline-block heights of often just 1 pixel, even though the element contains text. I think the problem is probably with the linux versions of the routines to measure individual glyphs sizes.
Comment 11 Chris Dumez 2012-08-27 22:47:00 PDT
I think the likely cause is that SimpleFontData::platformBoundsForGlyph() is not implemented for freetype backend (used by both EFL and GTK). I'm currently looking into it.
Comment 12 Chris Dumez 2012-08-28 02:25:15 PDT
Created attachment 160935 [details]

Fix and rebaseline for both EFL and GTK ports. The output looks good for MathML presentation tests now.
The output for the few fast/block/lineboxcontain tests that Dave Barton mentioned is also improved.
Comment 13 WebKit Review Bot 2012-08-28 03:37:42 PDT
Comment on attachment 160935 [details]

Clearing flags on attachment: 160935

Committed r126862: <http://trac.webkit.org/changeset/126862>
Comment 14 WebKit Review Bot 2012-08-28 03:37:47 PDT
All reviewed patches have been landed.  Closing bug.
Comment 15 Dave Barton 2012-08-28 09:29:46 PDT
This is wonderful, thanks!

In the past, MathML implementations like in Firefox and MathJax and MathPlayer I believe, as well as TeX before MathML, have had big tables of font data for the very few fonts they allowed in mathematical expressions. Getting metrics dynamically from the OS / graphics layer for arbitrary fonts, without huge static tables, is a huge win!