[Fontconfig] FT_COLOR (was Re: Fwd: [ft-announce] FreeType now supports color emojis

[Behdad Esfahbod]

Thanks Jungshik,

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
> place.  
> 
> Jungshik 
> 
> 
> 
> 
> 
> 
> 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
>         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?
> 
> 
>     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). 
> 
>     Jungshik 
> 
>      
> 
> 
>         --
>         behdad
>         http://behdad.org/
>         _______________________________________________
>         Fontconfig mailing list
>         Fontconfig at lists.freedesktop.org <mailto:Fontconfig at lists.freedesktop.org>
>         http://lists.freedesktop.org/mailman/listinfo/fontconfig
> 
> 
> 

-- 
behdad
http://behdad.org/