Bug 123068 - character width appears to be calculated before unicode-range is applied
Summary: character width appears to be calculated before unicode-range is applied
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Minor
Assignee: Nobody
URL: http://codepen.io/patrickkettner/full...
Keywords: BlinkMergeCandidate
Depends on:
Blocks:
 
Reported: 2013-10-19 14:20 PDT by Patrick Kettner
Modified: 2022-07-15 14:27 PDT (History)
6 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Kettner 2013-10-19 14:20:54 PDT 
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>
Comment 1 Patrick Kettner 2013-10-19 14:57:10 PDT 
Upon further investigation, this appears to ONLY happen when using local('courier') or local('courier new')
Comment 2 Patrick Kettner 2013-10-25 09:03:11 PDT 
There is an open pull fixing this issue in the blink codebase.

https://code.google.com/p/chromium/issues/detail?id=309407#c5
Comment 3 Brent Fulgham 2022-07-15 14:27:06 PDT 
Safari, Chrome, and Firefox all agree on rendering for this test case. I don't believe there is any remaining compatibility issue.