Unicode FB1E / Entity ‬ does not respect bounding box width of webfont
Reported by
templari...@gmail.com,
Sep 19
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.92 Safari/537.36 Example URL: https://en.wikipedia.org/wiki/Alphabetic_Presentation_Forms Steps to reproduce the problem: 1. Navigate to the page specified 2. Notice the character renders with 0 width 3. This is correct (probably?). 4. If a custom webfont is used with the same character code the width is still rendered with 0. Even if the bounding box is set (tried with TTF/Woff/Woff2). What is the expected behavior? The webfont loaded using unicode FB1E or Entity ‬ should render with the webfont's bounding box not 0. Edge renders with the correct width of the bounding box. What went wrong? It appears that Chrome has somehow "hardcoded" the width of this specific unicode character to 0. In the attached zip search for "origin" or "FB1E" to see the broken bounding box. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 69.0.3497.92 Channel: stable OS Version: 10.0 Flash Version: This is the only unicode I can see it happening with in the \F000 - \FBB8 (3000 characters) range I'm testing with right now.
,
Sep 19
,
Sep 25
FB1E is a nonspacing mark. Overloading defined codepoints like this for icon fonts is problematic, especially for combining marks. Consider using one of the Private Use Areas instead, or at the very least, limit the codepoints used to individual character ones.
,
Sep 25
The "WontFix" status is fine since it's very niche issue, but it is a bug in Chrome's font rendering. Windows itself renders this correctly and other browsers appear to respect the font having a different bounding box. It makes me wonder how this was wired up that there is a codepoint lookup first before rendering the desired font (maybe an optimization layer that shouldn't apply for webfonts?) Thanks for looking into this. |
|||
►
Sign in to add a comment |
|||
Comment 1 by dtapu...@chromium.org
, Sep 19