RESOLVED CONFIGURATION CHANGED 123068
character width appears to be calculated before unicode-range is applied 
https://bugs.webkit.org/show_bug.cgi?id=123068
Summary character width appears to be calculated before unicode-range is applied
Patrick Kettner
Reported 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>
Attachments
Add attachment proposed patch, testcase, etc.
Patrick Kettner
Comment 1 2013-10-19 14:57:10 PDT
Upon further investigation, this appears to ONLY happen when using local('courier') or local('courier new')
Patrick Kettner
Comment 2 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
Brent Fulgham
Comment 3 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.
Note You need to log in before you can comment on or make changes to this bug.