[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