[Webkit-unassigned] [Bug 110977] New: Font metrics incorrect while loading web fonts and using unicode ranges

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Feb 27 06:22:03 PST 2013


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

           Summary: Font metrics incorrect while loading web fonts and
                    using unicode ranges
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Macintosh
        OS/Version: Unspecified
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Text
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: stein at adobe.com


As far as I can tell there are either two separate issues or one that affects two cases.

1) The first case is when a font stack is used where the primary font only contains a limited Unicode subset, and the secondary font contains a larger Unicode range. For example: "'Apple Color Emoji', sans-serif;". In this case, Apple Color Emoji only spans the the 0xE63E - 0xE757 range, whereas "sans-serif" spans (at least) the basic ASCII range.

So if we measure a span with "abcdefg" and that font stack, we should expect to see a width identical to a font stack without "Apple Color Emoji" in it. However, WebKit returns the width as if Apple Color Emoji was used. See the following example:

http://www.bramstein.com/typekit/webkit-font-subset-metrics.html

The console should log the width of a span without Apple Color Emoji in it (green text) and with Apple Color Emoji (red text.) Both the width and height are different from what other browsers report (identical width, but different height.) If we add a local @font-face with a unicode-range that only covers emoji WebKit does the right thing and reports identical results to other browsers. This is demonstrated in the following example:

http://www.bramstein.com/typekit/webkit-font-subset-metrics-with-range.html

2) The second case happens when a web font is loading or has failed to load. All other browsers return identical metrics before loading, during loading, and if a web font failed to load. WebKit however reports a difference in height during loading and when a web font has failed to load. This is demonstrated in the following example:

http://www.bramstein.com/typekit/webkit-webfont-subset-metrics.html

I tested various WebKit builds and it seems only iOS and OSX are affected. Instances of WebKit on other platforms are unaffected, which leads me to believe the incorrect code is somewhere in the platform specific graphics submodule on OSX/iOS.

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



More information about the webkit-unassigned mailing list