Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#60658 - [freetype2] Enable Cleartype by default now that MS has joined the OIN

Attached to Project: Arch Linux
Opened by Alexandre Demers (oxalin) - Wednesday, 31 October 2018, 13:44 GMT
Last edited by Jan Alexander Steffens (heftig) - Wednesday, 31 October 2018, 14:12 GMT
Task Type Feature Request
Category Packages: Extra
Status Assigned   Reopened
Assigned To Jan de Groot (JGC)
Andreas Radke (AndyRTR)
Jan Alexander Steffens (heftig)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 9
Private No


Cleartype Subpixel rendering is disabled by default in Freetype2 because of legal concerns. Users must rely on Freetype2-cleartype to have this feature enabled.

However, now that Microsoft has joined the Open invention network (OIN), bringing over 60000 patents with it, it seems possible to enable cleartype without risking any legal action. In fact, Fedora is enabling the feature exactly because of Microsoft joining the OIN.

See this news:

This task depends upon

Comment by Jan Alexander Steffens (heftig) - Wednesday, 31 October 2018, 13:56 GMT
Subpixel rendering is already enabled. There's nothing to do.
Comment by Bruno Pagani (ArchangeGabriel) - Wednesday, 31 October 2018, 14:12 GMT
  • Field changed: Percent Complete (100% → 0%)
Comment by Jan Alexander Steffens (heftig) - Wednesday, 31 October 2018, 14:13 GMT
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.
Comment by Peter Weber (hoschi) - Wednesday, 31 October 2018, 14:45 GMT
Dear Microsoft, thank you for nothing. Correct?
Comment by Bario (barmadrid) - Friday, 09 November 2018, 20:23 GMT
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.
Comment by Jan Alexander Steffens (heftig) - Friday, 09 November 2018, 21:33 GMT
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.
Comment by Bario (barmadrid) - Friday, 09 November 2018, 22:34 GMT
Just to confirm, you mean it's a proper subpixel rendering when FT_CONFIG_OPTION_SUBPIXEL_RENDERING macro is enabled?
Comment by Jan Alexander Steffens (heftig) - Friday, 09 November 2018, 23:14 GMT
You get proper subpixel rendering whether you enable the option or not.
Comment by Mikhail Vorobyev (Mikhail) - Friday, 18 January 2019, 09:19 GMT
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.
Comment by Jan Alexander Steffens (heftig) - Friday, 18 January 2019, 09:26 GMT
What is the display of fonts you need?
Comment by Mikhail Vorobyev (Mikhail) - Tuesday, 22 January 2019, 15:54 GMT
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.
Comment by Jan Alexander Steffens (heftig) - Tuesday, 22 January 2019, 18:33 GMT
There will not be two packages for this.
Comment by Dimos Dimoulis (dimosd) - Saturday, 26 January 2019, 11:54 GMT
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.
Comment by Dietrich Hallentforden (aufkrawall) - Thursday, 07 March 2019, 21:27 GMT
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.
Comment by Nikolaus Waxweiler (madigens) - Wednesday, 20 March 2019, 21:53 GMT
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...
Comment by Andreas Radke (AndyRTR) - Wednesday, 11 December 2019, 12:44 GMT
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"?
Comment by Bario (barmadrid) - Wednesday, 26 February 2020, 16:28 GMT
@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?
Comment by Jan Alexander Steffens (heftig) - Wednesday, 26 February 2020, 18:35 GMT
The filter setting is ignored. In effect, you have something very close to "light".
Comment by Nikolaus Waxweiler (madigens) - Wednesday, 26 February 2020, 19:48 GMT
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.
Comment by Bario (barmadrid) - Monday, 12 October 2020, 18:17 GMT
@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?
Comment by Jan Alexander Steffens (heftig) - Friday, 23 October 2020, 14:41 GMT
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.
Comment by Bruno Pagani (ArchangeGabriel) - Friday, 23 October 2020, 14:53 GMT
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. ^^
Comment by Bario (barmadrid) - Monday, 16 November 2020, 22:19 GMT
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