[Fontconfig] FT_COLOR (was Re: Fwd: [ft-announce] FreeType now supports color emojis
behdad at behdad.org
Wed Aug 20 12:39:16 PDT 2014
The patch looks mostly good to me. I'll commit it soon.
On 14-08-17 06:08 AM, Jungshik SHIN (신정식) wrote:
> Hi Behdad,
> Attached is my patch to add FC_COLOR (the patch is against ToT as of now).
> It's the same patch that I attached to http://crbug.com/386772
> I'm not sure about the priority so that I just put it in a rather arbitrary
> On Sun, Aug 17, 2014 at 12:04 AM, Jungshik SHIN (신정식) <jshin1987 at gmail.com
> <mailto:jshin1987 at gmail.com>> wrote:
> On Sat, Aug 16, 2014 at 12:32 PM, Behdad Esfahbod <behdad at behdad.org
> <mailto:behdad at behdad.org>> wrote:
> [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
> > 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
> > 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
> > 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
> 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
> 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
> continue not setting FC_COLOR, but ignore the FC_COLOR results in the
> font. The only problem with this is that user config won't be able to
> color on / off.
> Humm. One problem with this is that if anyone does 2), then the color
> technology will be only usable for emoji. You can't have a color font
> 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?
> My patch is speculative and I only tested with fc-query command. Anyway,
> I'll send it your way in an hour or so (I have to do some chores atm).
> Fontconfig mailing list
> Fontconfig at lists.freedesktop.org <mailto:Fontconfig at lists.freedesktop.org>
More information about the Fontconfig