Gentoo's lcdfilter repository hasn't been updated in months, and I see that infinality patches are now part of Gentoo's main portage tree. Therefore, I strongly suspect that the lcdfilter ebuilds have reached their end of life. If they have, then my lcdfilter SlackBuilds, which are ports of them, will need to be retired.

Fortunately, Kabamaru's packages, which you can get at someslack, are still being updated and have a FreeType 2.4.11 package available.

Thanks for the redirection. Will have to figure out how to transition from yours to Kabamaru's... is it safe to leave your cairo package alone?

His packages are clearly meant to be used with Slackware's stock Cairo. I would use them as intended.

I use Salix OS
I put patches for freetype and Cairo

Ftp://elektroni.phys.tut.fi/slackware64-current/source/l/freetype/ )
Ftp://elektroni.phys.tut.fi/slackware64-current/source/l/cairo/ )

Please tell me, why now impose no on libXft patches?
Here, too, there is no patch for download
Ftp://elektroni.phys.tut.fi/slackware64-current/source/x/x11/src/lib/libXft-2.3.1.tar.xz

Because the contents of the patch have been merged into the source code of libXft since version 2.3.0. So the patch is no longer needed.

Thank you very much, Daedra !

I put the patches оn freetype freetype-2.4.10 and cairo cairo-1.10.2
after
ln -s /etc/fonts/conf.avail/10-sub-pixel-rgb.conf /etc/fonts/conf.d/
rm /etc/fonts/conf.d/30-urw-aliases.conf
rm /etc/fonts/conf.d/30-metric-aliases.conf

has created
~/.Xresources
Xft.dpi: 101
Xft.antialias: true
Xft.hinting:true
Xft.autohint: false
Xft.hintstyle:hintslight
Xft.rgba: rgb
Xft.lcdfilter: lcddefault
XTerm*background:black
XTerm*foreground:white
XTerm*faceName: Terminus:antialias=False:pixelsize=14

Great result!
http://photoload.ru/data/df/fb/e0/df...6714cfef82.png

Freetype and cairo I locked for update. ( Salix OS 14)

But in the list of updates, I see Freetype 2.4.11 with ClearType
However ( аs I understand ? ) ClearType support is not completely implemented

Yup looks good :), you can use the same patches from freetype 2.4.10 to patch up 2.4.11. The freetype patches aren't really version specific in this case. Any yes the reason why subpixel rendering and other such technologies aren't fully enabled by default is because they are patented by Microsoft. Just like the bytecode interpreter used to be patented by apple, but that patent expired so now its enabled by default.

I would like to put patches Сlear Type in Debian Wheezy (testing)
Is it possible?

Are you going to update your FreeType (lcd-filter) patch to 2.4.11?

No.

But I'll be updating my guide to replace references to them with references to Someslack soon.

That was quick, thanks. Actually I'm not too happy with infinality. For example, I tried to use Monaco font in Terminal (Xfce4) and it looks as if some part of line is chopped off ending up with some characters missing. I think I might have to re-install infinality. I'll be able to come back with some screenshots.

What are you using for your fonts now?

Infinality. From SomeSlack.

Adobe Source Sans Pro is my "Sans" font and Adobe Source Code Pro is my "Monospace" font.

Monaco looks quite decent on my setup (default Infinality). Although this is subjective.

Sorry, my Terminal (Xfce4) is fine with Monaco but it's my KDE. I use alienBob's KDE 4.10.5 with default infinality patches on my Slackware64-14.0. I'm pretty sure it's something to do with Konsole.

I can reproduce the bug, on a vanilla (non Infinality) Slackware 14.0 virtual machine. So this is some kind of a KDE/Konsole bug.