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@xxxxxxxxx > <mailto:jshin1987@xxxxxxxxx>> wrote: > > > > > On Sat, Aug 16, 2014 at 12:32 PM, Behdad Esfahbod <behdad@xxxxxxxxxx > <mailto:behdad@xxxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxxxx <mailto:Fontconfig@xxxxxxxxxxxxxxxxxxxxx> > http://lists.freedesktop.org/mailman/listinfo/fontconfig > > > -- behdad http://behdad.org/ _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
