Fonts in X11R

2.1.1. Installing fonts in Xft

Fontconfig looks for fonts in a set of well-known directories that include all of X11R's standard font directories (`/usr/X11R6/lib/X11/lib/fonts/*') by default) as well as a directory called `.fonts/' in the user's home directory. Installing a font for use by Xft applications is as simple as copying a font file into one of these directories.

$ cp lucbr.ttf ~/.fonts/

$ fc-cache

In order to globally update the system-wide Fontconfig information on Unix systems, you will typically need to run this command as root:

$ su -c fc-cache

2.1.2. Fine-tuning Xft

Fontconfig's behaviour is controlled by a set of configuration files: a standard configuration file, `/etc/fonts/fonts.conf', a host-specific configuration file, `/etc/fonts/local.conf', and a user-specific file called `.fonts.conf' in the user's home directory (this can be overridden with the `FONTCONFIG_FILE' environment variable).

Every Fontconfig configuration file must start with the following boilerplate:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>

</fontconfig>

The default Fontconfig configuration file includes the directory `˜/.fonts/' in the list of directories searched for font files, and this is where user-specific font files should be installed. In the unlikely case that a new font directory needs to be added, this can be done with the following syntax:

<dir>/usr/local/share/fonts/</dir>

Another useful option is the ability to disable anti-aliasing (font smoothing) for selected fonts. This can be done with the following syntax:

<match target="font">
    <test qual="any" name="family">
        <string>Lucida Console</string>
    </test>
    <edit name="antialias" mode="assign">
        <bool>false</bool>
    </edit>
</match>

<match target="font">
    <edit name="antialias" mode="assign">
        <bool>false</bool>
    </edit>
</match>

Xft supports sub-pixel rasterisation on LCD displays. X11R should automatically enable this feature on laptops and when using an LCD monitor connected with a DVI cable; you can check whether this was done by typing

$ xdpyinfo -ext RENDER | grep sub-pixel

<match target="font">
    <edit name="rgba" mode="assign">
        <const>rgb</const>
    </edit>
</match>

2.1.3. Configuring applications

A growing number of applications use Xft in preference to the core fonts system. Some applications, however, need to be explicitly configured to use Xft.

A case in point is XTerm, which can be set to use Xft by using the `-fa' command line option or by setting the `XTerm*faceName' resource:

XTerm*faceName: Courier

$ xterm -fa "Courier"

For KDE applications, you should select ``Anti-alias fonts'' in the ``Fonts'' panel of KDE's ``Control Center''. Note that this option is misnamed: it switches KDE to using Xft but doesn't enable anti-aliasing in case it was disabled by your Xft configuration file.

Gnome applications and Mozilla Firefox will use Xft by default.

2.2.1. Installing bitmap fonts

The X11R server can use bitmap fonts in both the cross-platform BDF format and the somewhat more efficient binary PCF format. (X11R also supports the obsolete SNF format.)

Bitmap fonts are normally distributed in the BDF format. Before installing such fonts, it is desirable (but not absolutely necessary) to convert the font files to the PCF format. This is done by using the command `bdftopcf', e.g.

$ bdftopcf courier12.bdf

$ gzip courier12.pcf

After the fonts have been converted, you should copy all the font files that you wish to make available into a arbitrary directory, say `/usr/local/share/fonts/bitmap/'. You should then create the index file `fonts.dir' by running the command `mkfontdir' (please see the mkfontdir(1) manual page for more information):

$ mkdir /usr/local/share/fonts/bitmap/
$ cp *.pcf.gz /usr/local/share/fonts/bitmap/
$ mkfontdir /usr/local/share/fonts/bitmap/

All that remains is to tell the X server about the existence of the new font directory; see Setting the server font path below.

2.2.2. Installing scalable fonts

The X11R server supports scalable fonts in multiple formats, including Type 1, TrueType, OpenType/CFF and CIDFont. This section only applies to the first three; for information on CIDFonts, please see Installing CIDFonts later in this document. (Earlier versions of X11 also included support for the Speedo scalable font format, but that is disabled in the default builds of X11R6.9 and not included in X11R7.0 and later releases.)

Installing scalable fonts is very similar to installing bitmap fonts: you create a directory with the font files, and run `mkfontdir' to create an index file called `fonts.dir'.

There is, however, a big difference: `mkfontdir' cannot automatically recognise scalable font files. For that reason, you must first index all the font files in a file called `fonts.scale'. While this can be done by hand, it is best done by using the `mkfontscale' utility.

$ mkfontscale /usr/local/share/fonts/Type1/
$ mkfontdir /usr/local/share/fonts/Type1/

2.2.3. Installing CID-keyed fonts

The CID-keyed font format was designed by Adobe Systems for fonts with large character sets. The CID-keyed format is obsolete, as it has been superseded by other formats such as OpenType/CFF; however, support for CID-keyed fonts is still provided in X11.

A CID-keyed font, or CIDFont for short, contains a collection of glyphs indexed by character ID (CID).

In order to map such glyphs to meaningful indices, Adobe provide a set of CMap files. The PostScript name of a font generated from a CIDFont consists of the name of the CIDFont and the name of the CMap separated by two dashes. For example, the font generated from the CIDFont `Munhwa-Regular' using the CMap `UniKS-UCS2-H' is called

Munhwa-Regular--UniKS-UCS2-H

The CIDFont code in X11R requires a very rigid directory structure. The main directory must be called `CID' (its location defaults to `/usr/X11R6/lib/X11/fonts/CID' but it may be located anywhere), and it should contain a subdirectory for every CID collection. Every subdirectory must contain subdirectories called CIDFont (containing the actual CIDFont files), CMap (containing all the needed CMaps), AFM (containing the font metric files) and CFM (initially empty). For example, in the case of the font Munhwa-Regular that uses the CID collection Adobe-Korea1-0, the directory structure should be as follows:

CID/Adobe-Korea1/CIDFont/Munhwa-Regular
CID/Adobe-Korea1/CMap/UniKS-UCS2-H
CID/Adobe-Korea1/AFM/Munhwa-Regular.afm
CID/Adobe-Korea1/CFM/
CID/fonts.dir
CID/fonts.scale

After creating this directory structure and copying the relevant files, you should create a `fonts.scale' file. This file has the same format as in the case of (non-CID) scalable fonts, except that its first column contains PostScript font names with the extension `.cid' appended rather than actual filenames:

1
Adobe-Korea1/Munhwa-Regular--UniKS-UCS2-H.cid \
  -adobe-munhwa-medium-r-normal--0-0-0-0-p-0-iso10646-1

$ cd /usr/local/share/fonts/CID
$ mkfontdir

Finally, you should create the font metrics summary files in the directory `CFM' by running the command `mkcfm':

$ mkcfm /usr/local/share/fonts/CID

2.2.4. Setting the server's font path

The list of directories where the server looks for fonts is known as the font path. Informing the server of the existence of a new font directory consists of putting it on the font path.

The font path is an ordered list; if a client's request matches multiple fonts, the first one in the font path is the one that gets used. When matching fonts, the server makes two passes over the font path: during the first pass, it searches for an exact match; during the second, it searches for fonts suitable for scaling.

For best results, scalable fonts should appear in the font path before the bitmap fonts; this way, the server will prefer bitmap fonts to scalable fonts when an exact match is possible, but will avoid scaling bitmap fonts when a scalable font can be used. (The `:unscaled' hack, while still supported, should no longer be necessary in X11R.)

You may check the font path of the running server by typing the command

$ xset q

$ xset +fp /usr/local/fonts/Type1
$ xset fp+ /usr/local/fonts/bitmap

FontPath "/usr/local/fonts/Type1"
...
FontPath "/usr/local/fonts/bitmap"

2.2.5. Troubleshooting

If you seem to be unable to use some of the fonts you have installed, the first thing to check is that the `fonts.dir' files are correct and that they are readable by the server (the X server usually runs as root, beware of NFS-mounted font directories). If this doesn't help, it is quite possible that you are trying to use a font in a format that is not supported by your server.

X11R supports the BDF, PCF, SNF, Type 1, TrueType, OpenType and CIDFont font formats. However, not all X11R servers come with all the font backends configured in.

On most platforms, the X11R servers are modular: the font backends are included in modules that are loaded at runtime. The modules to be loaded are specified in the `xorg.conf' file using the `Load' directive:

Load "type1"

• "bitmap": bitmap fonts (`*.bdf', `*.pcf' and `*.snf');

• "freetype": TrueType fonts (`*.ttf' and `*.ttc'), OpenType fonts (`*.otf' and `*.otc') and Type 1 fonts (`*.pfa' and `*.pfb');

• "type1": alternate Type 1 backend (`*.pfa' and `*.pfb') and CIDFont backend;

• "xtt": alternate TrueType backend (`*.ttf' and `*.ttc').

3.3.1. Standard Type 1 fonts

The IBM Courier set of fonts cover ISO 8859-1 and ISO 8859-2 as well as Adobe Standard Encoding. These fonts have XLFD

-adobe-courier-medium-*-*--0-0-0-0-m-0-*-*

/usr/X11R6/lib/X11/fonts/Type1/cour*.pfa

The Adobe Utopia set of fonts only cover ISO 8859-1 as well as Adobe Standard Encoding. These fonts have XLFD

-adobe-utopia-*-*-normal--0-0-0-0-p-0-iso8859-1

/usr/X11R6/lib/X11/fonts/Type1/UT*.pfa

Finally, X11R also comes with Type 1 versions of Bitstream Courier and Charter. These fonts have XLFD

-bitstream-courier-*-*-normal--0-0-0-0-m-0-iso8859-1
-bitstream-charter-*-*-normal--0-0-0-0-p-0-iso8859-1

/usr/X11R6/lib/X11/fonts/Type1/c*bt_.pfb

4.1.1. The fontenc layer

Two of the scalable backends (Type 1 and the FreeType TrueType backend) use a common fontenc layer for font re-encoding. This allows these backends to share their encoding data, and allows simple configuration of new locales independently of font type.

Please note: the X-TrueType (X-TT) backend is not included in X11R. That functionality has been merged into the FreeType backend.>

In the fontenc layer, an encoding is defined by a name (such as iso8859-1), possibly a number of aliases (alternate names), and an ordered collection of mappings. A mapping defines the way the encoding can be mapped into one of the target encodings known to fontenc; currently, these consist of Unicode, Adobe glyph names, and arbitrary TrueType ``cmap''s.

A number of encodings are hardwired into fontenc, and are therefore always available; the hardcoded encodings cannot easily be redefined. These include:

• iso10646-1: Unicode;

• iso8859-1: ISO Latin-1 (Western Europe);

• iso8859-2: ISO Latin-2 (Eastern Europe);

• iso8859-3: ISO Latin-3 (Southern Europe);

• iso8859-4: ISO Latin-4 (Northern Europe);

• iso8859-5: ISO Cyrillic;

• iso8859-6: ISO Arabic;

• iso8859-7: ISO Greek;

• iso8859-8: ISO Hebrew;

• iso8859-9: ISO Latin-5 (Turkish);

• iso8859-10: ISO Latin-6 (Nordic);

• iso8859-15: ISO Latin-9, or Latin-0 (Revised Western-European);

• koi8-r: KOI8 Russian;

• koi8-u: KOI8 Ukrainian (see RFC 2319);

• koi8-ru: KOI8 Russian/Ukrainian;

• koi8-uni: KOI8 ``Unified'' (Russian, Ukrainian, and Byelorussian);

• koi8-e: KOI8 ``European,'' ISO-IR-111, or ECMA-Cyrillic;

• microsoft-symbol and apple-roman: these are only likely to be useful with TrueType symbol fonts.

Additional encodings can be added by defining encoding files. When a font encoding is requested that the fontenc layer doesn't know about, the backend checks the directory in which the font file resides (not necessarily the directory with fonts.dir!) for a file named `encodings.dir'. If found, this file is scanned for the requested encoding, and the relevant encoding definition file is read in. The `mkfontdir' utility, when invoked with the `-e' option followed by the name of a directory containing encoding files, can be used to automatically build `encodings.dir' files. Please see the mkfontdir(1) manual page for more details.

A number of encoding files for common encodings are included with X11R. Information on writing new encoding files can be found in Format of encodings directory files and Format of encoding files later in this document.

4.1.2. Backend-specific notes about fontenc

4.1.3. Format of encoding directory files

In order to use a font in an encoding that the font backend does not know about, you need to have an `encodings.dir' file either in the same directory as the font file used or in a system-wide location (`/usr/X11R6/lib/X11/fonts/encodings/' by default).

The `encodings.dir' file has a similar format to `fonts.dir'. Its first line specifies the number of encodings, while every successive line has two columns, the name of the encoding, and the name of the encoding file; this can be relative to the current directory, or absolute. Every encoding name should agree with the encoding name defined in the encoding file. For example,

3
mulearabic-0 /usr/X11R6/lib/X11/fonts/encodings/mulearabic-0.enc
mulearabic-1 /usr/X11R6/lib/X11/fonts/encodings/mulearabic-1.enc
mulearabic-2 /usr/X11R6/lib/X11/fonts/encodings/mulearabic-2.enc

The name of an encoding must be specified in the encoding file's `STARTENCODING' or `ALIAS' line. It is not enough to create an `encodings.dir' entry.

If your platform supports it (it probably does), encoding files may be compressed or gzipped.

The `encoding.dir' files are best maintained by the `mkfontdir' utility. Please see the mkfontdir(1) manual page for more information.

4.1.4. Format of encoding files

The encoding files are ``free form,'' i.e. any string of whitespace is equivalent to a single space. Keywords are parsed in a non-case-sensitive manner, meaning that `size', `SIZE', and `SiZE' all parse as the same keyword; on the other hand, case is significant in glyph names.

Numbers can be written in decimal, as in `256', in hexadecimal, as in `0x100', or in octal, as in `0400'.

Comments are introduced by a hash sign `#'. A `#' may appear at any point in a line, and all characters following the `#' are ignored, up to the end of the line.

The encoding file starts with the definition of the name of the encoding, and possibly its alternate names (aliases):

STARTENCODING mulearabic-0
ALIAS arabic-0

The encoding file may then optionally declare the size of the encoding. For a linear encoding (such as ISO 8859-1), the SIZE line specifies the maximum code plus one:

SIZE 0x2B

SIZE 0x75 0x80

FIRSTINDEX 0x20 0x20

Note that in most font backends inclusion of a `FIRSTINDEX' line has the side effect of disabling default glyph generation, and this keyword should therefore be avoided unless absolutely necessary.

Codes outside the region defined by the `SIZE' and `FIRSTINDEX' lines are understood to be undefined. Encodings default to linear encoding with a size of 256 (0x100). This means that you must declare the size of all 16 bit encodings.

What follows is one or more mapping sections. A mapping section starts with a `STARTMAPPING' line stating the target of the mapping. The target may be one of:

• Unicode (ISO 10646):

  STARTMAPPING unicode

• a given TrueType ``cmap'':

  STARTMAPPING cmap 3 1

• PostScript glyph names:

  STARTMAPPING postscript

0x21 0x0660
0x22 0x0661
...

<it/start/ <it/end/ <it/target/

start     target

start+1   target+1

...

end       target+end-start

0x2121 0x215F 0x8140

0x2121 0x8140
0x2122 0x8141
...
0x215F 0x817E

UNDEFINE 0x00 0x2A

UNDEFINE 0x1234

PostScript mappings are different. Every line in a PostScript mapping maps a code to a glyph name

0x41 A
0x42 B
...

A mapping section ends with an ENDMAPPING line

ENDMAPPING

ENDENCODING

In order to make future extensions to the format possible, lines starting with an unknown keyword are silently ignored, as are mapping sections with an unknown target.

4.1.5. Using symbol fonts

Type 1 symbol fonts should be installed using the adobe-fontspecific encoding.

In an ideal world, all TrueType symbol fonts would be installed using one of the microsoft-symbol and apple-roman encodings. A number of symbol fonts, however, are not marked as such; such fonts should be installed using microsoft-cp1252, or, for older fonts, microsoft-win3.1.

In order to guarantee consistent results (especially between Type 1 and TrueType versions of the same font), it is possible to define a special encoding for a given font. This has already been done for the ZapfDingbats font; see the file `encodings/adobe-dingbats.enc'.

4.1.6. Hints about using badly encoded fonts

A number of text fonts are incorrectly encoded. Incorrect encoding is sometimes done by design, in order to make a font for an exotic script appear like an ordinary Western text font on systems which are not easily extended with new locale data. It is often the result of the font designer's laziness or incompetence; for some reason, most people seem to find it easier to invent idiosyncratic glyph names rather than follow the Adobe glyph list.

There are two ways of dealing with such fonts: using them with the encoding they were designed for, and creating an ad hoc encoding file.

"-ogonki-alamakota-medium-r-normal--0-0-0-0-p-0-iso8859-2" \
  "-ogonki-alamakota-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific"

4.2.1. About the FreeType backend

The FreeType (libfreetype-xtt2) backend (formerly xfsft) is a backend based on version 2 of the FreeType library (see the FreeType web site) and has the X-TT functionalities for CJKV support provided by the After X-TT Project (see the After X-TT Project web site). The FreeType module has support for the ``fontenc'' style of internationalisation (see Section 4.1.1). This backend supports TrueType font files (`*.ttf'), OpenType font files (`*.otf'), TrueType Collections (`*.ttc'), OpenType Collections (`*.otc') and Type 1 font files (`*.pfa' and `*.pfb').

In order to access the faces in a TrueType Collection file, the face number must be specified in the fonts.dir file before the filename, within a pair of colons, or by setting the 'fn' TTCap option. For example,

:1:mincho.ttc -misc-pmincho-medium-r-normal--0-0-0-0-p-0-jisx0208.1990-0

refers to face 1 in the `mincho.ttc' TrueType Collection file.

The new FreeType backend supports the extended `fonts.dir' syntax introduced by X-TrueType with a number of options, collectively known as `TTCap'. A `TTCap' entry follows the general syntax

option=value:

and should be specified before the filename. The new FreeType almost perfectly supports TTCap options that are compatible with X-TT 1.4. The Automatic Italic (`ai'), Double Strike (`ds') and Bounding box Width (`bw') options are indispensable in CJKV. For example,

mincho.ttc -misc-mincho-medium-r-normal--0-0-0-0-c-0-jisx0208.1990-0
ds=y:mincho.ttc -misc-mincho-bold-r-normal--0-0-0-0-c-0-jisx0208.1990-0
ai=0.2:mincho.ttc -misc-mincho-medium-i-normal--0-0-0-0-c-0-jisx0208.1990-0
ds=y:ai=0.2:mincho.ttc -misc-mincho-bold-i-normal--0-0-0-0-c-0-jisx0208.1990-0
bw=0.5:mincho.ttc -misc-mincho-medium-r-normal--0-0-0-0-c-0-jisx0201.1976-0
bw=0.5:ds=y:mincho.ttc -misc-mincho-bold-r-normal--0-0-0-0-c-0-jisx0201.1976-0
bw=0.5:ai=0.2:mincho.ttc -misc-mincho-medium-i-normal--0-0-0-0-c-0-jisx0201.1976-0
bw=0.5:ds=y:ai=0.2:mincho.ttc -misc-mincho-bold-i-normal--0-0-0-0-c-0-jisx0201.1976-0

setup the complete combination of jisx0208 and jisx0201 using mincho.ttc only. More information on the TTCap syntax is found on the After X-TT Project page.

The FreeType backend uses the fontenc layer in order to support recoding of fonts; this was described in Section 4.1.1 and especially Section 4.1.2.1 earlier in this document.

4.2.2. About the X-TrueType TrueType backend

The `X-TrueType' backend is a backend based on version 1 of the FreeType library. X-TrueType doesn't use the `fontenc' layer for managing font encodings, but instead uses its own database of encodings.

Since the functionalities for CJKV support introduced by X-TT have been merged into the new FreeType backend, the X-TT backend will be removed from X11R's tree near the future. Therefore, the use of FreeType backend is preferred over the X-TT backend.

General information on X-TrueType may be found at the After X-TT Project page.

4.2.3. Delayed glyph rasterisation

When loading a proportional fonts which contain a huge number of glyphs, the old FreeType delayed glyph rasterisation until the time at which the glyph was first used. The new FreeType (libfreetype-xtt2) has an improved `very lazy' metric calculation method to speed up the process when loading TrueType or OpenType fonts. Although the X-TT module also has this method, the "vl=y" TTCap option must be set if you want to use it. This is the default method for FreeType when it loads multi-byte fonts. Even if you use a unicode font which has tens of thousands of glyphs, this delay will not be worrisome as long as you use the new FreeType backend -- its `very lazy' method is super-fast.

The maximum error of bitmap position using `very lazy' method is 1 pixel, and is the same as that of a character-cell spacing. When the X-TT backend is used with the `vl=y' option, a chipped bitmap is displayed with certain fonts. However, the new FreeType backend has minimal problem with this, since it corrects left- and right-side bearings using `italicAngle' in the TrueType/OpenType post table, and does automatic correction of bitmap positions when rasterisation so that chipped bitmaps are not displayed. Nevertheless if you don't want to use the `very lazy' method when using multi-bytes fonts, set `vl=n' in the TTCap option to disable it:

vl=n:luxirr.ttf -b&h-Luxi Serif-medium-r-normal--0-0-0-0-p-0-iso10646-1

Of course, both backends also support an optimisation for character-cell fonts (fonts with all glyph metrics equal, or terminal fonts). A font with an XLFD specifying a character-cell spacing `c', as in

-misc-mincho-medium-r-normal--0-0-0-0-c-0-jisx0208.1990-0

or

fs=c:mincho.ttc -misc-mincho-medium-r-normal--0-0-0-0-p-0-jisx0208.1990-0

will not compute the metric for each glyph, but instead trust the font to be a character-cell font. You are encouraged to make use of this optimisation when useful, but be warned that not all monospaced fonts are character-cell fonts.