Is Beauty Only Pixel Deep?, Part 1
Hello, everyone, and welcome back to the SysAdmin's Corner. If it seems like I've been away, it's because I've been away--seventeen days in Europe learning to love espresso and finding out that old is simply a matter of perspective. When they talk about an old building in Europe, they aren't talking century homes, but four or five century homes. And thank you for asking; I had a fantastic time there (nothing like a gondola ride in the pouring rain). Maybe I'll show you some pictures some time.
I run a quiet little mailing list on my server where people talk about Linux, life, the universe and anything else that sounds like it might run on their systems. One of the topics that crops up from time to time (and which cropped up a few days ago) is that of fonts. It seems that fonts under Linux represent one of the great bugaboos of working in the Linux environment. There's a mystique around fonts as though something magical is happening, something that is better left untouched for fear of angering the X gods. Even seasoned Linux users tread lightly around this topic: Warning! Here be monsters.
The real problem with fonts under Linux (under X actually) is the many different ways of handling fonts, not to mention different font types. We have both bitmap and outline fonts; which further break down into Speedo fonts, portable compiled fonts, Type1, TrueType, ghostscript fonts and others. This is one place where "more than one way to do it" hasn't paid off.
In this recent discussion, somebody wanted to remove some particularly ugly fonts from their system. While that seems simple enough, where are these fonts? What do they look like? How do you add or remove them? Do we even know what fonts are already installed on our systems? All good questions. Now, you might think that you don't have a lot of fonts installed on your system, and you'd be surprised at how much is really there. Try the xlsfonts command and you'll know what your X server knows.
$ xlsfonts -adobe-courier-bold-i-normal--0-0-0-0-m-0-iso8859-1 -adobe-courier-bold-i-normal--0-0-0-0-m-0-iso8859-2 -adobe-courier-bold-i-normal--0-0-0-0-m-0-iso8859-3 -adobe-symbol-medium-r-normal--34-240-100-100-p-191-adobe-fontspecific -adobe-symbol-medium-r-normal--8-80-75-75-p-51-adobe-fontspecific -adobe-symbol-medium-r-normal--8-80-75-75-p-51-adobe-fontspecific -adobe-times-bold-i-normal--0-0-100-100-p-0-iso10646-1 -adobe-times-bold-i-normal--0-0-100-100-p-0-iso8859-1 -adobe-times-bold-i-normal--0-0-75-75-p-0-iso10646-1 -adobe-times-bold-i-normal--0-0-75-75-p-0-iso8859-1
The output you see above is actually only a small excerpt of the output from running the command on my system. If I pipe the output of the command to wc -l ( xlsfonts | wc -l ), I get 2907 lines. Consequently, you might want to pipe that output to more or less. Let's take that first line and inspect it--what does all this mean?
This method of identifying fonts is called the X Logical Font Description. Each part of the description is delimited by hyphens to make it somewhat easier to read. The first part (in this case, adobe) is the foundry. Essentially, this tends to be who is responsible for creating the font; you could see things like bitstream, xfree86, urw, dec and others here. The next is the font family, things like times, courier and so on. Then we have the weight for the font. Is is bold, light, semi-bold or something else? The single letter that follows is the slant; "i" for italic, "r" for roman, or "o" for oblique. It goes on from there with stretch, style, pixel, points and more. Unless this is really your thing, you might start to go mad at this point. Instead, why not fire up the xfontsel program? It's part of the XFree86 tools package.
If you click on any of the font descriptors (fndry, fmly, slant, etc), the display will update with the number of available fonts that fit that profile. Then you can specify other parameters and narrow the list further. The bottom part of the window lets you see what the fonts look like. Other than let you play with descriptions and tailor a font, the utility doesn't really do anything else. Nevertheless, it is still a good way to get a feel for how these descriptions are put together.
Moving, on, the location of these fonts will vary, although most of them tend to live under the /usr/X11R6/lib/X11/fonts hierarchy. Each directory that contains fonts is made known to your X Window System. It used to be that there were FontPath entries in the XF86Config file that looked something like this:
Section "Files" FontPath "/usr/X11R6/lib/X11/fonts/75dpi"
There would be a line for each of the font directories on the system. Most of you, however, will be running a newer system with some version of XFree86 4.X, and your XF86Config file might be called XF86Config-4. There, the only FontPath entry you're likely to find is this:
What that means is that you are running the X Font Server. "Font server", you ask? "What is this font server?" With recent XFree86 implementations, you'll find the xfs package included. You've most likely installed X when you first set up your system, but should you ever want to pick up the latest and greatest X server from XFree86.org, xfs can be found in the Xfsrv.tgz bundle. The server has another very nice feature. When you start (or restart) the server, it takes care of regenerating the font list, and it handles all this strange font business.
To list the font paths known to your server, you can check its configuration at /etc/X11/fs/config. This is a text file editable with your favorite editor. Here's a sample from the file that describes the various places fonts can be found on my system.
# catalogue = /usr/X11R6/lib/X11/fonts/misc:unscaled, /usr/X11R6/lib/X11/fonts/75dpi:unscaled, /usr/X11R6/lib/X11/fonts/100dpi:unscaled, /usr/X11R6/lib/X11/fonts/Type1, /usr/X11R6/lib/X11/fonts/Speedo,
Note that this is only part of the file that describes the font "catalogue". The order on your system may vary from mine (because I've been mucking about with mine). Alternatively you can use the chkfontpath command on a number of different Linux distributions including Red Hat, Mandrake, SuSE and others.
Here's what I get when I run it on my much abused Red Hat notebook.
Current directories in font path: 1: /usr/X11R6/lib/X11/fonts/misc:unscaled 2: /usr/X11R6/lib/X11/fonts/75dpi:unscaled 3: /usr/X11R6/lib/X11/fonts/100dpi:unscaled 4: /usr/X11R6/lib/X11/fonts/misc 5: /usr/X11R6/lib/X11/fonts/Type1 6: /usr/X11R6/lib/X11/fonts/Speedo 7: /usr/X11R6/lib/X11/fonts/CID 8: /usr/X11R6/lib/X11/fonts/75dpi 9: /usr/X11R6/lib/X11/fonts/100dpi 10: /usr/share/fonts/default/Type1 11: /usr/share/fonts/ja/TrueType 12: /usr/share/AbiSuite/fonts
You can use the same command (chkfontpath) to remove and add fonts. Specifically, if you wanted to remove the AbiSuite font path, you would type:
chkfontpath -r /usr/share/AbiSuite/fonts
On older versions of X, you would add (or remove) a font path with the xset command. Let's say I wanted to add the path to a new font directory called "newfonts":
xset +fp /path_to/newfonts
Then we need to have X recognize the new fonts.
xset fp rehash
You can also restart the font server at this point.
service xfs restart
The beauty of the chkfontpath command is that it greatly simplifies this whole process. If you've got it, I recommend that you use it. Now, let's get back to my AbiWord fonts for a moment. If I try to start up AbiWord at this point, it will complain that its fonts are missing. To get things working properly again, I repeat the command with the -a option on chkfontpath. AbiWord now starts happily.
My allotment of electrons has pretty much run out for today, so I'm going to stop here. Consider this final thought: if you are like me, you've got thousands of font files from packages you've purchased going back many years. What about using some of those old fonts in your applications? How can you convince your system to use one set of fonts over another? How does it decide? All these questions and more will be dealt with next time we meet on this very Corner.
In the meantime, remember that beauty is more than pixel deep.
Marcel Gagné's book, Linux System Administration; A User's Guide (ISBN 0-201-71934-7, Addison Wesley) is in stores now (including your favorite on-line vendor). You can download a free excerpt from his web site.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- Home Automation with Raspberry Pi
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development