<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>