<div dir="ltr">Hi Behdad,<div><br></div><div>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 <a href="http://crbug.com/386772">http://crbug.com/386772</a></div>
<div><br></div><div>I'm not sure about the priority so that I just put it in a rather arbitrary place.  </div><div><br></div><div>Jungshik </div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sun, Aug 17, 2014 at 12:04 AM, Jungshik SHIN (신정식) <span dir="ltr"><<a href="mailto:jshin1987@gmail.com" target="_blank">jshin1987@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Sat, Aug 16, 2014 at 12:32 PM, Behdad Esfahbod <span dir="ltr"><<a href="mailto:behdad@behdad.org" target="_blank">behdad@behdad.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[Reviving old thread]<br>
On 13-07-16 07:01 PM, Raimund Steger wrote:<br>
> Behdad Esfahbod wrote:<br>
>> On 13-07-14 09:17 PM, Raimund Steger wrote:<br>
>>><br>
>>>>>    3. If user requests FC_COLOR=false and a font with FC_COLOR=true is<br>
>>>>> chosen,<br>
>>><br>
>>> These should be some real corner cases.<br>
>><br>
>> Not really.  If the only fonts supporting a character is color, this happens.<br>
><br>
> That's true, but... right now, in many setups most of the Unicode character<br>
> range is covered by existing scalable fonts, like Droid Sans Fallback, Arial<br>
> Unicode, etc. So right now it would mostly happen for glyphs outside the usual<br>
> character ranges; chances are that these *would* be emoji glyphs where user<br>
> tolerance toward accidental color rendering might be a bit higher... but of<br>
> course that's difficult to say in advance and it's also not a good quality<br>
> standard. The picture might change, too. It's just that if we copy the value<br>
> from the pattern, I'm not sure how easy it would be for users to disable that<br>
> behavior in their local configuration files, if they wanted to. Which again is<br>
> a rather far-fetched scenario.<br>
> Don't get me wrong, I'm not trying (too hard) to convince you of anything<br>
> here. Actually I don't have a very strong opinion on the subject.<br>
><br>
> Other possibilities:<br>
><br>
> (2) fontconfig could initialize the 'color' property at scan time for cache<br>
> entries *only* in the case fonts have no color, and *not* set it in all other<br>
> cases. This would a bit like the current 'antialias' behavior and it's<br>
> semantically similar, too (meaning it's open to renderer settings and not<br>
> predetermined by the cache). If I remember right, that way fontconfig will<br>
> copy any value from the pattern automatically if the match result was a color<br>
> font, because that font didn't have it in the cache; if no 'color' value was<br>
> in the pattern, it will just not set the property which should be fine as<br>
> FreeType will just render it in color. Users could disable the behavior with<br>
> target="scan" rules.<br>
<br>
I think I like this!<br>
<br>
So, for non-color fonts we scan FC_COLOR=false.  Then, in<br>
FcDefaultSubstitute(), we set FC_COLOR=false in the pattern.  It won't quite<br>
work currently because I broke it in 2008, but I like to fix that soon<br>
(<a href="https://bugs.freedesktop.org/show_bug.cgi?id=80873#c10" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=80873#c10</a>).  After that's fixed,<br>
this is how it will work:<br>
<br>
  1) Old clients who don't know about color won't set FC_COLOR, get<br>
FC_COLOR=false in FcDefaultSubstitute, and always get FC_COLOR=false in the<br>
matched font and will get fallback grayscale rendering from FreeType for color<br>
fonts,<br>
<br>
  2) Color-aware clients will set FC_COLOR=True, which will make them get<br>
color fonts preferred over non-color.  The match result will have FC_COLOR if<br>
the font was color,<br>
<br>
  3) Color-aware clients that don't want color to change font matching will<br>
continue not setting FC_COLOR, but ignore the FC_COLOR results in the matched<br>
font.  The only problem with this is that user config won't be able to turn<br>
color on / off.<br>
<br>
Humm.  One problem with this is that if anyone does 2), then the color font<br>
technology will be only usable for emoji.  You can't have a color font (say,<br>
that covers ASCII) installed, because with that you will always get that font<br>
when you, eg, ask for sans.  So, I think this option is out.<br>
<br>
Ok, lets fully set FC_COLOR in the font, and match on it (what priority?).  If<br>
client doesn't set, we won't prefer color or non-color.  If client asked, with<br>
give it just that.  The client's preference will be lost in the matched<br>
result, but we don't care, client can look it up itself.<br>
<br>
Jungshik, do you have a patch for this you said?<br></blockquote><div><br></div></div></div><div>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). </div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Jungshik </div></font></span><div class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><font color="#888888"><br>
--<br>
behdad<br>
<a href="http://behdad.org/" target="_blank">http://behdad.org/</a><br>
_______________________________________________<br>
Fontconfig mailing list<br>
<a href="mailto:Fontconfig@lists.freedesktop.org" target="_blank">Fontconfig@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/fontconfig" target="_blank">http://lists.freedesktop.org/mailman/listinfo/fontconfig</a><br>
</font></span></blockquote></div></div><br></div></div>
</blockquote></div><br></div>