At the present time, X.org and XFree86 use two font subsystems, each with different characteristics:

Over time, fontconfig/Xft will replace the core X font subsystem. At the present time, applications using the Qt 3 or GTK 2 toolkits (which would include KDE and GNOME applications) use the fontconfig and Xft font subsystem; most everything else uses the core X fonts.

In the future, Linux distributions may support only fontconfig/Xft in place of the XFS font server as the default local font access method.

FreeType compiled with BCI presented much better screen font rendering results.

Get RPMs for your distribution here:

If you use one of these distributions, but on a platform that binary RPMs are not being provided, you can easily compile your own (even if you don't have any software compilation skills) following the instructions on Appendix B, Recompiling an RPM Ready for Your Distribution.

WE WILL ACCEPT CONTRIBUTIONS of distribution specific FreeType repackaging, so if you can contact us, we appreciate.

If you are interested in repackaging your own FreeType, see how we repackage the Fedora Core and Red Hat RPMs with BCI on the Appendix A, Recompiling FreeType for BCI as a reference.

General Guidelines

The main idea is to use good hinted fonts all around. As a general rule, we'll use Tahoma 8pt for desktop widgets, LucidaTypewriter 8pt for monospace text, and Verdana 8pt, 9pt or 10pt for fluent text reading or web surfing. These are the default font sizes on a Microsoft Windows desktop, and they look good on a 1024x768 screen. If you have a better screen resolution (1280x1024, 1600x1200) our suggestion is to stick with these fonts but increase their sizes.

We choose these fonts, specially Microsoft's Tahoma and Verdana, because they look perfect at small sizes (8pt, due to their excellent hinting), providing a more efficient screen utilization. They'll make your desktop look beautiful, professional, clean and comfortable. These fonts were designed for this purpose.

For window titles or text that will appear in bigger sizes, you may choose whatever you want because bigger sizes hinting are not so relevant.

3.2.2. KDE

To configure KDE, use the Control Center (kcontrol in the command line). This is how I have it configured.

Figure 1. General KDE font configuration

So we basically chose Trebuchet 12pt as the window title font, the bitmap font LucidaTypewriter 8pt for fixed size text, and Tahoma 8pt for everything else, which includes menus, buttons, etc. The 2 first should follow your taste, but Tahoma 8pt for all the rest is the optimal configuration, also used by MS Windows 2000 and XP.

One other thing to note is that I disabled anti-aliasing for font sizes up to 9 points. Look at the entire dialog and see how all text is clearly rendered, looks clean precise and professional.

Konqueror (KDE's browser and file manager) also needs font configuration for beautiful web browsing and file management.

Figure 2. Konqueror File Management font configuration

We used the same Tahoma 8pt for rendering the list of files in Konqueror's window, because Tahoma was simply designed with this purpose in mind, with 8pt being its most important size, with no need of anti-aliasing to be clear and beautiful.

Figure 3. Konqueror Web Browsing font configuration

And this is finally for web browsing. We are using Verdana as the general font because it was simply designed for the purpose of fluent text reading on the screen. And the old LucidaTypewriter when a web page requested a fixed size font. Some may choose fonts like Courier or Bistream Vera Mono here.

We left all other fonts blank, to let the page choose it. But you may use Times New Roman as the Serif Font. Read more about serif fonts in Section 7.2.2, “To serif or not to serif ?”.

The sizes of the fonts for browsing are a bit personal and depends on how healthy are your eyes, and the resolution of your screen. In my 1024x768 screen I use default size as 8pt, and I don't want web pages to use sizes smaller than 7pt. In the end of the day, to set the size is not so effective because modern web pages use to set them with absolute values. So it is more practical to use the browsers View menu to "zoom" the page you are currently seeing.

One more thing to note is the Default Encoding. This is a quite complex subject that deserves an entire HOWTO, but it is generally OK to leave it as the Language Encoding. You may need to change it if you frequently browse pages with non pure ASCII (international text) made by irresponsible webmasters that still don't use UTF-8 for the web. But here also it may be more practical to use the View menu to set the encoding for the current page you are browsing.

3.2.3. Gnome

We'll use our generic rules here too: Tahoma 8pt for everything. Navigate preferences menu to invoke the following dialog or just run gnome-font-properties from the command line.

Figure 4. Gnome Font Configurations

3.2.4. OpenOffice.org

As of Fedora Core 3 time, OpenOffice.org 1.1.2 has look (but not feel) integration with KDE and Gnome. This means that your environment should tell OOo how to use widget fonts. But we found it didn't really work. With further investigation we found that only the non-AA configuration we made was not propagated to OOo. So we used OOo's own dialogs to change it.

Figure 5. OpenOffice.org font configuration, using my KDE themes etc.

So we basically selected Tool, Options menu, and in the View section we enable OOo to do anti-aliasing at font sizes beginning with 12 pixels (approximately 9pt), and the result is what you can see above: clean and comfortable widgets with Tahoma 8pt.

3.2.5. Mozilla Firefox

Mozilla Firefox follows the same Konqueror rules.

Figure 6. Firefox fonts for web browsing

So we Edit->Preferences and then Fonts & Colors , and selected Verdana 14px for general browsing and LucidaTypewriter 11px for monospace text.

Firefox is a Gnome application, so it will use Gnome's font settings for widgets.

Additionaly, a very interesting way to configure some font rendering aspects of Firefox is described in a Mandrake Wiki.

3.2.6. Beautiful Alternatives Without Webcore Fonts

If you want to stay away from patents and proprietary fonts, the best way to go is with Bitstream Vera Sans 8pt, Nimbus Sans 8 or 9pt, or Luxi Sans 8 or 9pt (also known as Sans, simply) for desktop widgets, and bigger sizes for fluent text reading. You'll need Anti-Aliasing to blur the low quality of the hinting of these fonts.

Here are some screen shots about the usage of these fonts on KDE. You should pay attention on how the widgets text on this window are rendered.

Figure 7. Bitstream Vera 8pt with Anti-Aliasing

Figure 8. Luxi 8pt with Anti-Aliasing

Figure 9. Luxi 9pt with Anti-Aliasing

Figure 10. Nimbus 9pt with Anti-Aliasing

As you can see, the results aren't so good as Tahoma 8pt.

Bitstream donated to the open world their Vera set of fonts, which are good quality and include a sans, sans serif and monospace fonts. This fonts are not very well hinted but can be used for desktop widgets, programming, fluent text reading and web surfing. Here is a screen shot:

Figure 11. Bitstream Vera Fonts

At these sizes, these fonts look great, specially with anti-aliasing. But unfortunately their bad hinting can be noted at small sizes.

Bitstream Vera fonts are included by default in all modern Linux distributions.

The DejaVu fonts are modifications of the Bitstream Vera fonts designed to extend this original for greater coverage of Unicode. It is being included by default in all modern Linux distributions, and everywhere you were thinking to use Bitstream Vera, DejaVu is another option with a more complete Unicode set.

Figure 12. The DejaVu Fonts

The official distribution of these fonts for Linux include tarballs and RPMs for several distributions.

Also known as the Microsoft fonts, these are the best fonts available to be used on the screen. Very well hinted for small sizes makes them perfect for desktop widgets, fluent text, etc.

They are Verdana, Tahoma, Times New Roman, Arial, Trebuchet, Comic Sans, Impact and others. Here is a screen shot of them:

Figure 13. The Webcore Fonts

As we said before, Tahoma and Verdana were designed for the screen, but they are getting overused for many other purpose.

Our objective here is to provide links where you can get good quality RPMs, debs, etc for your distribution. These packages are provided by independent contributors, so if you have the skills to build them for your distribution, please contact us and send the URL for your packages. WE WILL ACCEPT CONTRIBUTIONS.

Packages for distributions:

After installing this font package you'll also note a better rendering of web pages, because professional web designers use to use them for their pages.

Some people say these fonts are free only for persons who have a Microsoft Windows license.

If you need to exchange documents with Windows users, you should use Windows fonts. This is the general rule. So you should install the Webcore Fonts package and take care to use only Arial, Times New Roman, Verdana, etc, on your docs.

The combination of these fonts with the cross-platform, high quality OpenOffice.org suite, gives you a truly productive teamwork tool.

The fonts available on modern Linux distributions, to produce good quality documents are the following:

Using these fonts you'll be able to safely exchange and print documents between different modern Linux distributions.

There are other fonts available on your Linux system, but we did not list them here because they are low-quality (obsolete) bitmap fonts, to be used on the screen, and not for documents.

The title says it all. OpenOffice.org's all platform packages include the Bitstream Vera package. So if you'll take care to use only these fonts, your documents will open nicely in any other OpenOffice.org installation.

As a side note, OpenOffice.org excels in portability. In any platform, OOo looks and works the same, and it takes special care with your documents layout. It is simply a great tool.

To make your documents have a professional look, you should choose the correct font for the document purpose. Our current culture standardized that serif fonts (Times, etc) are the right choice for books and magazines. Now sans-serif fonts (Arial, Helvetica, Verdana) are gaining space and some may feel these fonts provide a more modern look, because of their lack of serifs. We have seen them being used in printed articles and commercial proposals.

For web pages, Arial and Helvetica or specially Verdana, are definitively the right choice.

For further more deep information, please refer to Section 7, “Designer's Guide for Modern Good Looking Documents”, by Donovan Rebbechi on typography, about cultural and social facts that influenced font designing evolution, and what are being produced today by designers.

To build RPMs, you need a special structure of directories and some configurations on your environment. You should do everything as a regular user, in all steps. In fact, we recommend that you do not do this as root.

To create this directories, do this:

bash$ cd ~
bash$ mkdir -p src/rpm
bash$ cd src/rpm
bash$ cp -r /usr/src/redhat/* .
bash$ ls
BUILD/  RPMS/  SOURCES/  SPECS/  SRPMS/
bash$ 
			

(the "~" is an alias to the current user's home directory name, and the command line knows it should interpret it this way)

Of course this is on a Red Hat system, but the important point is to have the following directories under src/rpm:

Then, you'll have to create the .rpmmacros file in you home directory, with this single line content:

%_topdir        YOUR_HOME_DIR_HERE/src/rpm
			

And you should substitute YOUR_HOME_DIR_HERE with the absolute name of your $HOME directory. So as an example, my .rpmmacros file contains this line:

%_topdir        /home/aviram/src/rpm
			

Now you must think about a name for your font collection. To make things easy in this documentation, we'll use the name myfonts from now on. Then you must create a directory named ~/src/myfonts/myfonts (yes, myfonts two times) and put all your .ttf files right under it. So you'll have something like:

bash$ cd ~/src
bash$ find myfonts/myfonts/

myfonts/myfonts/
myfonts/myfonts/font1.ttf
myfonts/myfonts/font2.ttf
myfonts/myfonts/font3.ttf
...

			

To build an RPM package you'll have to create a .spec file that provides instructions to the package builder on how to organize the files, package description, author, copyright, etc. We provide a template here that you can use to start your work. The template looks like this:

Name: myfonts     
Summary: Collection of My Funny Fonts   
Version: 1.1   
Release: 1
License: GPL    
Group: User Interface/X
Source: %{name}.tar.gz
BuildRoot: %{_tmppath}/build-root-%{name}
BuildArch: noarch
Requires: freetype
Packager: Avi Alkalay <avi unix sh>    
Prefix: /usr/share/fonts
Url: http://myfonts.com/     

%description    
These are the fonts used in our marketing campaign, designed by our marketing agency specially for us.
The package includes the following fonts: Font 1, Font 2, Font 3, Font 4.


%prep

%setup -q -n %{name}

%build

%install
mkdir -p $RPM_BUILD_ROOT/%{prefix}
cp -r %{name}/ $RPM_BUILD_ROOT/%{prefix}


%clean
rm -rf $RPM_BUILD_ROOT


%files
%defattr(-,root,root,0755)
%{prefix}/%{name}


%post
{
	if test -x /sbin/conf.d/SuSEconfig.fonts ; then
		# This is a SUSE system. Use proprietary SuSE tools...
		if test "$YAST_IS_RUNNING" != "instsys" ; then
			if test -x /sbin/SuSEconfig -a -f /sbin/conf.d/SuSEconfig.fonts ; then
				/sbin/SuSEconfig --module fonts
			else
				echo -e "\nERROR: SuSEconfig or requested SuSEconfig module not present!\n" ; exit 1
			fi
		fi

		if test -x /sbin/conf.d/SuSEconfig.pango ; then
			if test "$YAST_IS_RUNNING" != "instsys" ; then 
				if test -x /sbin/SuSEconfig -a -f /sbin/conf.d/SuSEconfig.pango ; then
					/sbin/SuSEconfig --module pango
				else
					echo -e "\nERROR: SuSEconfig or requested SuSEconfig module not present!\n" ; exit 1
				fi
			fi
		fi
	else
		# Use regular open standards methods...
		ttmkfdir -d %{prefix}/%{name} \
			-o %{prefix}/%{name}/fonts.scale
		umask 133
		/usr/X11R6/bin/mkfontdir %{prefix}/%{name}
		/usr/sbin/chkfontpath -q -a %{prefix}/%{name}
		[ -x /usr/bin/fc-cache ] && /usr/bin/fc-cache
	fi
} &> /dev/null || :


%preun
{
	if [ "$1" = "0" ]; then
		cd %{prefix}/%{name}
		rm -f fonts.dir fonts.scale fonts.cache*
	fi
} &> /dev/null || :

%postun

{
	if test -x /sbin/conf.d/SuSEconfig.fonts ; then
		# This is a SUSE system. Use proprietary SuSE tools...
		if test "$YAST_IS_RUNNING" != "instsys" ; then
			if test -x /sbin/SuSEconfig -a -f /sbin/conf.d/SuSEconfig.fonts ; then
				/sbin/SuSEconfig --module fonts
			else
				echo -e "\nERROR: SuSEconfig or requested SuSEconfig module not present!\n" ; exit 1
			fi
		fi

		if test -x /sbin/conf.d/SuSEconfig.pango ; then
			if test "$YAST_IS_RUNNING" != "instsys" ; then 
				if test -x /sbin/SuSEconfig -a -f /sbin/conf.d/SuSEconfig.pango ; then
					/sbin/SuSEconfig --module pango
				else
					echo -e "\nERROR: SuSEconfig or requested SuSEconfig module not present!\n" ; exit 1
				fi
			fi
		fi
	else
		# Use regular open standards methods...
		if [ "$1" = "0" ]; then
			/usr/sbin/chkfontpath -q -r %{prefix}/%{name}
		fi
		[ -x /usr/bin/fc-cache ] && /usr/bin/fc-cache
	fi
} &> /dev/null || :








%changelog    
* Sun Apr 15 2007 Avi Alkalay <avi unix sh> 1.1
- Added support to SUSE on installation scriptlets
* Thu Dec 14 2002 Avi Alkalay <avi unix sh> 1.0
- Tested
- Ready for deployment
* Thu Dec 10 2002 Avi Alkalay <avi unix sh> 0.9
- First version of the template

					

This file must be named as the name of the package - myfonts.spec in our example. And you must put it under the main directory of the package. So in the end we'll have something like this:

bash$ cd ~/src
bash$ find myfonts
myfonts/
myfonts/myfonts.spec
myfonts/myfonts/
myfonts/myfonts/font1.ttf
myfonts/myfonts/font2.ttf
myfonts/myfonts/font3.ttf
...

			

We are almost ready to go. Next steps:

bash$ cd ~/src
bash$ tar -czvf myfonts.tar.gz myfonts
bash$ rpmbuild -ta myfonts.tar.gz
			

Done (after seeing a lot of messages about the building process). So we basically created a .tar.gz containing all our font files and myfonts.spec, and then we used rpmbuild on it, that will look for myfonts.spec inside the archive and follow its instructions.

You'll find the generated RPM under ~/src/rpm/RPMS/noarch/ directory, and this is the file you'll deploy and install. Under ~/src/rpm/SRPMS/ you'll find the source RPM file, which you should backup if you need to regenerate the deployable RPM again in the future. When you'll need it, you should do:

bash$ rpmbuild --rebuild myfonts-1.0-1.src.rpm
			

And the RPM file will be generated again.

For more information and advanced RPM packaging, read the Maximum RPM book, available in many formats in the rpm.org site.

Typically, typefaces come in groups of a few variants. For example, most fonts come with a bold, italic, and bold-italic variant. Some fonts may also have small caps, and demibold variants. A group of fonts consisting of a font and its variants is called a family of typefaces. For example, the Garamond family consists of Garamond, Garamond-italic, Garamond-bold, Garamond bold-italic, Garamond demi-bold, and Garamond demi-bold-italic. The Adobe expert Garamond font also makes available Garamond small caps, and Garamond titling capitals.

Font metrics define the spacing between variable width fonts. The metrics include information about the size of the font, and kerning information, which assigns kerning pairs -- pairs of characters that should be given different spacing. For example, the letters ``To'' would usually belong in a kerning pair, because correctly spaced (or kerned), the o should partly sit under the T. Typesetting programs such as LaTeX need to know information about kerning so that they can make decisions about where to break lines and pages. The same applies to WYSIWYG publishing programs.

The other important component of a font is the outline, or shape. The components of the fonts shape (a stroke, an accent, etc) are called glyphs.

A bitmap is a matrix of dots. Bitmap fonts are represented in precisely this way -- as matrices of dots. Because of this, they are device dependent -- they are only useful at a particular resolution. A 75 DPI screen bitmap font is still 75 DPI on your 1200 DPI printer.

There are two types of bitmap fonts -- bitmap printer fonts, such as the pk fonts generated by dvips, and bitmap screen fonts, used by X and the console. The bitmap screen fonts typically have a bdf or pcf extension. Bitmap screen fonts are most useful for terminal windows, consoles and text editors, where the lack of scalability and the fact that they are unprintable is not an issue.

TrueType fonts were developed by Apple. They made the format available to Microsoft, and successfully challenged Adobe's grip on the font market. True type fonts store the metric and shape information in a single file (usually one with a ttf extension). Recently, font servers have been developed that make TrueType available to X. And PostScript and ghostscript have supported TrueType fonts for some time. Because of this, TrueType fonts are becoming more popular on linux.

The Type 1 font standard was devised by Adobe, and Type 1 fonts are supported by Adobe's PostScript standard. Because of this, they are also well supported under linux. They are supported by X and ghostscript. Postscript fonts have traditionally been the choice of font for anything on UNIX that involves printing.

Typically, a UNIX Type 1 font is distributed as an afm (adobe font metric) file, and an outline file, which is usually a pfb (printer font binary) or pfa (printer font ascii) file. The outline file contains all the glyphs, while the metric file contains the metrics.

Type 1 fonts for other platforms may be distributed in different formats. For example, PostScript fonts for windows often use a different format (pfm) for the metric file.

These fonts are distributed in a similar manner to Type 1 files -- in groups of afm font metrics, and pfa files. While they are supported by the PostScript standard, they are not supported by X, and hence have limited use.

Type42 fonts are actually just TrueType fonts with headers that enable them to be rendered by a PostScript interpreter. Most applications, such as ghostscript and SAMBA handle these fonts transparently. However, if you have a PostScript printer, it may be necessary to explicitly create Type42 font files.

Despite the historical feuding between the proponents to Type 1 and TrueType fonts, both have a lot in common. Both are scalable outline fonts. Type 1 fonts use cubic as opposed to quadratic curves for the glyphs. This is in theory at least a slight advantage since they include all the curves available to TrueType fonts. In practice, it makes very little difference.

TrueType fonts have the apparent advantage that their support for hinting is better (Type 1 fonts do have hinting functionality, but it is not as extensive as that of TrueType fonts). However, this is only an issue on low resolution devices, such as screens (the improved hinting makes no discernable difference on a 600dpi printer, even at small point sizes.) The other point that makes this apparent advantage somewhat questionable is the fact that well hinted TrueType fonts are rare. This is because software packages that support hinting functionality are out of the budget of most small time designers. Only a few major foundries, such as Monotype make well hinted fonts available.

In conclusion, the main differences between TrueType and Type 1 fonts are in availability and application support. The widespread availability of TrueType fonts for Windows has resulted in webpages designed with the assumption that certain TrueType fonts are available. Also, many users have large numbers of TrueType fonts because they ship with the users Windows applications. However, on Linux, most applications support Type 1 fonts but do not have the same level of support for TrueType. Moreover, most major font foundries still ship most of their fonts in Type 1 format. For example, Adobe ships very few TrueType fonts. My recommendation to users is to use whatever works for your application, and try to avoid converting from one format to another where possible (because the format conversion is not without loss).