KDE/Freetype antialiased font rendering.

[Sivar]

I very much like the antialiasing features of KDE as it makes fonts look vastly better than they do without...

...However, it seems that the font rendering could be a bit better. Now, I am no expert at font rendering, and I am sure that the powers that be (the programmers) know far more than I do and that there is probably a technical or legal reason thus far for the following problem (Adobe patent?), but I do have a comment:

Antialiased fonts rendered in X look as though they were antialiased using supersampling. I am probably oversimplifying things greatly, and font rendering uses many methods (hinting, for example), and supersampling does look great for some things, such as 3D games. For fonts, however, supersampling makes fuzzy and blurry parts of the font that should be entirely left alone. Example:

If you have a simple capitol letter "E"; one that has no curves but JUST straight vertical and horizontal lines making up the letter, its appearance should not be changed by the font AA engine. Antialiasing should only be performed on the edge of curved areas, such as the rounded part of the letter "P"
AA rendering in X, however, seems to apply filtering to the straight areas of characters as well. For example, as I type this, the right-most pixel of the lower case letter 'l' (lower case 'L') is an average of the white background and the black letter, thus making it dark gray rather than completely black.
This may not seem like a big deal at all, and the font rendering does still look very good, but it does make a difference when one stares at a monitor for a long time and when one needs sharp, clear letters (for example when the letters are small or very tightly packed)
Turning AA on has an effect vaguely similar to having a cheap monitor or a second-order lowpass filter (instead of a fourth or fifth) on a video card, like cheap RAMDAC setups do. It isn't quite as destructive to image quality, but it has similar blurring consequences.

Now, I read a while back when I was researching font antialiasing that Freetype was force to use an inferior method for rendering fonts because of a patent held by Adobe. I do NOT know if this rendering method or the patent by adobe have anything at all to do with the antialiasing problem that I am speaking of. I also read that a small modification to the source code could be made to use the better method, which would of course require a license from Adobe to use.
Does anyone know:

1) If this rendering problem is happening because of a mistake of mine or because the rendering is not yet mature.

2) What that source code modification is, and where one can contact Adobe for such a license

3) Any ideas or solutions/comments/notes about any of this.

I am using all TrueType and OpenType fonts when I can, I have many extra fonts installed, I have manually reemerged the latest version of Freetype and have done all the little tips floating around for fixing unrelated font problems, not because I am experiencing that problem but to see if the fix improves overall rendering.
Thanks for any comments.
_________________
The greatest deeds are still undone, the greatest songs are still unsung...

[474]

The patents are held by Apple, read this interesting page: http://www.freetype.org/patents.html. Yes, Apple designed and implemented TrueType, not Microsoft or Adobe! Your are correct in your assertions as far as KDE anti-aliasing goes.

First, read some posts I made before (just because you might find some items of interest, and you should see them before what I am going to say below!).

https://forums.gentoo.org/viewtopic.php?t=2233
https://forums.gentoo.org/viewtopic.php?t=3828

Secondly, I don't think re-emerging freetype is going to make any difference. X compiles Freetype statically from source code that is is bundled with the X tarballs - so, it's independent from your freetype build. It uses freetype 2.0.6, except for XFree 4.2.0-r11 which now uses freetype 2.0.9. Having said that, I am not sure how the KDE anti-aliasing mechanism fits into everything else. I presume that turning it on means that it employs the direct render extension (libXft to be precise) in its capacity to render anti-aliased fonts.

Thirdly, as I'm sure you know, the big fuss about Truetype rendering and the patent issue in lieu of freetype concerns the use of the bytecode interpreter option. Gentoo automatically ensures that the macro is enabled before compilation in the case of standalone freetype and the X bundled one. When it is not enabled, auto-hinting is used which isn't supposed to be as good in terms of hinting the glyphs and rendering the fonts at small sizes. Now here's the funny thing: it's been reported that you get better results using methods which have nothing to do with it. Well, specifically: a guy called David Chester patched libXft, calling it the "Xft-slight" patch). This does not make use of the bytecode interpreter, but for best results the auto-hinter should be on. And guess what? It really does seem to look way better! My tests went well (I manually extracted the i586 pre-compiled libXft from his tar.gz just to test it, rather than patch and recompile X and freetype ). Comments on the MandrakeForum were in favour of it also. I suggest you go and check his site, and look at the examples. On one of them, you can clearly see that the unpleasant blurring effect on straight lines is not there, or at least nowhere near as pronounced. The kerning and sizing of the characters also seems to be much better

http://www.cs.mcgill.ca/~dchest/xfthack/

Even better, he is working on moving the patch into freetype itself. According to him: