Created attachment 84665 [details] WebKit rendering of Acid3 Our Acid3 rendering no longer matches the reference image pixel-for-pixel after <http://trac.webkit.org/changeset/72141>. It appears that the "100/100" text is a pixel higher in our rendering than it is in the reference image. See the attached screenshots.
Created attachment 84666 [details] Reference rendering
<rdar://problem/9084992>
The content of attachment 84665 [details] has been deleted by William Siegrist <wsiegrist@apple.com> who provided the following reason: Deleted per request from Andy Estes The token used to delete this attachment was generated at 2011-03-03 18:01:27 PST.
The content of attachment 84666 [details] has been deleted by William Siegrist <wsiegrist@apple.com> who provided the following reason: Deleted per request from Andy Estes The token used to delete this attachment was generated at 2011-03-03 18:02:12 PST.
Created attachment 84670 [details] WebKit rendering of Acid3
Created attachment 84671 [details] Reference rendering
Created attachment 89085 [details] Reduction
I took a look at it for an hour or so. It seems like this is specific to the combination of having 0 font-size and 0 line-spacing, and due to this I think we compute a bogus descent when looking at the root linebox (1px ascent, -1px descent). It doesn't seem right that a 0px font with 0 leading should have an ascent.
Created attachment 89552 [details] Patch
Comment on attachment 89552 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=89552&action=review > Source/WebCore/css/CSSStyleSelector.cpp:6808 > + if (fabsf(specifiedSize - 0.0f) < std::numeric_limits<float>::epsilon()) Looks good, but why is it necessary to subtract 0?
(In reply to comment #10) > (From update of attachment 89552 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=89552&action=review > > > Source/WebCore/css/CSSStyleSelector.cpp:6808 > > + if (fabsf(specifiedSize - 0.0f) < std::numeric_limits<float>::epsilon()) > > Looks good, but why is it necessary to subtract 0? Ah, it isn't! Good call. I can take that out before landing.
Committed r83889: <http://trac.webkit.org/changeset/83889>