1306585 - When text-shadow is present, color:transparent is ignored for text using COLR/CPAL or SVG-in-OT fonts

Status: RESOLVED WORKSFORME

(Core :: Graphics: Text, defect)

Description

[Tigran Sargsyan]

Attachment: Firefox emoji text shadow color bug

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36

Steps to reproduce:

I am trying to color the emoticons uniformly with a solid color with the following CSS:

color: transparent;
text-shadow: 0 0 0 red;

https://jsfiddle.net/tikosar/bs2x0j48/

A similar bug was filed a year ago here https://bugzilla.mozilla.org/show_bug.cgi?id=1128190. For some reason it is marked as resolved. Though the issue still persists, moreover, it also happens for blur values other than 0. 


Actual results:

The emoticons' shadows are colored with their colors, not the color specified in text-shadow.


Expected results:

The emoji should have one solid color specified in text-shadow.

Comment 1

[Jonathan Kew [:jfkthame]]

Ah, I see.... the issue here isn't actually the shadow, which is correctly rendered using the specified text-shadow color; the problem is that the primary rendering of the colored glyph is not respecting the "color:transparent" property when a shadow is present.

This becomes easier to see if you make the example bigger and offset the shadow:

  font-size:60px;
  text-shadow: 10px 10px 0 red;

Then you can see that there IS a red shadow, as expected; but that the glyphs themselves are not transparent (and so in your original example, they directly overprint the shadows).

This occurs with colored fonts using either the COLR/CPAL or embedded-SVG formats; on OS X, where the color-emoji font uses an embedded bitmap technology instead, it renders as expected.

Updating the bug description to be more specific.

Comment 2

[Jonathan Kew [:jfkthame]]

The problem is wider than just text-shadow: the emoji glyphs will unexpectedly appear (despite being styled with 'color:transparent') if you select the text, and/or if it has a text-decoration (such as underline) applied.

Comment 3

[Jonathan Kew [:jfkthame]]

Attachment: Be more careful to avoid drawing text when the color is transparent, because inherently-colored fonts do not respect the current color from the context

It looks like we can fix this by making gfxTextRun::Draw smarter about when it should skip drawing text that has no visible color.

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: Reftest for color:transparent used together with text-shadow/text-decoration and colored emoji fonts

Comment 5

[Xidorn Quan [:xidorn] UTC+11]

Shouldn't we ignore color property including its alpha component for color glyphs at all, per discussion in www-style [1]?

[1] https://lists.w3.org/Archives/Public/www-style/2016Mar/0431.html

Comment 6

[Jonathan Kew [:jfkthame]]

Hmm, that's a good point, I'd forgotten about that exchange. That means we have a different bug, in that we currently -do- allow color:transparent to hide the glyphs in simple cases (when no text-shadow/decoration/selection is present).

It also means the reporter's original example here (intended to hide the glyphs and only show their shadow) cannot work as designed, because color:transparent won't hide the color glyphs at all. (And using opacity isn't an alternative because that would also affect the shadow.)

Are we OK with saying that use case is just not supported in any way? (Maybe there'd be some way to achieve a similar result using CSS filters?)

Comment 7

[Xidorn Quan [:xidorn] UTC+11]

That's a good question. It is possible via CSS filters: https://jsfiddle.net/7o9c224r/ It somehow doesn't work correctly in Gecko as well, but it at least works on both Blink and WebKit. (The original demo doesn't work on WebKit because color property doesn't control color glyphs in WebKit.) I don't know why it doesn't work on Gecko, but that is definitely a bug we want to fix.

The only down side of using filter is that, the selection color is changed as well. But I believe using filter provides more flexibility than transparent+shadow.

But I think our current behavior is broken either way, so we should make it consistent either via making alpha component always control, or never control the transparency of color glyphs.

jfkthame, how hard do you think it is to fix bug 1260575?

Comment 8

[Xidorn Quan [:xidorn] UTC+11]

(Looks like that demo doesn't work because svg is display: none. Not sure whether that is supposed to work, but WebKit and Blink seem to work as expected.)

Comment 9

[Jonathan Kew [:jfkthame]]

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #7)
> jfkthame, how hard do you think it is to fix bug 1260575?

It looks to me like it'll be a bit tricky, involving a substantial reworking of the low-level text drawing code. I think the main problem is that we handle alpha at the textrun level, particularly to handle the case of multistrike synthetic-bold, but we don't know until we get down to the individual glyph in gfxFont::DrawOneGlyph whether we actually have a color or SVG glyph to paint. At that point, if we're painting to a temporary buffer that we're going to composite with alpha, the decision has already been made.

Maybe we'd have to hoist the check for color glyphs (on a per-glyph basis, because a font may contain color glyphs for some of its characters but not others) up to the text-run construction stage, so that we can always make sure to put any color glyphs into a separate GlyphRun from non-color glyphs. But care will be needed to make sure we don't regress overall text performance.

Comment 10

[Jonathan Kew [:jfkthame]]

As far as I can tell this example now works as expected. The text-rendering code has had substantial reworking since this was filed, though offhand I'm not sure exactly when this was fixed; closing as WFM.