New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 758223 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Aug 2017
Cc:
█ krajshree@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

/space glyph gets ignored in OpenType code

Reported by eima...@gmail.com, Aug 23 2017 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36

Steps to reproduce the problem:
1. Go to http://www.impallari.com/testing/index-latin-02.php and select "Kern Words"
2. Load up the attached font.
3. Do same thing in Safari and compare results

What is the expected behavior?
Words should start with a capital letter from one of 3 stylistic sets

What went wrong?
Instead all words start with letters from the first set.

Did this work before? No 

Chrome version: 60.0.3112.101  Channel: stable
OS Version: OS X 10.12.5
Flash Version: 

The font has 3 stylistic sets for #calt feature. The code is written so that /space does not interrupt rotation between alternates. The problem is that apparently before processing code, Chrome turns all spaces (U+0020) into /nbspace (U+00A0). Found this out by pasting spaces into a unicode checker. This means that any OT code line containing /space gets ignored. I tried adding /nbspace glyph to the font and the code but it did not work.
Signato011-3-Regular.otf.zip
60.8 KB Download

Comment 1 by krajshree@chromium.org, Aug 24 2017

Cc: krajshree@chromium.org
Components: Internals>Skia Blink>Fonts
Labels: Needs-Triage-M60 Needs-Feedback
Unable to reproduce the issue in MacBook Pro (Retina, 15-inch, Mid 2014), 10.12.6 using chrome reported version #60.0.3112.101 and latest canary #62.0.3194.0.

Following are the steps followed to reproduce the issue.
------------
1. Navigated to http://www.impallari.com/testing/index-latin-02.php and selected "Kern Words"
2. Loaded up the attached font.
3. Did same thing in Safari and compared results.
4. Observed that both the safari and chrome behaviour are same.

Attaching screen cast and screen shots for reference.

eimapas@ - Could you please check the screen cast and screen shots and please let us know if anything missed from our side. Also please check the issue on latest canary #62.0.3194.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!
758223.mp4
21.1 MB Download
Font@chrome.png
623 KB View Download
Font@Safari.png
564 KB View Download

Comment 2 by eima...@gmail.com, Aug 24 2017 

Checked – issue persists on canary #62.0.3194.0 too.

In the attached file I circled the letters from different stylistic sets so it's easier to see. Also notice the /d in "cod". The OT code for substitution is:

sub d' space by d_old;

It works in Safari but because Chrome does not recognize /space, the line (and substitution) gets ignored.
deaa5913-1c8b-4730-a446-9133e91edd3b.png
603 KB View Download
Project Member

Comment 3 by sheriffbot@chromium.org, Aug 24 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "krajshree@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 4 by e...@chromium.org, Aug 29 2017

Status: WontFix (was: Unconfirmed)
Thanks for the report. Chrome currently segments text on space by default for performance reasons.
Adding "text-rendering: optimizeLegibility;" disables that and us render the text as expected.

We're currently in the process of changing our line layout implementation and that work will fix this without the need for any extra css properties.

Until then though hopefully the workaround suggested above is sufficient for your use case.

Thanks.
►

Sign in to add a comment