Closed Bug 1738589 Opened 9 months ago Closed 9 months ago

CSS color is ignored for fonts with COLR/CPAL tables

Categories

(Core :: Graphics: Text, defect)

Firefox 93
x86_64
macOS
defect

Tracking

()

VERIFIED FIXED
96 Branch
Tracking Status
firefox96 --- verified

People

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

References

Details

Attachments

(4 files)

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

In the page https://www.amirifont.org/fatiha-colored2.html 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
action.

Assignee: nobody → lsalzman
Status: NEW → ASSIGNED
Flags: needinfo?(lsalzman)
Flags: needinfo?(jmuizelaar)
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/fd38093162bc
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)
Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → 96 Branch
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6af6b19b6dcb
Let Gecko decide if WR Mac font has color glyphs. r=jfkthame

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

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