New issue
Advanced search Search tips

Issue 886501 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 25
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Unicode FB1E / ‬‬Entity ‬ does not respect bounding box width of webfont

Reported by templari...@gmail.com, Sep 19

Issue description

UserAgent: 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.
 
example.zip
1.3 MB Download
Components: -Blink Blink>Fonts
Labels: Needs-Triage-M69
Status: WontFix (was: Unconfirmed)
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.
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