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. Dashboard: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20webkit.org&tests=mathml Failures on builders: http://build.webkit.org/results/Apple%20Lion%20Release%20WK1%20(Tests)/r124564%20(1904)/results.html http://build.webkit.org/results/Apple%20Lion%20Debug%20WK1%20(Tests)/r124560%20(1541)/results.html http://build.webkit.org/results/GTK%20Linux%2064-bit%20Release/r124564%20(27129)/results.html [1] - http://trac.webkit.org/changeset/124512
16 tests are failing on EFL bot too. http://build.webkit.org/results/EFL%20Linux%2064-bit%20Debug/r124517%20%283783%29/results.html
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.
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!
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.
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.
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.
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.
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?
I would expect that non-optional (#define guarded) CSS features work the same among all ports. More likely font differences are to blame here?
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.
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.
Created attachment 160935 [details] Patch 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 on attachment 160935 [details] Patch Clearing flags on attachment: 160935 Committed r126862: <http://trac.webkit.org/changeset/126862>
All reviewed patches have been landed. Closing bug.
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!