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

[Jungshik SHIN (신정식)]

On Sat, Aug 16, 2014 at 12:32 PM, Behdad Esfahbod <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
> http://lists.freedesktop.org/mailman/listinfo/fontconfig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/fontconfig/attachments/20140817/2836aa6c/attachment.html>