Re: [css-fonts] selecting color or monochrome glyphs for emoji fonts

On Thu, Aug 21, 2014 at 1:21 PM, Behdad Esfahbod <behdad@google.com> wrote:
> On Thu, Aug 21, 2014 at 4:08 AM, Cameron McCormack <cam@mcc.id.au> wrote:
>>
>> John Daggett wrote:
>>>
>>> As emoji fonts gain popularity across platforms, authors are
>>> starting to run into problems where they end up getting a color
>>> emoji glyph for a symbol they desire to be monochrome (for an
>>> example bug report, see [1]). I'm thinking it might make sense to
>>> have a CSS property to allow authors to explicitly control this:
>>>
>>> font-variant-color: auto | color | monochrome
>>> initial value: auto
>>
>> This sounds like a good idea to me.
>
> I'd rather CSS doesn't go down that path.  CSS doesn't specify whether fonts
> should be hinted, use embedded bitmaps or not, render as subpixel,
> grayscale, etc.  It's out of the scope IMO.

I don't think this is comparable to that.  This seems much more like
turning on alternate ligatures or historical figures; you're choosing
which of several variant glyphs to use for a given family of
characters.

>>> Like other font-variant property values, this would only affect
>>> glyph selection. If alternate glyphs are not available, using this
>>> property would not affect how text is rendered. User agents must not
>>> try and simulate fallback glyphs for fonts lacking color glyphs.
>>
>> What happens if you use "font-variant-color: monochrome" and the font has
>> a colour glyph but no monochrome glyph?
>
> At least on the Free platforms, we like to support converting from color to
> monochrome (which might be grayscale, not necessarily a 1bit image) if
> needed.  As such, we don't see font coverage dependent on color or no color.

I agree that some fonts may be able to convert from color back down to
monochrome.  Not all will, and if they're missing a given glyph I
suspect we'd want to do font fallback.

~TJ

Received on Thursday, 21 August 2014 21:05:25 UTC