[Fontconfig-bugs] [Bug 92981] Wrong legacy sub-pixel filter number leading to bad filtering

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=92981

--- Comment #2 from Benjamin Cama <benoar at dolka.fr> ---
> 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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/fontconfig-bugs/attachments/20151118/1eb0e848/attachment.html>