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

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.


 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 should note here that all the color font formats in use currently
>> (Apple/Google/Microsoft/SVG) all add additional tables to a TrueType
>> font to contain the color glyph data. So there are typically
>> monochrome glyphs for all characters but not necessarily color
>> glyphs.
>>
>
> Do you think we need a way to select between the different coloured font
> tables?  I'm not sure how likely it is that we'll see fonts with CBDT and
> SVG and COLR tables, but it's possible.
>

No.  Those are implementation details.