Created attachment 119747 [details] [PATCH] Fix wrong legacy LCD sub-pixel filter number I was having bad font filtering for some years on urxvt: I am used to the “legacy” LCD filter, and it didn't work anymore very well starting with Debian wheezy. I finally traced it back to fontconfig: a change to urxvt (in wheezy) made it aware of the lcd filter used, through FT_Library_SetLcdFilter() which got its setting from FcPatternGetInteger(…, FC_LCD_FILTER, …). Before that change to urxvt, strangely, the filtering worked well, I think because the system default that I set was set more “right” (i.e. not through fontconfig API, but somehow internally, I suppose) by fontconfig. So, the bug I found is that FC_LCD_LEGACY (FC_LC_FILTER setting for the legacy filter) is set to 3 in fontconfig, while it is 16 in FreeType; see <http://www.freetype.org/freetype2/docs/reference/ft2-lcd_filtering.html> or <http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/include/freetype/ftlcdfil.h#n137>. The result is that FreeType then uses no LCD filtering as it does not know this filter number, leading to colorful fonts. This dates back to 2008… The attached patch fixes it and makes me happy. BTW, I do not understand why you do not get this information directly from FreeType's headers, instead copying it… could it solve further problems if you did it so? Is this in a TODO list needing some patch? And finally, I saw that the legacy filter seems “deprecated” and may go away one day; I know I should rather tell the FreeType developers, but I would like to pray you for it here: please keep it around! I use strong hinting with this filter, and it works beautifully!
Well, I don't know the background of this code though, apparently no changes in freetype nor fontconfig since it is available. it may not be supposed to be equal to freetype. in fact cairo do handle it that way say (http://cgit.freedesktop.org/cairo/tree/src/cairo-ft-font.c#n1758). ideally it should be same as what freetype has perhaps. but it changes API and affects a lot of software which supports this feature and already deals with it as different value, plus, it may breaks a lot if freetype changes it. so it may be better dealing with it separately, at least so far. it may be worth considering in fontconfig 3 though.
> Well, I don't know the background of this code though, apparently no > changes in freetype nor fontconfig since it is available. it may not > be supposed to be equal to freetype. What?! For me it was obvious that this were supposed to be the same… Are you really sure about that? That would be a strange design decision. > in fact cairo do handle it that way say > (http://cgit.freedesktop.org/cairo/tree/src/cairo-ft-font.c#n1758). Wow. You mean Cairo does its own correspondence between lcd filters? So every application using fontconfig and freetype should do its own correspondence? This seems insane. What a poor design. > ideally it should be same as what freetype has perhaps. but it > changes API and affects a lot of software which supports this feature > and already deals with it as different value, plus, it may breaks a > lot if freetype changes it. Well, first this is only an ABI change, furthermore to *fix a bug*, but still a change, yes. But then, I wondered why all my other applications didn't “break”, i.e. did not fall back to no filtering; I applied my change system-wide, without recompiling every cairo based application. And the result was that I still get the *right* legacy filter! Looking at the code, it seems that this is because, when getting the lcd_filter value http://cgit.freedesktop.org/cairo/tree/src/cairo-ft-font.c#n1745 that is unknown to it then it stays at its default which is CAIRO_LCD_FILTER_DEFAULT cf. http://cgit.freedesktop.org/cairo/tree/src/cairo-font-options.c#n72 which gives a FT filter of… FT_LCD_FILTER_LEGACY! http://cgit.freedesktop.org/cairo/tree/src/cairo-ft-font.c#n3085 So, we fall back well for cairo even with my change… I know it may not hold true with every other app, but there is something very strange with this interface anyway, that fontconfig values do not correspond to FT's ones… For my case, libXft does not do the right thing. > so it may be better dealing with it separately, at least so far. What do you mean by “separatly”? > it may be worth considering in fontconfig 3 though. It would really be a shame… I have been chasing this bug for years, and it broke the beautiful legacy rendering that I see a lot of people regret when you read all the reports about the blurry look of lots of todays distros default config. The right solution is to define very well what is your interface regarding these values and their relation to freetype. If you keep on having different definitions, then I think several software would need fixing, like libXft. It would be a better idea to define a common and consistent interface
(In reply to Benjamin Cama from comment #2) > > Well, I don't know the background of this code though, apparently no > > changes in freetype nor fontconfig since it is available. it may not > > be supposed to be equal to freetype. > > What?! For me it was obvious that this were supposed to be the same… Are > you really sure about that? That would be a strange design decision. This should be the first log that FT_LCD_FILTER_LEGACY is available into the header file: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/include/freetype/ftlcdfil.h?id=8765c71b41625406fe87598645d842ca8451983c And fontconfig: http://cgit.freedesktop.org/fontconfig/commit/fontconfig/fontconfig.h?id=53aec111074cf7b46d15eb84a55791d3c95bc15e That looks to me like explaining it so. > The right solution is to define very well what is your interface > regarding these values and their relation to freetype. If you keep on > having different definitions, then I think several software would need > fixing, like libXft. It would be a better idea to define a common and > consistent interface I'm afraid there are no plans to break API/ABI of fontconfig so far, particularly for 2.x. even no real plans for fontconfig 3.
(In reply to Akira TAGOH from comment #3) > That looks to me like explaining it so. Explaining it? It just states that the interface in fontconfig has been added because one was added in freetype. It does not say anything about being equal, but it *may* be interpreted like so. But I admit I did not find any other occurrence of almost-matching interface (quick search only). So this may only be a coincidence… > > The right solution is to define very well what is your interface > > regarding these values and their relation to freetype. If you keep on > > having different definitions, then I think several software would need > > fixing, like libXft. It would be a better idea to define a common and > > consistent interface > > I'm afraid there are no plans to break API/ABI of fontconfig so far, > particularly for 2.x. even no real plans for fontconfig 3. Is this an official statement from the fontconfig developers? So, libraries using fontconfig and freetype should do the matching themselves? If so, then libXft would need a fix. I may do that if I find time.
(In reply to Benjamin Cama from comment #4) > (In reply to Akira TAGOH from comment #3) > > That looks to me like explaining it so. > > Explaining it? It just states that the interface in fontconfig has been > added because one was added in freetype. It does not say anything about > being equal, but it *may* be interpreted like so. > > But I admit I did not find any other occurrence of almost-matching interface > (quick search only). So this may only be a coincidence… > > > > The right solution is to define very well what is your interface > > > regarding these values and their relation to freetype. If you keep on > > > having different definitions, then I think several software would need > > > fixing, like libXft. It would be a better idea to define a common and > > > consistent interface > > > > I'm afraid there are no plans to break API/ABI of fontconfig so far, > > particularly for 2.x. even no real plans for fontconfig 3. > > Is this an official statement from the fontconfig developers? That's what the incumbent maintainer said, so yes. > So, libraries > using fontconfig and freetype should do the matching themselves? If so, then > libXft would need a fix. I may do that if I find time. Easier to fix remaining clients than to change something now and change every other client... Documentation would be nice though. Alternatively, may I suggest, we change FreeType to recognize 3 as well as 16?
(In reply to Behdad Esfahbod from comment #5) > (In reply to Benjamin Cama from comment #4) > > (In reply to Akira TAGOH from comment #3) > > > I'm afraid there are no plans to break API/ABI of fontconfig so far, > > > particularly for 2.x. even no real plans for fontconfig 3. > > > > Is this an official statement from the fontconfig developers? > > That's what the incumbent maintainer said, so yes. Understood. Sorry I did not know Akira's position in the project. So, should one close this bug as WONTFIX? > > So, libraries > > using fontconfig and freetype should do the matching themselves? If so, then > > libXft would need a fix. I may do that if I find time. > > Easier to fix remaining clients than to change something now and change > every other client... Documentation would be nice though. Yes, I understand this is an easier path. > Alternatively, may I suggest, we change FreeType to recognize 3 as well as > 16? Well, this kind of blurs the interface more with this kind of hack. Should I report this possibility to the freetype maintainers to get their feeling on this?
I've just added FT_LCD_FILTER_LEGACY1 to FreeType, which corresponds to value 3.
(In reply to Werner Lemberg from comment #7) > I've just added FT_LCD_FILTER_LEGACY1 to FreeType, which corresponds to > value 3. Thanks for this fix! It will help old non-conforming clients. And it's nice to have the explanation in the API's documentation.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.