Created attachment 69752 [details]
These tests fail:
These tests rely on 'ex' units.
We're getting an xHeight of 20 for the Ahem font at 20px, but it seems that the xHeight should be 80% of this <http://hixie.ch/resources/fonts/>
CTFontGetBoundingRectsForGlyphs() returns a rect of 0,-4, 20x20, which
converts to 0,-16, 20x20
which seems wrong.
Right, on Mac OS X, WebKit prefers the height of the lowercase x glyph over the x-height encoded in the font.
Ah, the culprit is:
// Use the maximum of either width or height because "x" is nearly square
// and web pages that foolishly use this metric for width will be laid out
// poorly if we return an accurate height. Classic case is Times 13 point,
// which has an "x" that is 7x6 pixels.
m_xHeight = static_cast<float>(max(CGRectGetMaxX(xBox), -CGRectGetMinY(xBox)));
Maybe we should make an exception for the Ahem font?
The tests covered by bug 47158 also rely on ex units.
Fixed by http://trac.webkit.org/changeset/80662 ?
*** Bug 47158 has been marked as a duplicate of this bug. ***
No, not fixed by r80662. Actual patch coming shortly.
Created attachment 85379 [details]
Comment on attachment 85379 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=85379&action=review
> + https://bugs.webkit.org/show_bug.cgi?id=47157, CSS2.1 test failures because the ex unit is broken
We normally put the bug URL on its own line.
> - 1
> -Requesting the title of an AccessibilityImageMapLink can cause a crash when the map's area element has been removed.
> -On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
> -PASS successfullyParsed is true
> -TEST COMPLETE
Why did this result go away?
Fixed in r80755.