The Xft library provides support for [antialias]ed TrueType [font]s, full [Unicode], and an unbraindamaged font selection mechanism for X11. It relies on fontconfig [http://www.fontconfig.org], FreeType [http://www.freetype.org], and the X Render extension (although it will still work if XRender is not available on the server). Xft 2.0 is included in most recent Linux distributions (circa May 2003). Mozilla, Qt, and GTk have all been updated to use Xft. Experimental support for Xft in Tk 8.5 has been committed to the CVS HEAD (31 May 2003). See also patch #535541 [http://sourceforge.net/tracker/?func=detail&aid=535541&group_id=12997&atid=312997]. There are still (31 May 2003) a few quirks and bugs to be worked out, but overall it works pretty well. To enable Xft support, run: sh ./configure --enable-xft make clean make Many thanks to Keith Packard for contributing the original code. Blame [Joe English] for the stuff that doesn't work right yet. ---- [KPV] I for one don't particularly like antialiased fonts--I find them fuzzy and hard to read. ''Joel on Software'' essay ''Three Wrong Ideas From Computer Science'' [http://www.joelonsoftware.com/articles/fog0000000041.html] talks about the fallacy of antialiased fonts. [JE] Note that Joel constructed the "evidence" that antialiased fonts look bad by taking a screenshot of text in a bitmapped font and running it through Corel PHOTO-PAINT. This is like using Turner's colorized version of ''The Maltese Falcon'' to demonstrate that black and white movies are superior. If the antialiasing is done by the font rasterizer (where it's supposed to be done), the results are much better. [IDG] I don't like them either. But then, I don't like syntax-colouring editors, so I'm clearly a weirdo! [DKF]: I think he's not quite on the ball over AA fonts. More exactly, non-AA fonts are great if you require a font of exactly the size they provide (often the case for GUIs where font sizes can be controlled fairly well) but are awful if you're after some other size of font and the system has to fall back on its own rasterizer. (Previewing printable documents is one of the cases when you'll probably hit this problem.) [JH] Some systems provide controllable lower boundaries for the use of AA fonts, which is the best solution. Small text is crisp while larger text gets AAed. OS X provides this for sure, but perhaps there is a way to allow better control for this on the unix side in Tk? AKA: You guys are so totally wrong it hurts. Any screen design that uses pixels as a design element is flawed. Pixels are artefacts. Sane screen should try to hide the fact that (todays) screens are pixelized. For paper output, this happened when 300 dpi printers got affordable, ca. 1988. With LCD screens, we're at 150 dpi now and should really forget about pixels RSN. [DKF]: FWIW, I'm happy to let the system pick whether to AA a font or not. With higher res screens of at least 24-bits deep, it's no longer a major issue. [JAC]: Re: "controllable lower boundaries". Xft takes care of deciding whether or not to AA a font. This can be controlled in the fonts.conf which is found in /etc/fonts/fonts.conf or ~/.fonts.conf on my Debian system. AFS: people, I can commiserate with you if you don't like AA fonts, but at least we should have the choice. I can assure you that for me it's a real problem to work with tcltk text processing applications (for the rest I don't care). [Jasp] Blurry AA is only a problem if you are using a font without good hinting instructions, otherwise, it's no doubt alot better than un-AA, IMHO. Take this screenshot for example: [http://www.lostagain.org/images/offworld/aa-firefox.png] (16-bit colour, Ubuntu Dapper). The window titlebar font is Trebuchet MS, interface is Segoe UI, webpage is Bitstream Vera Sans with font size turned right down. Notice the active tab is bold and also blurry?, that's because there isn't a bold version of Segoe available, so the font renderer has generated the bolded effect by horizontally resizing the original, losing it's sharpness. Almost all fonts suitable for interface use come with a bold version, so that usually doesn't happen (as you can see in the titlebar). Also notice that the AA Bitstream Vera still looks good when small, especially the italic text, which while is a bit blurryish, I prefer over blockly un-AA italic. So anyway, I think it's about time AA support on X has been added to Tk, since the current un-AA rendering on X doesn't even appear to look at hinting instructions, and the result is messy blockly text, on 99% of fonts. (Tk just seems to be playing a game of "catch-up to the other toolkits" these days to me). --- [TJE]: Who can fix this in the configure script? The current source trees (as of 26 Sep 2005) don't 'configure' properly with --enable-xft, at least on Redhat Enterprise. The Xft library is part of the standard installation, and there's no 'xft-config' executable to be found. I managed to get 8.5a3 to build by adding '-lfreetype -lXft' to the 'wish' link line, as well using the output of 'freetype-config' to add the freetype library to the compile line for tkUnixRFont.c (which must be substituted for tkUnixFont.c in the Makefile). Even if you're in the "I hate anti-aliased fonts" camp, this is still a desirable improvement, as it fixes the '''shape''' of the font as well, not just the jaggy edges. (Try comparing a 'T' in Courier at size 150, and you'll see what I mean.) [IDG]: I had no trouble with --enable-xft on Suse 9.3, using a July 05 source distribution. You are certainly right about shape. Recent versions of X look worse than older ones, if you don't have xft enabled. [TJE]: Hmm. I just configured/compiled with Xft on an Opteron running Redhat Enterprise without a single hitch, so I guess the problem is limited to my 32-bit Intel box's configuration. Odd. [DLR] Make sure you have the development version of the libraries installed ---- [Category Discussion]