Looking at your examples, and specifically the one with Dejavu, did you notice that font width changes a lot between spr or no spr? It's not about just a few pixels, it's a huge increase in size compared to the tiny font size that it happens with.

The line with the extreme width change in DejaVu (the second line) has a font size of 7.5pt (@96ppi).

The unhinted text has a width about half between the two renderings.

I'm for staying plain vanilla unpatched here as always in Arch.

This isn't about patched vs. unpatched, it's an upstream compile-time option exposed as a preprocessor flag just like subpixel support itself.

Seems the screenshots I made are outdated; the behavior changed again. alucryd did a new series of comparisons at http://pkgbuild.com/~alucryd/freetype/ . 1 is without SPH, 2 is with SPH. The few images having a 3 are from freetype2-infinality.

I've also written a patch that allows getting the old behavior back by setting the environment variable "FT2_NO_SUBPIXEL_HINTING", see http://pkgbuild.com/~heftig/packages/freetype2-git/env_FT2_NO_SUBPIXEL_HINTING.diff .

I didn't expect too much, but the env patch was rejected upstream. The application is supposed to select the interpreter version.

I suppose this means for a proper solution, at least fontconfig and perhaps other parts of the stack will have to learn how to set the version.

Should I leave the patch in for now? I haven't pushed anything yet as I wanted to wait for feedback.

Could this be done via a fontconfig tunable rather than an environment variable?

Any objections to applying the getenv patch? It'll be something that never goes upstream.

@thestinger: That it how it *should* work, but I don't have time to dive into fontconfig.

We should stick to the default behavior and keep the package as vanilla as possible; so -1 for the getenv patch.

SPH also makes some fonts render slightly fuzzy (e.g. DejaVu Sans). Making a pretty common Linux font like that render worse so that e.g. Segoe UI doesn't appear fuzzy doesn't seem like a good trade-off to me.

Even setting FT2_SUBPIXEL_HINTING=0 many fonts (e.g. Monospace used in text editors) are no longer fine rendered. I agree that old MS fonts may have problems, but... standard linux fonts also?. Setting sub-pixel-order to NONE in XFCE improves things (e.g. no color artifacts) but doesn't restores the better previous appeareance (e.g. the "l" and "d" have different vertical thickness). I have reverted (at least by the moment) to the previous freetype-2.5.3-2 package.

cgarcia, note that the patch checks for *presence* of the envvar, not the value. You need to completely unset it.

A few days ago I upgraded and manually set FT2_SUBPIXEL_HINTING to 1 thinking that I have used that feature for the last years and want to continue using it (at least XFCE has settings for hinting and subpixel order and they change the fonts appearance). In the poor laptop screen (I was out of home) I didn't pay much attention to the bad fonts.

Now at home with in my desktop LCD, after identifiying freetype2 as the "culprit" package of the poor fonts rendering, I set the environment variable to 0 (even I didn't remembered to have set it to 1 a few days ago) and this doesn't disables hinting... fortunately, by looking at the source code of the patch, I see that it only tests for the variable presence. You have to NOT SET the variable at all.

I think that it may be a bit misleading that FT2_SUBPIXEL_HINTING=0 also *ENABLES* subpixel hinting.

Thanks grawity, I just have figured it. Now all is OK again with the latest package.