[Fontconfig] Fwd: [ft-announce] FreeType now supports color emojis

[Behdad Esfahbod]

[Reviving old thread]
On 13-07-16 07:01 PM, Raimund Steger wrote:
> Behdad Esfahbod wrote:
>> On 13-07-14 09:17 PM, Raimund Steger wrote:
>>>
>>>>>    3. If user requests FC_COLOR=false and a font with FC_COLOR=true is
>>>>> chosen,
>>>
>>> These should be some real corner cases.
>>
>> Not really.  If the only fonts supporting a character is color, this happens.
> 
> That's true, but... right now, in many setups most of the Unicode character
> range is covered by existing scalable fonts, like Droid Sans Fallback, Arial
> Unicode, etc. So right now it would mostly happen for glyphs outside the usual
> character ranges; chances are that these *would* be emoji glyphs where user
> tolerance toward accidental color rendering might be a bit higher... but of
> course that's difficult to say in advance and it's also not a good quality
> standard. The picture might change, too. It's just that if we copy the value
> from the pattern, I'm not sure how easy it would be for users to disable that
> behavior in their local configuration files, if they wanted to. Which again is
> a rather far-fetched scenario.
> Don't get me wrong, I'm not trying (too hard) to convince you of anything
> here. Actually I don't have a very strong opinion on the subject.
> 
> Other possibilities:
> 
> (2) fontconfig could initialize the 'color' property at scan time for cache
> entries *only* in the case fonts have no color, and *not* set it in all other
> cases. This would a bit like the current 'antialias' behavior and it's
> semantically similar, too (meaning it's open to renderer settings and not
> predetermined by the cache). If I remember right, that way fontconfig will
> copy any value from the pattern automatically if the match result was a color
> font, because that font didn't have it in the cache; if no 'color' value was
> in the pattern, it will just not set the property which should be fine as
> FreeType will just render it in color. Users could disable the behavior with
> target="scan" rules.

I think I like this!

So, for non-color fonts we scan FC_COLOR=false.  Then, in
FcDefaultSubstitute(), we set FC_COLOR=false in the pattern.  It won't quite
work currently because I broke it in 2008, but I like to fix that soon
(https://bugs.freedesktop.org/show_bug.cgi?id=80873#c10).  After that's fixed,
this is how it will work:

  1) Old clients who don't know about color won't set FC_COLOR, get
FC_COLOR=false in FcDefaultSubstitute, and always get FC_COLOR=false in the
matched font and will get fallback grayscale rendering from FreeType for color
fonts,

  2) Color-aware clients will set FC_COLOR=True, which will make them get
color fonts preferred over non-color.  The match result will have FC_COLOR if
the font was color,

  3) Color-aware clients that don't want color to change font matching will
continue not setting FC_COLOR, but ignore the FC_COLOR results in the matched
font.  The only problem with this is that user config won't be able to turn
color on / off.

Humm.  One problem with this is that if anyone does 2), then the color font
technology will be only usable for emoji.  You can't have a color font (say,
that covers ASCII) installed, because with that you will always get that font
when you, eg, ask for sans.  So, I think this option is out.

Ok, lets fully set FC_COLOR in the font, and match on it (what priority?).  If
client doesn't set, we won't prefer color or non-color.  If client asked, with
give it just that.  The client's preference will be lost in the matched
result, but we don't care, client can look it up itself.

Jungshik, do you have a patch for this you said?

-- 
behdad
http://behdad.org/