This version of XFree86 comes with two TrueType backends, known as `freetype' (formerly `xfsft') and `X-TrueType' (`X-TT' for short). Those two backends are incompatible, in that only one can be used at any one time. Users are invited to chose whichever backend they find more useful and stick to it.
The `freetype' backend resides in the module `
using it, please check that the `
Module' section of your
XF86Config' file contains a line that reads
The `X-TrueType' backend resides in module `
xtt'. In order to
use it, replace the line in your `
XF86Config' file that loads the
freetype' module with a line reading
Both TrueType backends delay glyph rasterisation to the time at which a glyph is first used. For this reason, they only provide an approximate value for the `average width' font property. Users are warned not to rely on the average width of a font having an accurate value.
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
will not rasterise glyphs at metrics computation time, but instead trust the font really to be a character-cell font. Users are encouraged to make use of this optimisation when useful, but be warned that not all monospaced fonts are character-cell fonts.
The `freetype' backend (formerly `xfsft') is a backend based on the
FreeType library (see www.freetype.org) with support for the `fontenc'
style of internationalisation (see
The fontenc layer). This backend supports TrueType Font files
*.ttf) and TrueType Collections (
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 colons. For example,
refers to face 2 in the `
mincho.ttc' TrueType Collection file.
The `X-TrueType' backend is another backend based on the FreeType library. X-TrueType doesn't use the `fontenc' layer for managing font encodings, but instead uses its own database of encodings. However, X-TrueType includes a large number of encodings, and any encoding you need is likely to be present in X-TrueType.
X-TrueType extends the `
fonts.dir' syntax with a number of options,
known as `TTCap'. A `TTCap' entry follows the general syntax
and should be specified before the filename.
The most useful TTCap option is used to specify the face number to use
with TTCs; it carries the name `
fn'. This means that face 2 of font
mincho.ttc' is specified using:
More information on the TTCap syntax, and on X-TrueType in general, may be found on
The CID-keyed font format was designed by Adobe Systems for fonts with large character sets. It is described in the Adobe Technical Notes nr. 5092, "Overview of the CID-Keyed Font Technology," nr. 5014, "CMap and CIDFont File Format Specification," and others, available from
Sample CID-keyed fonts can be found at:
Support for CID-keyed fonts in XFree86 is controlled by the two switches `
BuildCIDFonts. Make sure that those switches are turned on (in the directory
xc/config/cf) when XFree86 is built. By default, they should be set to
YES, unless you are building XFree86 for a small memory footprint, in which case they should be set to
The CID-keyed font backend does not use the `fontenc' layer, but instead uses the standard `CMap' method of recoding CID-keyed fonts.
As shown in the sample install file
/usr/X11R6/lib/X11/XF86Config.eg, the font directory CID
should be specified as part of the XFree86 font path:
in the `
XF86Config' file. When the CID font directory is on the font path it must contain at least the empty files fonts.dir and fonts.scale. Sample `
fonts.dir' and `
fonts.scale' files, with 0 entries, are installed by default.
A sample CID-keyed font is provided in the file:
The test directory was given the same name as the CID font directory, because it shows how a CID-keyed font should be installed. It contains a number of subdirectories, and any CID font directory should have the same directory structure.
When installing CID-keyed fonts, the empty fonts.scale and fonts.dir files in the directory:
should be replaced by
fonts.dirfiles with a number of entries of the form:
(the font file name and the XLFD name should be on the same line). Note that the first column does not specify an actual filename; instead, it specifies the PostScript name of the CID-keyed font, followed by the extension `
.cid'. The actual names of the files used will be derived from this PostScript name.
CID-keyed fonts are divided in groups by character collection. For example, the Korean font:
is in a subdirectory `
The PostScript name of a CID-keyed font consists of two parts, the CIDFontName and the CMapName, separated by two dashes. For instance, in the case of the font name
the CIDFontName is `
Munhwa-Regular' while the CMapName is `
Each CID-keyed font consist of a CIDFont file and one or more CMap files. The CIDFont file contains the description of each character in a font. It is stored in the subdirectory CIDFont of the Adobe-Korea1 directory. The directory structure looks as following:
The file `
Munhwa-Regular.afm' is an Adobe Font Metric File (AFM). The directory `
CFM' will be used for summaries of that font metric file, which will be computed later.
When the CID-keyed files are installed you can run the utility
to create the summaries of font metric file (
*.cfm), and to put them in appropriate subdirectories. By default, the program works on the directory:
A different directory can be specified on the command line of `
mkcfm' should be run as root, as it needs to write its output to
a system directory. If the program determines that it cannot write in
the designated `
CFM' subdirectories, it will display a message,
and switch to current directory.
mkcfm' is run, opening large CID-keyed fonts will take a
significant amount of time. `
mkcfm' should be run again whenever a
change is made to any of the CID-keyed fonts, or when the CID-keyed
fonts are copied to a machine with a different architecture.
The current version of the CID-keyed fonts backend only supports
the CMaps used for horizontal text (e.g. the CMap
KSC-EUC-H' will be used, but not `
limitation is due to the fact that the core X11 protocol only provides
support for horizontal writing.