Linux's font handling is undergoing a major change. In the past, Linux relied on X's native font-handling systems (known as X core fonts), but over time, these systems have become rather ragged. The solution is an entirely different font system, known as Xft.
Linux’s font handling is undergoing a major change. In the past, Linux relied on X’s native font-handling systems (known as X core fonts), but over time, these systems have become rather ragged. The solution is an entirely different font system, known as Xft.
Unfortunately, the transition from X core fonts to Xft isn’t without its problems. Linux distribution designers have done their best to insulate users from the travails, but if you’re an experienced Linux (or Unix) user who’s used to X core fonts, Xft is still likely to be confusing. Adding fonts in the old way won’t work for many newer applications, so knowing how Xft works is critical.
Xft Font Improvements
Xft requires that applications be written to use Xft fonts. For this reason, installing fonts in Xft will not make them available to older applications, and installing fonts in the X core system doesn’t make fonts available to Xft-only programs. (If an application can use both Xft and X core fonts, of course, installing the font in either location does the job, but the font may look different depending upon where it’s installed.)
X’s core fonts and Xft can both handle various bitmap formats, PostScript Type 1 fonts (also known as ATM fonts), and TrueType fonts. (Until version 4.0, XFree86 didn’t support TrueType fonts natively, though.) Thus, X core fonts and Xft have similar formats, but Xft generally delivers better looking fonts.
X core fonts and Xft vary in terms of where they’re rendered. With X core fonts, the fonts are handled by the X server — that is, they’re server-side fonts. With Xft, the fonts are handled by the clients (via the Xft libraries with which they link) — they’re client-side fonts. This distinction has few consequences for a typical workstation that’s used from its own console, but it can be important if you run X programs remotely. In that case, you must configure X core fonts on your local X server (that is, the computer at which you sit), but configure Xft fonts on the X client (the computer that’s actually running the program you’re using). Depending upon your needs, this distinction can simplify or complicate configuration.
Xft also lets individual users add fonts to their home directories. This can greatly simplify font configuration for individual users who aren’t system administrators.
Windows and Mac OS have long supported font smoothing (or anti-aliasing), a technique where the outlines of letters are deliberately blurred by using gray pixels rather than just black and white pixels. The XFree86 core font system doesn’t support font smoothing, but Xft does. (Figure One shows the same letter rendered with and without font smoothing.)
Figure One: Font smoothing creates a blurred font border, improving legibility at high screen resolutions
X core fonts are also largely insufficient for printing. Applications can’t go to X to obtain a single font for both display and printing use. X also doesn’t provide some font size information that’s necessary for precise character spacing, as used by word processors, page layout programs, and the like. Xft improves on some of these matters, but not all of them. In particular, although Xft provides improved font-spacing information to applications, it doesn’t provide tools to integrate font delivery to printers. Fortunately, other tools, including libraries that ship with Qt, help to provide this integration.
Font System Options for Applications
Most modern X-based applications now support Xft fonts. Many continue to support X core fonts, as well. Some programs, though, don’t yet support Xft. This fact can result in configuration complications and confusion if you don’t understand how applications are finding their fonts.
To further complicate matters, some applications bypass both X core fonts and Xft to render fonts. Some of these programs, such as OpenOffice, use the same FreeType libraries upon which Xft is based. Others use completely unrelated systems for rendering fonts.
In most cases, you can learn whether or not a program uses Xft by examining the list of dynamic libraries it requires, as revealed by ldd. Type ldd followed by the name of the program, as in ldd /usr/bin/konqueror. The result is a series of lines summarizing the dynamic libraries the executable you’re examining uses. If the program supports Xft, the libXft library should be in the list:
libXft.so.2 => /usr/X11R6/lib/libXft.so.2
You may also see other related libraries, such as libfreetype and libfontconfig.
A few programs are compiled statically, so this test won’t work with them; for those, ldd reports that the program isn’t a dynamic executable. If you do see a list of libraries and libXft is not among them, chances are the program doesn’t use Xft. It may use X core fonts or its own, custom font system.
Editing the Global Xft 2.0 Configuration File
In 2004, most distributions ship with Xft 2.0 or later. This version of Xft uses an entirely different configuration file from the older Xft 1.1 and earlier revisions. In particular, Xft 1.1 and earlier used a file called /etc/X11/XftConfig, whereas Xft 2.0 and later rely upon a file called /etc/fonts/fonts.conf and often a local configuration file called /etc/fonts/local.conf. Look for all of these files on your system. If XftConfig is present, you’re using Xft 1.1 or earlier; if fonts.conf is present, you’re using Xft 2.0 or later. Because the most recent Linux distributions use Xft 2.x, that’s the version we’ll focus on here.
The /etc/fonts/fonts.conf and /etc/fonts/local.conf files are actually XML files, so if you’re familiar with XML, you should be at an advantage. If not, don’t worry: tweaking your font configuration doesn’t require extensive knowledge of XML. These files belong to a subsystem called fontconfig, whose job it is to locate fonts, perform font name substitutions, and help determine which fonts are required for particular languages. In theory, you can make changes to either /etc/fonts/fonts.conf or /etc/fonts/local.conf; however, the fonts.conf file might be overwritten if you upgrade your fontconfig subsystem, so as a general rule, you should edit local.conf whenever possible. If you don’t, be prepared to duplicate your changes should you upgrade fontconfig.
Adding System-Wide Xft Fonts
One of the most basic changes you can make to your font configuration is adding fonts. To do so, you must first install fonts in a directory of your choice. Suppose that you’ve bought a font CD-ROM and you want to use some or all of the fonts from that package. Xft (and X core fonts, for that matter) can use TrueType and Type 1 fonts in the formats that are preferred for Windows systems — .ttf files for TrueType, and .pfb or .pfa files for Type 1 fonts. Type 1 fonts often come with additional files (.pfm, .afm, and sometimes other files). Xft doesn’t need these files, but copying them over won’t do any harm.
You should copy your TrueType or Type 1 font files to a directory of your choice. Creating a directory in /usr/local or /opt for such installations (say, /opt/fonts) works well and keeps the fonts you install separate from your distribution’s standard fonts. You may also want to create separate subdirectories for fonts in different formats (/opt/fonts/TrueType and /opt/fonts /Type1, say) or for different styles of fonts (/opt/fonts/serif and /opt/fonts/sans-serif, for instance). Creating subdirectories enables you to easily add and remove the fonts from your configuration, or give users control over which fonts they want to use. When you’ve copied the fonts to the new directory, you can add a line like the following to your /etc/fonts/ local.conf file:
In local.conf, this line must appear between the <fontconfig> and </fontconfig> lines. Be sure not to place the line within a comment, which is a line or block of lines that begins with the string <!–> and ends with the string <–>. A good place to add the directory specification is a new line just before the </fontconfig> line.
In Xft 2.x, adding a directory such as /opt/fonts to the configuration file automatically adds its subdirectories, such as /opt/fonts/ TrueType. Thus, if you want to use subdirectories, you need only specify the parent of all the subdirectories. On the other hand, specifying the subdirectories individually gives you greater control: you can go into the configuration file to remove just one subdirectory if there’s a problem. You can also add some directories system-wide and leave others as optional additions for your users.
After you’ve saved your changes, the fonts should become available to ordinary users, as described shortly. If you do nothing more, though, user applications will trigger fontconfig to scan the font directories and create index files in users’ home directories. This task may cause delays the first time users run an Xft-enabled application after you make changes. To avoid this problem, type fc-cache, optionally followed by the path to the directories you want scanned. This action creates the font index files (called fonts.cache-1) in each font directory you created.
Tweaking Xft Behavior
You can do more than just add fonts using Xft. For instance, most Linux distributions ship with font smoothing enabled by default. If you don’t like font smoothing, though, you can disable it by adding lines like this to /etc/fonts/local.conf:
If you’re using a computer with an LCD monitor, you may want to enable a feature called sub-pixel rendering, which is a way to improve the legibility of fonts on an LCD screen. The configuration to enable it resembles the one used to disable font smoothing, but with some important differences:
If you examine the fonts.conf file, you’ll find a number of sequences that set up font aliases. These are instructions to fontconfig to substitute one font for another. Some aliases are designed to provide substitute fonts in case an application asks for a font that’s not present on the system. One particularly important set of aliases defines the fonts that may be used for the Serif, Sans-Serif, and Monospace families. These aliases look something like this (but are typically longer):
<family>Nimbus Roman No9 L</family>
<family>Bitstream Vera Serif</family>
This definition tells fontconfig to deliver the Nimbus Roman No9 L font as the default serif font, but to fall back on Bitstream Vera Serif if the preferred font is missing entirely or if it’s missing a character. (These lists may hold a dozen or so entries so that the system can fall back on an appropriate font when rendering text with non-ASCII symbols.) You can change the order of these fonts if you like. For instance, you can move Bitstream Vera Serif up in the list to make it the default. You can also add fonts you’ve installed to the list, if you’d rather use one of them.
Configuring Fonts as a User
Most /etc/fonts/fonts.conf files include a line that loads the contents of the user’s ~/.fonts.conf file, if it’s present. This line enables ordinary users to make changes to their font configurations by editing this file just as the system administrator can edit /etc/fonts/local.conf.
Because features such as preference for or against font smoothing are very subjective, this feature can be very handy, but it requires users to understand the font configuration file format, at least to a small extent.
Merely adding fonts is a bit simpler: most /etc/fonts/fonts. conf files include a font directory listing for ~/.fonts. This entry tells the system to use fonts stored in the .fonts subdirectory of a user’s home directory. The result is that users can install fonts merely by copying them to their own fonts subdirectory. When users run Xft-enabled programs, those programs will cause fontconfig to generate an index file called ~/.fonts. cache-1, which holds information on the fonts in the ~/.fonts directory, as well as in any system font directories that haven’t been properly indexed.
Some GUI font configuration tools, such as the font installer provided with KDE, edit the user’s ~/.fonts.conf file so that it points to font directories unique to the font installer. In the case of KDE’s font installer, the directory is ~/.kde /share/fonts, with subdirectories for TrueType and Type 1 fonts.
Once you’ve installed fonts or changed your font configuration, it’s time to run some tests. You can do this by running any Xft-enabled program that supports arbitrary font selection.
To check basic font installation, try the GNOME Font Preferences tool, which you can launch by typing gnome-font-properties in an xterm. (You don’t need to use GNOME as your default environment to use this program.) The tool is designed to set GNOME’s default fonts, but it loads fairly quickly and enables you to see what fonts are installed, which makes it handy for testing font installations.
Figure Two: Font picker utilities can be good ways to test for successful installation of a font
Click on any of the font name buttons near the top of the window and the tool displays the “Pick a Font” dialog box, shown in Figure Two. You can use this dialog box to determine whether a font’s been properly recognized by the system and whether the font smoothing settings are as you desire. You can also select the Serif, Sans Serif, and Monospace font names to see what actual font is called. (The tool won’t display the name, but if you’re familiar with the font you want, you should recognize it.)
If something’s not working as you expect, exit from the program and look for error messages in the xterm you used to launch gnome-font-properties. You might also examine the ~/.fonts.cache-1 file and the fonts.cache-1 files in your system font directories to see if you can find references to the font. Sometimes a font will appear under an unexpected name, or a defective font won’t be picked up at all.
Once you’ve configured your fonts, you can begin using them in your Xft-enabled programs. Older programs are unlikely to support Xft, though, and many word processors still use their own font rendering systems, although Xft is beginning to be used even by word processors.
Roderick W. Smith is the author or co-author of tweleve books, including Advanced Linux Networking and Linux Power Tools. He can be reached at email@example.com.
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62