Unicode-range works unpredictably with local fonts
Reported by
pixelamb...@gmail.com,
Jun 15 2018
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.170 Safari/537.36 OPR/53.0.2907.68 Steps to reproduce the problem: 1. Write an @font-face rule using a local() font and a unicode range 2. The unicode range will be applied inconsistently See attached file index.html. I only use the font Chalkboard for capital A-Z through a @font-face rule. This would only affect the letter H in the text "Hello there". But the entire first word is written in Chalkboard. See attached file index2.html. I use two local fonts, Chalkboard for A-Z and Futura for a-z. In the text "Hello There" the H and the T would be written in Chalkboard, the small cap remainder of the text in Futura. But the entire text is written in Futura only. Also see: What is the expected behavior? The local font should be applied to text in the specified unicode range only. What went wrong? The font is being applied to characters outside its unicode range, but only for the first word. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 66.0.3359.170 Channel: n/a OS Version: OS X 10.13.3 Flash Version:
,
Jun 17 2018
,
Jun 18 2018
Able to reproduce this issue on reported version 66.0.3359.170 and latest stable 67.0.3396.87 using Mac 10.13.3, Ubuntu 14.04 and Windows 10. NOTE: In Mac firefox able to see difference, but in Linux and Windows seeing same behavior as in chrome. This issue is seen from M-60. Hence considering this issue as Non-Regression and marking as Untriaged. Thanks!
,
Jun 28 2018
,
Jun 28 2018
+drott@ who may have some insights
,
Jun 28 2018
,
Jun 28 2018
,
Aug 17
iOS does not use Blink
,
Oct 19
Thanks for this interesting reports. This will fail only for AAT fonts that pass through the hb-coretext shaping backend. Futura seems to be one of those fonts, as are ".SFNSText" (the mac ui font), "Helvetica", "Times". If you use "Arial" this issue does not occur, as Arial is not an AAT font, which is not shaped with hb-coretext. The hb-coretext backend does not call back into Blink to take unicode-range into account and proceeds to shape with priority. This is not reproducible on Windows and Linux, as Futura and Chalkboard are not available as local fonts there, and the whole run displays in Times. This will be fixed by moving to HarfBuzz' own shaping algorithm, also for AAT fonts, which is tracked in issue 894354 .
,
Oct 19
,
Nov 26
Fixed by rolling to HarfBuzz AAT support, see issue 894353, available in Canary from 72.0.3622.0. See https://chromium-review.googlesource.com/c/chromium/src/+/1275945 |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by pixelamb...@gmail.com
, Jun 15 2018