Closed Bug 1738589 Opened 2 years ago Closed 2 years ago

CSS color is ignored for fonts with COLR/CPAL tables


(Core :: Graphics: Text, defect)

Firefox 93



96 Branch
Tracking Status
firefox96 --- verified


(Reporter: dr.khaled.hosny, Assigned: lsalzman)




(4 files)

CSS color is ignored for fonts with COLR/CPAL tables for layers using the special palette index 0xFFFF.

In the page the black glyphs should be cyan. The color is applied in Firefox for Android, so might be macOS specific.

From the spec:

A palette entry index value of 0xFFFF is a special case indicating that the text foreground color (defined by the application) should be used and shall not be treated as actual index into CPAL ColorRecord array.

Component: Layout: Text and Fonts → Graphics: Text

CSS color is applied on Windows as well, so definitely macOS specific.

On macOS CSS color is ignored even for glyphs with no COLOR layers at all, as long as the font has COLR table.

On Linux, the characters appear in cyan as well, so this does seem to be macOS-specific.

Severity: -- → S3
Flags: needinfo?(jmuizelaar)
See Also: → 1738590

The Mac-specific nature of this will be related to the fact that on macOS, we don't use our own code in thebes to parse the COLR table and render the colored layers individually; instead we rely on Core Text's native support for the format. So presumably we're not setting the primary color properly when we call CT to render these glyphs.

So I think the immediate cause of the problem here is that in the webrender rasterize_glyph method on macOS, we set the color on the context to black (or possibly white?), not to the actual CSS current color. So when Core Text is handling COLR glyphs, and sees the "currentColor" palette index, we get black instead of the proper color for those layers.

Setting the context color to font.color would allow Core Text to apply the proper CSS color to such layers. Though it's not as simple as just using font.color here, because that was already munged in prepare_font, so we get a shade of green instead of the expected cyan.

Neutering that code, so that font.color is left untouched, results in the testcase here rendering the currentColor layers in cyan, as expected (and they respond properly to changes in the CSS). However, this would presumably regress rendering in various other situations/modes, so a proper fix will need a much deeper understanding of all that's going on.

So this is a proof-of-concept that demonstrates how passing the actual CSS color through to Core Text results in the expected rendering of the color-font layers here. However, I'm sure it breaks all kinds of other stuff (I haven't even tried to hit all the various rendering modes, etc), and will need to be done in a more refined manner.

Lee, I think you know more about how all this is managed within WR -- maybe you can take this and make something usable?

Flags: needinfo?(lsalzman)

FWIW, fixing this will also resolve bug 1520157, which is essentially the same issue.

See Also: → 1520157

WR tries to normalize Mac FontInstances so that regardless of the font color
we only need to generate one version of the glyph in the cache. This strategy
backfires for fonts with color glyphs that are nominally supposed to ignore
the font color, but may choose to opt-in to the font color per-glyph based
on table data.

This determination is problematic to do in WR itself, but Gecko knows whether
a font has color glyphs ahead of time. So we let Gecko pass this data into
ScaledFonts which can then transmit the knowledge of whether the font has
color glyphs to the WR Mac font backend, which will then take appropriate

Assignee: nobody → lsalzman
Flags: needinfo?(lsalzman)
Flags: needinfo?(jmuizelaar)
Pushed by
Let Gecko decide if WR Mac font has color glyphs. r=jfkthame

Backed out changeset fd38093162bc (Bug 1738589) for causing reftest failures on svg-glyph-invalid.html.
Backout link
Push with failures
Failure Log

Flags: needinfo?(lsalzman)
Flags: needinfo?(lsalzman)
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 96 Branch
Pushed by
Let Gecko decide if WR Mac font has color glyphs. r=jfkthame
Flags: qe-verify+

I was able to reproduce the issue on Mac 10.13 using build 95.0a1(20211031213949).
Verified as fixed on Mac 10.13 using build 96.0b3 (20211209163454) and 97.0a1(20211209155024), Win10 using 97.0a1(20211209155024) and Ubuntu 20.4 using 96.0b3(2021120916345).

Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.