Is Beauty Only Pixel Deep?, Part 1

Getting to know your fonts.

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.

Typing

     xfontsel &

gives you

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:

     FontPath "unix/:7100"

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.

     $ /usr/sbin/chkfontpath

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.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

the quote should be here be dragons, or even better: hic sunt dracones...

And as ye would that men should quote you, quote ye also them likewise

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

I have to express my agreement with the above posters' responses. The way Linux GUIs handle fonts is, to say the least, disappointing.

Being a Linux newbie myself, I tried out Mandrake Linux 8.0 last year and came away with the impression that "desktop Linux" really isn't a reality (yet). The quality of the KDE & GNOME window managers was both heartening and disappointing. Heartening in that the open-source community has created GUIs are just as slick looking as Windows and OS X. Disappointing because both GUIs are slow bloated behemoths that make Win98 and above seem svelte and blindingly fast.

But I digress. Regarding my font experience, I was only able to get TT fonts to properly render in KDE when I reinstalled Mandrake and left out the installation of AbiWord. Once that was done and the proper checkbox selected to activate AA fonts (shouldn't it have been checked by default???), all was well in KDE. Except that ONLY KDE specific apps rendered fonts properly. TT fonts in StarOffice 5.2? Furgetit.

It's sad that a 10 year old GUI, Windows 3.1, can manage and render True Type fonts better. The situation would be much better if KDE/GNOME developers had not wasted energy on making purty GUIs with 10 zillion options to customize and instead tried to develop a solid GUI that wasn't saddled with X's problems and meet the modest goal of matching Win 3.1's level of ease of use and functionality.

Beauty may be more than pixel deep, but ugly goes down to the API.

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

Hehe you hit it where it hurts. I just installed Mandrake 9.0 on my system now and this fonts are so ***** ugly yuk ! And I'm a Linux noob crap !

Fonts in Distributions

Anonymous's picture

It's somewhat disappointing that most Linux distributions don't seem to bother including decent fonts, set up in a way such that text appears in a presentable fashion without the user having to mess with font paths and font servers. Alarmingly, it would appear that the classic "Linux expert" advice is to go to Microsoft's typography page, as the first step to remedy the problem, and download their fonts. With "bad fonts" as being one of the biggest problems with the Linux desktop (just read the threads on the KDE and GNOME news sites to see how even advanced users have difficulties with the topic), it's surely time that the distribution vendors added value in this area rather than bundling the same old dodgy fonts from the 80s (and screwing up the font configuration at the same time).

Re: Fonts in Distributions

Anonymous's picture

Part of the problem is bad hinting and bad rendering. I was amazed at how much better the existing fonts on my system looked when I switched over to using Xft.

Many of the Type1 fonts which looked very ugly when rendered as core fonts in X suddenly looked a lot better antialiased (less blocky, more rounded). This is partly because the antialiasing gives a higher "virtual" resolution, and partly because those fonts weren't hinted well (or maybe not hinted at all) for display at low resolution.

Re: Fonts in Distributions

Anonymous's picture

"Copyrights" are the problem. The pretty fonts are copyrighted. If Any Linux Distribution were to include them, then there would be a per seat license.

Re: Fonts in Distributions

Anonymous's picture

There is one reason for going to Microsoft to get fonts that is not going to be easily fixed. As long as web pages and documents specify fonts that come from Microsoft, and as long as the distribution conditions on those fonts don't allow packaging them in Linux distros, there are only two options. First, get the fonts from MS. Second, duplicate all of them in open source.

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

However, for beeing able to use truetype fonts, one still needs the "ttmkfdir" program, which itself requires freetype1 ?

At least, I haven't found out how to create the fonts.* files otherwise

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

Why can't X handle fonts like Windows? Dump all fonts in a directory (i.e. c:winntfonts) and they get loaded and are available to all apps automagically? Is it really that damn difficult or can't the X/*nix/others get their collective ***** together? Why isn't there an effort to make font installation and availability easier? I guess I can grab all the true-type fonts in the world and drop them into my fonts directory on Windows, but on linux it is a nightmare just trying to get them available. This is a big shitty thing I absoluttely hate. Take something that M$ does well and make it so damn convoluted and impossible for the average or even experienced person to do that all we hear is about ugly fonts on Linux. The font's are fine and with AA now, they even look good. Now let's see a well coordinated effort to create /usr/share/fonts and make it so I can drop any font file in there and it will *just work*. Is that not possible in the opensource world???

Xft

Anonymous's picture

This is being addressed with Xft. It doesn't worry about fonts.dir, fonts.scale, etc files. I just add a directory to the system wide XftConfig file or my user's ~/.XftConfig file and all my apps can see them (for Xft 2, the file names and formats are a bit different, as the font handling has been split into a separate library called fontconfig).

So I could easily create a ~/fonts directory, and when I dump fonts in there, they become instantly usable to all apps using Xft (which at the moment is all your KDE apps, all GNOME 2.0 apps, and mozilla if your build has Xft support).

There is even a plan to get X to use fontconfig to find the fonts for core X font rendering used by traditional apps, which would also mean that you only need to configure fonts for X once.

On top of this, the fontconfig library is not X specific, so in the future other parts of your system may get ported to use it (eg. the print subsystem, TeX, etc). There are a number of people working on this problem.

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

I guess the following is a nightmare?

copy your TrueType Fonts into a font directory such as /usr/share/fonts

cd /usr/share/fonts

ttmkfdir -o fonts.dir

chkfontpath --add /usr/share/fonts

service xfs restart

This would create your initial /usr/share/fonts

after that you can add more TrueType Fonts

just

cd /usr/share/fonts

ttmkfdir -o fonts.dir

service xfs restart

This will work on Redhat on other distros you may have to restart xfs some other way.

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

>> Is that not possible in the opensource world???

I guess this is something LSB (Linux Standards Base) or freedesktop.org will address, if not already.

To my knowledge, SUSE was awarded as being the most LSB-compliant last time they checked.

Now, unless I'm totally off here, Windows works easy because it only understands a few kinds like Truetype. For certain other kinds, it's very simple, too: it doesn't work.

I guess someone will eventually do, if not already, a front-end to xft such that you could drag-and-drop a font-file and it convert, install and rehash automatically. That's not too difficult for one versed in KDE or Gnome programming.

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

"I guess someone will eventually do, if not already, a front-end to xft such that you could drag-and-drop a font-file and it convert, install and rehash automatically. That's not too difficult for one versed in KDE or Gnome programming."

...

aren't there several of these already (after installing Mandrake 8.1, it has drakfont (it's frontend), as well as 1 or 2 others...isn't there a KDE version too?

...aren't these project already under development?

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

I guess this is something LSB (Linux Standards Base) or freedesktop.org will address, if not already.

*******

I don't think the LSB has anything to do with this, since it's a user-interface issue. LSB pretty much restricts itself to binary compatibility issues.

Re: Is Beauty Only Pixel Deep?, Part 1

Harlan's picture

Frankly Windows can't find fonts unless they are in the folder you mention. With Linux you may have a diskless terminal with no fonts of it's own, so the design is a little different.

You already can simply drag fonts into a folder and have them automatically added to your X font path and Ghostscript.

For example, here's a portion of Mandrake's startkde script that adds fonts from your $Home/.kde/share/fonts/override folder to Ghostscript and the X Font server every time KDE starts:

# Activate the kde font directories.

#

# There are 4 directories that may be used for supplying fonts for KDE.

#

# There are two system directories. These belong to the administrator.

# There are two user directories, where the user may add her own fonts.

#

# The 'override' versions are for fonts that should come first in the list,

# i.e. if you have a font in your 'override' directory, it will be used in

# preference to any other.

#

# The preference order looks like this:

# user override, system override, X, user, system

#

# Where X is the original font database that was set up before this script

# runs.

usr_odir=$kdehome/share/fonts/override

usr_fdir=$kdehome/share/fonts

if test -n "$KDEDIRS"; then

kdedirs_first=`echo $KDEDIRS|sed -e 's/:.*//'`

sys_odir=$kdedirs_first/share/fonts/override

sys_fdir=$kdedirs_first/share/fonts

else

sys_odir=$KDEDIR/share/fonts/override

sys_fdir=$KDEDIR/share/fonts

fi

# We run mkfontdir on the user's font dirs (if we have permission) to pick

# up any new fonts they may have installed. If mkfontdir fails, we still

# add the user's dirs to the font path, as they might simply have been made

# read-only by the administrator, for whatever reason.

test -d $usr_odir && (mkfontdir $usr_odir ; xset +fp $usr_odir)

test -d $sys_odir && xset +fp $sys_odir

test -d $usr_fdir && (mkfontdir $usr_fdir ; xset fp+ $usr_fdir)

test -d $sys_fdir && xset fp+ $sys_fdir

#

# Add any user-installed font directories to the X font path

kde_fontsdir=$kdehome/share/fonts

kde_fontpaths=$kde_fontsdir/fontpaths

if test -r $kde_fontpaths ; then

for fpath in `cat $kde_fontpaths | grep -v '#'` ; do

if test -s $fpath/fonts.dir ; then

xset fp+ $fpath

fi

done

fi

# Ask X11 to rebuild its font list.

xset fp rehash

#

# Get Ghostscript to look into user's KDE fonts dir for additional Fontmap

if test -n "$GS_LIB" ; then

GS_LIB=$kde_fontsdir:$GS_LIB

export GS_LIB

else

GS_LIB=$kde_fontsdir

export GS_LIB

fi

Nothing stops you from adapting the script for non-KDE use and sticking it in a trusted users bash profile.

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

>> Now let's see a well coordinated effort to create /usr/share/fonts and make it so I can drop any font file in there and it will *just work*.

wait wait... i for one would like them to be in

/opt/usr/global/var/share/fonts, with personal-only fonts put in /var/usr/.profile/touchmenot/fonts, and

TT fonts put in /etc/TT/...

Re: Is Beauty Only Pixel Deep?, Part 1

davechen's picture

What about anti-aliased fonts? My biggest gripe with X

windows versus Mac OS X or Windows is the ugly fonts and

lack of anti-aliasing. I tried to enable anti-aliasing once,

following instructions I found on various web sites, but

could never get it to work.

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

This is something that will never cease mistifying me. The purported advantages and beauty of anti-aliasing are virtues that I have yet to understand. In my monitor anti-aliasing does nothing to improve quality, and my screen has nothing whatsoever to envy when compared with a Mac or Windows PC. And, yes, I know how to enable/disable anti-aliasing.

Really, I think that anti-aliasing is just another fad which, as all fads, is of a very limited and questionable value.

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

That is true for the most cases, but if you prefers some odd setups, anti-aliasing can help you quite bit. I didn't care for alti-aliasing before, but I need it now badly, at least until I get a bigger, better monitor.

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

well, yes -- a fad for poor monitor/video card users. Personally I use HP P1110/Matrox G400 at 2048x1536 which translates to 132 dpi for my xfs's font rendering efforts. KDE AA is almost useless with me. To make it absolutely useless and gone, one needs to go to 150~180 dpi for one's screen which I plan to do for my next upgrade (Matrox Parhelia 512/iiYama Vision Master Pro 512, both @400MHz of bandwidth). Pity and shame freetype/freetype2 as of version 2.1.0 doesn't know a fig in delta-hinting, hints as such, kerning -- all the beauty and delicacy of finest typography works goes right to the drain.

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

It also has much to do w/ who you compile freetype and how you set up Xft. I spent a couple of days to get it right, and i do have to say AA is an improvement.

First, read up on the freetype site (freetype.org?) about the patent issues. Even w/ the proper bits compiled in, it isn't the best font renderer in the world, but for many fonts (like most of the microsoft ones), its quite nice.

Also make sure you setup Xft to not AA small fonts, say everything at pt 16 and under. This helps give you very sharp and readable text at small sizes, and also makes large headdings and such nice and smooth.

This is on a flatpanel too, so its really pretty. I can see that on a bad CRT it could have different effects, but now I can't stand to work on a box w/o AA.

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

Only my opinion and I may be wrong -- but in case I'm right, here it goes:

Anti-aliasing loses a lot (at least here) at lower resolutions: 800x600 doesn't allow a "good experience" (in fact it should work better at coarse resolutions, but I figure our eyes can see jagged edges better then). Try it at least at 1024x768.

Conversely, if you use a high enough resolution (say, 1600x1200) and get a somewhat fuzzy image, it may be difficult to separate what is anti-aliasing from fuzzy aspect the monitor creates.

Also, anti-aliasing is most benefitial to these fonts which are incomplete. For example, the "times" font is available at various sizes, so you won't likely notice a better image. Try using a bit-mapped font at a big weird size (like 29). If you see letters apparently made of blocks (i.e., jagged) then they _should_ look beautiful when anti-aliased.

All in all the biggest advantage, I imagine, is that you can scale a font to any desired size -- that means that cute font you only have at size 8 could be seen at size 36 now; also most html pages will render correctly since a weird font will be resized correctly and text will fit exaclty where the mor^H^H^H webdesigner meant it to be.

A side-effect is the increased processor usage (my Pentium 133 renders text at a perceivable longer time) and reduced memory requirement (since you wouldn't need fonts for all sizes in a typeface).

I would agree with you about anti-aliasing being not that important, except I don't think it's a fad. I guess it's here to stay.

It's kinda having a good calligraphy (?sp) or newer printing techniques allowing for beautiful magazines (like Wired): the content is still what counts, but the packaging really helps to sell.

In a short time, it is my opinion, some "professional" OSes will only have aesthetic advantages over Linux; technically things will be even or Linux will have an edge.

In this case, why not have an "dressed-to-kill" looks option and put the last nail on their coffin?

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

Hmm, now I see why you like it :-)

Use of antialiasing precludes the use of any bitmapped fonts, so your example of 'use an imcomplete font at a big odd size' is bogus - Xft (the library behind Antialiased fonts) won't do that. In fact, you can't select the fonts that aren't scalable at all, because it doesn't support them period. So when you turn on AA, what you've really accomplished is to pick your truetype fonts, which probably do look much better than the old bitmapped ones.

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

Have a look at the XFree86 Font De-uglification HOWTO. It might be what you are looking for....

http://www.tldp.org/HOWTO/mini/FDU/

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

Your article encourages me to go boldly where I usually didn't go before. :))

Cheers,

Dhar

Re: Is Beauty Only Pixel Deep?, Part 1

Anonymous's picture

Marcel is one heck of a writer, you should try his new book, Linux System Administration: A User's Guide, great!

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix