Arch Linux

Subpixel rendering is already enabled. There's nothing to do.

No, you have to add this simple patch for this: https://aur.archlinux.org/cgit/aur.git/tree/0007-cleartype.patch?h=freetype2-cleartype

Ah, yes, I forgot we removed the patch in 2.8.1 because FreeType gained an equivalent free version.

Really, the experience is much better without. The free version doesn't have to mess with LCD filters where half the font stack defaults to the absolutely horrible "legacy" filter.

Dear Microsoft, thank you for nothing. Correct?

Actually, default upstream is not a subpixel rendering, but something that brings near cleartype subpixel rendering.
I did tests for the past few months when I got a UHD monitor and in my opinion, ~185 dpi (24inch 4k) and above, you don't need subpixel rendering at all. At lower dpi's I would test with subpixel enabled and LCD filter and see if it brings improvements with acceptable color fringing (examine very small size and very large texts to see difference). But you still need to compile freetype with FT_CONFIG_OPTION_SUBPIXEL_RENDERING to test/activate subpixel rendering since as mentioned above, upstream default is subpixel like and not subpixel (cleartype) rendering actually.

It's not "not subpixel", "near subpixel" or "subpixel-like", it's proper subpixel rendering.

If you want to nitpick, then neither the free nor the patented implementation in FreeType work like ClearType does.

Just to confirm, you mean it's a proper subpixel rendering when FT_CONFIG_OPTION_SUBPIXEL_RENDERING macro is enabled?

You get proper subpixel rendering whether you enable the option or not.

I have to rebuild the package with the FT_CONFIG_OPTION_SUBPIXEL_RENDERING option enabled to make the display of fonts as I need, I hope someday it will be enabled by default.

What is the display of fonts you need?

Having tried a large number of combinations, I came to the conclusion that the best display of fonts on my monitor is achieved with the FT_CONFIG_OPTION_SUBPIXEL_RENDERING and truetype option enabled: interpreter-version = 38. Perhaps on high dpi monitors this is not necessary, but not all have such monitors. It would be nice to have two packages, with the option turned on and without it, so that everyone can choose what they need during the installation.

There will not be two packages for this.

AFAIK: The freetype2-cleartype package from AUR looks better when MS fonts are used (for Libreoffice etc). It looks about the same when Chrome OS equivalents are used.

I think the freetype2-cleartype package from AUR can be considered as superior, as it produces a result which shows less obvious colored pixels while the font appearing sharper (and thus better readable) at the same time. Imho it's safe to assume that this is what most users want when using subpixel font AA, so my opinion is it would be good practice to replace the freetype2 package of the official repository with the cleartype one.

FreeType contributor here.

Just to make it clearer, toggling FT_CONFIG_OPTION_SUBPIXEL_RENDERING does not lead to better or worse subpixel rendering (careful: "ClearType" is an umbrella/marketing term that differs in meaning depending on which Windows GUI toolkit you look at -- yes, Microsoft made more than one and they are all in use somewhere). If the #define is undefined, you get what its author dubbed "Harmony" rendering, which is essentially the same as toggling FT_CONFIG_OPTION_SUBPIXEL_RENDERING on and selecting the `lcdlight` LCD filter in fontconfig. I think the only way to tell both modes apart is to look for rounding errors in the resulting image. The Harmony "filter" is not configurable because it is essentially the lcdlight filter cast into code, trying not to do things in the way "ClearType" does them.

The "problem" with these different modes, or LCD filters, is that how well they work depends on the library drawing text on a surface in an application, your monitor (plus its calibration) and on your eyes. Correct text rendering is absolutely crucial to prevent color fringes. Do text rendering correctly and you will see very little color fringing! Sadly, only Qt5.9+ render text correctly, and only when rendering OTF fonts (*.otf). If the text rendering is done correctly, Harmony and FT_CONFIG_OPTION_SUBPIXEL_RENDERING + lcdlight lead to sharper text. I plan to at some point get back to working on FreeType to lay the foundation for correct text rendering for other toolkits and font formats...

With Nikolaus' comment and especially "Harmony "filter" is not configurable because it is essentially the lcdlight filter cast into code"
I'm for staying with our current configuration user being able to configure different LCD filters.

@heftig? Should we close this one "won't implement"?

@madigens Should we not use a filter at all with Harmony (example, set it to lcdfilter "none"). Or can we just leave the default lcdfilter?

The filter setting is ignored. In effect, you have something very close to "light".

What Jan said. I'd leave fontconfig's lcdfilter property to default either way in case anyone wants to enable FT_CONFIG_OPTION_SUBPIXEL_RENDERING. None would maybe lead to very ugly rendering in some toolkits.

@heftig I noticed that freetype2 2.10.3 currently in testing repo enables subpixel rendering!
Should I request the deletion of freetype2-cleartype (I maintain) on the AUR once this lands in extra?

So we ran with it enabled for 2 releases now and I think I'm going to disable it again. Apps and users can shoot themselves in the foot by configuring "legacy" filtering by accident (see  FS#68238 ), and that's not an issue when filters aren't configurable.

The issue is that the default filter seems to be legacy at least in some contexts (cairo?) if no configuration is specified. So another option could be shipping the lcddefault filter (or lcdlight) forcefully enabled, just like we have slight hinting enabled by default.

OTOH, I, for one, get exactly the same rendering with Harmony (FreeType default without ClearType), lcddefault and lcdlight, so it would not make a great difference (at least for me). And any other filter option is either borked (legacy and none) or require compiling FreeType yourself (custom filter, at which point you can also enable ClearType). But other might get different results with default and light (the latter being normally identical to Harmony).

My main reason to want ClearType enabled at this ponit, is to have one less package in AUR. ^^

I agree with Bruno: "another option could be shipping the lcddefault filter (or lcdlight) forcefully enabled".

Anyway, I submitted a deletion request for the AUR package and it was accepted. Another reason to keep ClearType enabled :D