New issue
Advanced search Search tips

Issue 880398 link

Starred by 1 user

Issue metadata

Status: ExternalDependency
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Layer misalignment in variable color fonts (COLR/CPAL)

Reported by henrique...@gmail.com, Sep 4

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 OPR/55.0.2994.44

Steps to reproduce the problem:
1. Go to https://www.axis-praxis.org and type “eé” in the topmost field.
2. Drag and drop the attached font file into “Drag & drop fonts here” area on the right side.
3. Experiment sliding the “Bevel” slider.

What is the expected behavior?
No matter the Bevel value, “e” and “é” should be rendered consistently.

What went wrong?
If the glyph contains components (like the “é” glyph, which contain “e” and “acute”), the variations can become misaligned.

Did this work before? No 

Chrome version: 68.0.3440.106  Channel: stable
OS Version: OS X 10.13.6
Flash Version: 

Microsoft Edge and Firefox 62 render it correctly.
 
RocherColorGX-subset.ttf
160 KB Download
Components: Blink>Fonts
Labels: Needs-Milestone
Cc: susan.boorgula@chromium.org
Labels: -Needs-Milestone Needs-Triage-M68 Needs-Feedback Triaged-ET
henriquebeier@ Thanks for the issue.

Tested this issue on Windows 10 and Mac OS 10.13.3 on the reported version 68.0.3440.106 and the latest Canary 71.0.3543.0.

1. Launched Chrome and navigated to the given web page.
2. Typed “eé” in a new text box and dragged & dropped the given font file.
3. Tried sliding the Bevel slider and could not observe any “e” and “é” value.
Attached is the screen cast for reference.

Request you to check and confirm if anything is missed from our end in triaging the issue.

Also request you to provide a screen cast of the steps followed, which will be helpful in better understanding of the issue.

Thanks..
880398.mp4
2.3 MB View Download
Susan, thanks for trying it out. I apologize for my first report as the steps to reproduce weren't very clear. I have updated them below and included a screencast.

Steps to reproduce the problem:
1. Go to https://www.axis-praxis.org/.
2. Replace the text “Axis-Praxis is a website for playing with OpenType Variable Fonts” with “eé”.
3. Drag and drop the attached font file into “Drag & drop fonts here” area on the right side.
4. Increase the font-size using the slider on the right.
5. Experiment sliding the “Bevel” slider and notice how the two “e” get rendered different.

MacOS High Sierra: the bug is present in both Chrome 69.0.3497.81 and Canary 71.0.3543.0.

Windows 10: Chrome 69.0.3497.81 does not support COLR/CPAL fonts, so it doesn’t apply here. Canary 71.0.3543.0 on Windows does NOT have this bug, as observed in the screencast.
Chromium variable color fonts.mp4
2.5 MB View Download
Project Member

Comment 5 by sheriffbot@chromium.org, Sep 5

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: Needs-Triage-M69
Owner: drott@chromium.org
Status: Assigned (was: Unconfirmed)
Thanks for the report, Henrique. I can reproduce this in Chrome on Mac and in Firefox nightly on Mac. This seems to be an issue with the underlying MacOS CoreText library computing an incorrect rasterization for this variable COLR/CPAL font. On Windows we use FreeType for variable fonts, that's why the rendering looks correctly there. I'll see if I can forward this as a bug to Apple.

https://gist.github.com/drott/5ce9cbe1508e1a9bb153dfc1e1a44b1c produces the rendering attached, pure CoreText reproduction shows the same issue.


coretext_color_variable_font.png
49.8 KB View Download
Status: ExternalDependency (was: Assigned)
Filed as radar://46212997

Sign in to add a comment