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

Raimund Steger rs at mytum.de
Tue Jul 16 16:01:25 PDT 2013


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:

(1) we could introduce two properties: one for the matcher and one for 
the renderer, like 'weight' vs. 'embolden', 'slant'/'width' vs. 'matrix' 
etc. So: 'color' vs. 'opacitymap' (or whatever). But as I write it I 
recognize it's a bit ridiculous.

(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.

Raimund


-- 
Worringer Str 31 Duesseldorf 40211 DE  home: <rs at mytum.de>
+49-179-2981632 icq 16845346           work: <rs at interface-ag.de>


More information about the Fontconfig mailing list