[Webkit-unassigned] [Bug 40555] line-height handling in rendering code on font fallbacks

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=40555





--- Comment #8 from Jiang Jiang <gzjjgod at gmail.com>  2010-06-21 23:22:28 PST ---
Created an attachment (id=59343)
 --> (https://bugs.webkit.org/attachment.cgi?id=59343)
Compare the results in Safari 5 (left) and Firefox 3.6.3 (right)

(In reply to comment #7)
> Created an attachment (id=59342)
 --> (https://bugs.webkit.org/attachment.cgi?id=59342) [details]
> Test case not involving font fallback
> 
> First of all, this behavior is not unique to font fallback. This test case shows how with all fonts being specified explicitly and no fallback occurring, the line height is 23px as well. Secondly, I believe that this behavior is correct, and Firefox renders this test case the same, with a 23px line height. The cases involving font fallback just mimic the same behavior, i.e. they always behave as if the runs using fallback fonts were inlines explicitly specifying the fallback families.

You are right about this behavior is not unique to font fallback, but are you sure Firefox renders this test case the same? In my setup, Firefox 3.6.3 renders it in constant 22px line height. (If you compare a longer test case as I provided, the container box is obviously higher than that in Safari/WebKit, see attached screenshot)

About what is the correct behavior, let's consider this: suppose we have a constant baseline which both Times New Roman and STSong will be put on, above this baseline, the max ascent is 13px, below it, max descent is 4px, so the line height specified (22px) is more than enough to fit in both fonts, why should we extend it to 23px?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.