Open Bug 1465324 Opened 6 years ago Updated 2 years ago

Non-COLR glyphs don't get text color applied

Categories

(Core :: Graphics: Text, defect, P3)

56 Branch
x86
macOS
defect

Tracking

()

Tracking Status
firefox60 --- affected
firefox61 --- affected
firefox62 --- affected

People

(Reporter: roel, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.170 Safari/537.36 OPR/53.0.2907.68

Steps to reproduce:

See: https://djr.com/merit-badge/test.html

A COLR font can also have the individual layers for its glyph available as stylistic sets. For example, A is made up of A.001, A.002 and A.003 in the COLR table. And then ss01 = A → A.001, ss02 = A → A.002, ss03 = A → A.003.

Since the glyphs in the stylistic sets are pointing to regular glyphs (and are not color glyphs themselves), I'd expect them to be rendered as regular glyphs. And they are, but they don't take the color from CSS — they are always rendered in black. 
The text should be rendered in the colors specified in the CSS

This works properly in Safari, but fails in the same way in Firefox (except it can't be "fixed" by making the font bold)

Tested on MacOS High Sierra 10.13.3 with Firefox 60.0.1 (64-bit)
 
(Chrome has a similar bug: https://bugs.chromium.org/p/chromium/issues/detail?id=847416)


Actual results:

The text is rendered in black only, ignoring colors defined both in CSS as in the CPAL table


Expected results:

The text should be rendered in the colors specified in the CSS
I have reproduced this issue on Mac OS 10.13 with Release (v60.0.1) and Nightly (v+62.0a1).

Please also note that this issue can NOT be reproduced on Mac OS x 10.12.6.
Status: UNCONFIRMED → NEW
Component: Untriaged → CSS Parsing and Computation
Ever confirmed: true
OS: Unspecified → Mac OS X
Product: Firefox → Core
Hardware: Unspecified → x86
Component: CSS Parsing and Computation → Graphics: Text
Is this related to bug 1306585?
Flags: needinfo?(jkew)
Priority: -- → P3
Flags: needinfo?(jkew) → needinfo?(jfkthame)
(In reply to Andrew Osmond [:aosmond] from comment #2)
> Is this related to bug 1306585?

Somewhat; I suspect fixing this would probably involve the issues mentioned in bug 1306585 comment 9. I think the problem is that we determine whether to use the color-glyph rendering path (which ignores CSS color, as it's using color inherent in the glyphs) or the non-color path (applying CSS color to monochrome glyphs) on a per-font basis, based on whether the font has color glyphs. In this example, the font does have color glyphs but the testcase isn't using them; it's rendering the component glyphs that represent color layers as standalone monochrome glyphs. But because we viewed it as a "color font", we don't apply CSS color to them.

So this does sound a lot like what bug 1306585 comment 9 mentioned, in a slightly different context.
Flags: needinfo?(jfkthame)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.