1738589 - CSS color is ignored for fonts with COLR/CPAL tables

Status: VERIFIED FIXED

(Core :: Graphics: Text, defect)

Description

[Khaled Hosny]

Attachment: Firefox rendering, CSS color is ignored

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.

Comment 1

[Khaled Hosny]

Attachment: Firefox rendering on Windows, CSS color is applied

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

Comment 2

[Khaled Hosny]

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

Comment 3

[Jim Blandy :jimb]

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

Comment 4

[Jonathan Kew [:jfkthame]]

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.

Comment 5

[Jonathan Kew [:jfkthame]]

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.

Comment 6

[Jonathan Kew [:jfkthame]]

Attachment: Strawman patch/hack that shows how CSS color can be allowed to work here

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?

Comment 7

[Jonathan Kew [:jfkthame]]

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

Comment 8

[Lee Salzman [:lsalzman]]

Attachment: Bug 1738589 - Let Gecko decide if WR Mac font has color glyphs. r?jfkthame

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.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fd38093162bc
Let Gecko decide if WR Mac font has color glyphs. r=jfkthame

Comment 10

[Marian-Vasile Laza]

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

Comment 11

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/fd38093162bc

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6af6b19b6dcb
Let Gecko decide if WR Mac font has color glyphs. r=jfkthame

Comment 13

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/6af6b19b6dcb

Comment 14

[Monica Chiorean]

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