New issue
Advanced search Search tips
Starred by 1 user

Issue metadata

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

Sign in to add a comment

Issue 880398: Layer misalignment in variable color fonts (COLR/CPAL)

Reported by, 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 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.
160 KB Download

Comment 1 by, Sep 4

Components: Blink>Fonts
Labels: Needs-Milestone

Comment 3 by, Sep 5

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.

2.3 MB View Download

Comment 4 by, Sep 5

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
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

Comment 5 by, Sep 5

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

For more details visit - Your friendly Sheriffbot

Comment 6 by, Sep 5

Labels: Needs-Triage-M69

Comment 7 by, Sep 10

Status: Assigned (was: Unconfirmed)

Comment 8 by, Nov 22

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.

Comment 9 by, Nov 22 produces the rendering attached, pure CoreText reproduction shows the same issue.
49.8 KB View Download

Comment 10 by, Nov 22

Status: ExternalDependency (was: Assigned)
Filed as radar://46212997

Sign in to add a comment