New issue
Advanced search Search tips

Issue 778698 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

  bug with font "Brandon Light"

Reported by mar...@daknight.se, Oct 26 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Steps to reproduce the problem:
Download included zip, includes html and otf+ttf

Otherwise you can:
1. Use Brandon Light font with @font-face
2. Use   for spaces

What is the expected behavior?
Space instead of ` symbol

What went wrong?
The font space is displayed as a symbol. This is related to this issue:
https://bugs.chromium.org/p/chromium/issues/detail?id=454108

It seems like the problem is back or never fixed for certain fonts, eg. Brandon Light. 

Attached image for clarification.
Attached html,  ttf/otf to show live example of the problem.

Did this work before? N/A 

Chrome version: 61.0.3163.100  Channel: n/a
OS Version: OS X 10.11.6
Flash Version:
 
brandon_grotesque.jpg
86.4 KB View Download
brandon_problem.zip
148 KB Download

Comment 1 by lgrey@chromium.org, Oct 26 2017

Components: -UI Blink>Fonts

Comment 2 by e...@chromium.org, Oct 30 2017

Cc: e...@chromium.org behdad@chromium.org
Labels: Needs-Feedback
Hej!

Thank you for the detailed report and the excellent test case demonstrating the problem.

This is slightly different from  issue 454108  where the font in question lacked a NO-BREAK SPACE glyph.

In this case, brandon-light has an entry for NO-BREAK SPACE (U+00A0, character 160) in the fonts cmap section where it maps character 160 to glyph 98. Glyph 98 in turn is a glyph that looks like the grave accent.

It also has an entry for GRAVE ACCENT (U+0060, character 96) where it is mapped to glyph 67 which is a slightly different grave accent which has been aptly named "grave".

It appears like a bug in the font where an accent was incorrectly copied into the position used for NO-BREAK SPACE.

Out of curiosity, do you see the same behavior in other applications?

Comment 3 by mar...@daknight.se, Oct 31 2017

Hello!

Okay, the reason why I assumed it was a browser based problem was because Safari actually display the   as a spaces, while Chrome display it as a grave accent. Looking at it now, Firefox also display it as a grave accent.

Thanks, we will have to rethink the use of Brandon Light.
Project Member

Comment 4 by sheriffbot@chromium.org, Oct 31 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "eae@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 5 by e...@chromium.org, Oct 31 2017

Status: WontFix (was: Unconfirmed)
Safari uses the space glyph for non-breaking space but the metrics for non breaking space (chrome used to do the same). We might have to go back to the behavior if this is causing compat problems but I'd obviously prefer to respect the wishes of the font creator and render the font as designed.

As we're matching Firefox here and are technically correct I'll go ahead and mark this bug as WontFix for now.

It would be quite easy to "fix" the font, all that is needed is to change the NO-BREAK SPACE entry in the cmap. If you can't get the author to update the font you might want to consider doing it yourself, assuming it is allowed by the license.

Another option would be to have a font that *only* provides the NO-BREAK SPACE glyph and set that as the prefered font:

font-family: "nb-sp-only-font", "Brandon Light";

Thank you and please comment here if you have any more questions or concerns.

Sign in to add a comment