Bug 123068
| Summary: | character width appears to be calculated before unicode-range is applied | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Patrick Kettner <patrickkettner> |
| Component: | CSS | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED CONFIGURATION CHANGED | ||
| Severity: | Minor | CC: | bfulgham, dbates, enrica, mitz, mmaxfield, rniwa |
| Priority: | P2 | Keywords: | BlinkMergeCandidate |
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://codepen.io/patrickkettner/full/4eae4e3811c762f821259f55b2204e26 | ||
Patrick Kettner
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1674.0 Safari/537.36
I am loading a monospace font only for the period character (U+002E) using unicode-range. The second m's font-family is set to that font. The width of the character is what it should be if it was using the monospace font, even though the correct sans-serif font displays.
The width of the second m should be the width of the third m.
This bug does not exist in IE 9+.
Steps to reproduce the problem:
1. go to http://codepen.io/patrickkettner/full/4eae4e3811c762f821259f55b2204e26
2. compare the widths of the 'm's
just in case the above test case doesn't work, you can view it with this dataurl
data:text/html, <html><style>@font-face{font-family:bug;src:local("Courier New");unicode-range:U+002E}div{font-size:125px;display:inline-block}.control{font-family:"Courier New";background:#00f}.mono{font-family:bug,sans-serif}.sans{font-family:sans-serif;background:red}</style><div class="control">m</div> <div class="mono">m</div> <div class="mono sans">m</div>
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Patrick Kettner
Upon further investigation, this appears to ONLY happen when using local('courier') or local('courier new')
Patrick Kettner
There is an open pull fixing this issue in the blink codebase.
https://code.google.com/p/chromium/issues/detail?id=309407#c5
Brent Fulgham
Safari, Chrome, and Firefox all agree on rendering for this test case. I don't believe there is any remaining compatibility issue.