1792214 - [COLRv1] Parallax font showing empty glyphs

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Dominik Röttsches (drott)]

Attachment: parallax_working.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36

Steps to reproduce:

On nightly, try to display example page for Parallax font by Simon Cozens:
https://github.com/simoncozens/parallax/issues/1

Actual results:

Parallax glyph show white / empty.

Expected results:

Parallax glyph should show in orange stripes, ideally with variations working.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Jonathan Kew [:jfkthame]]

Curious.... it renders for me in Nightly on macOS, but only when the variation axes are at their default values; as soon as they're non-zero, the glyphs vanish. Not yet sure what's going on here.

Comment 3

[Jonathan Kew [:jfkthame]]

This seems to be triggered by the font having variations (an 'fvar' table is present) but no 'gvar' -- it looks like this confuses the Core Text APIs that we rely on to get glyph outlines and advances, and as soon as any non-default variation values are passed, the glyphs (and advance widths) collapse.

Adding an empty 'gvar' table fixes it. As we don't have FreeType in our Mac build as an alternative for rasterizing the glyphs (which I presume is what Blink uses?), maybe we could add an empty 'gvar' during sanitization as a workaround.

Comment 4

[Dominik Röttsches (drott)]

We did have this issue with FreeType but that was fixed in https://gitlab.freedesktop.org/freetype/freetype/-/issues/1172 and the respective Chromium roll, compare: https://gitlab.freedesktop.org/freetype/freetype/-/issues/1172#note_1567073 - we do not require a GVAR anymore, so from our point of view no need to add that to OTS in general - but I guess it doesn't hurt too much. Although I'd have a slight preference for adding it after OTS if you need gvar before passing to CoreText. I would also suggest to file an issue with Apple.

Blink uses FreeType to get the path contours, but then rasterizes COLRv1 using Skia.

Comment 5

[Jonathan Kew [:jfkthame]]

Thanks for the details, Dominik.

I'm leaning towards adding this during OTS sanitization because at that point, we're already processing the entire font, rewriting the table directory, etc., so it's pretty easy to insert an extra entry; if we do it separately afterwards, it becomes more expensive as it requires another reconstruction of the font data before we can hand it to Core Text.

I've opened a PR at https://github.com/khaledhosny/ots/pull/249 to add gvar-synthesis to OTS, with a build-time flag so you can omit the feature if not required; I hope that'll be acceptable.

Comment 6

[Jonathan Kew [:jfkthame]]

(I'll also note that we may need this on desktop Linux as well as macOS, because although you've recently fixed the corresponding FreeType issue, we link against the system freetype library and can't guarantee that it will be updated with that fix any time soon.)

Comment 7

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1792214 - Apply OTS patch from https://github.com/khaledhosny/ots/pull/249 to work around Core Text and FreeType failures with variable COLR fonts that lack a gvar table. r=#gfx-reviewers

Comment 8

[Jonathan Kew [:jfkthame]]

Proposed patch attached as WIP for now, pending review upstream in the OTS repo.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/431ae85fa1a6
Apply OTS patch from https://github.com/khaledhosny/ots/pull/249 to work around Core Text and FreeType failures with variable COLR fonts that lack a gvar table. r=gfx-reviewers,jrmuizel

Comment 10

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/431ae85fa1a6