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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide