Bug 92981

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.