Fonts in XFree86 Juliusz Chroboczek, Juliusz.Chroboczek@ens.fr 5 March 2000 XFree86 contains a number of improvements related to fonts, including o inclusion of new fonts; o internationalisation of the scalable font backends (Type 1, Speedo, and TrueType); o support for TrueType fonts; o support for CID-keyed fonts. This document describes these improvements. It does not attempt to describe the standard support for fonts in X11; the reader is referred to the X(1), Xserver(1), and mkfontdir(1) manpages. 1. Background and terminology 1.1 Characters and glyphs A character is an abstract unit of a writing system. Examples of characters include the Latin capital letter A, the Arabic letter jim, and the dingbat black scissors. A glyph is a shape that may represent one or many characters when displayed by a window system or printed by a printer. While glyphs roughly correspond to characters in most cases, this correspon- dence is not, in general, one to one. For example, a font may have many vari- ant forms of the capital letter A; a single fi ligature may correspond to the letters f and i. A coded character set is a set of characters together with a mapping from integer codes -- known as codepoints -- to characters. Examples of coded character sets include US-ASCII, ISO 8859-1, KOI8-R, and JIS X 0208(1990). A coded character set need not use 8-bit integers to index characters. Many early mainframes used 6-bit character sets, while 16-bit (or more) character sets are necessary for ideographic writing systems. 1.2 Font files, fonts, and XLFD Traditionally, typographers speak about typefaces and founts (we use the tra- ditional British spelling to distinguish founts from digital fonts). A type- face is a particular style or design, such as Times Italic, while a fount is a molten-lead incarnation of a given typeface at a given size. Digital fonts come in font files. A font file contains all the information necessary for generating glyphs of a given typeface, and applications using font files may access glyph information in arbitrary order. Digital fonts may consist of bitmap data, in which case they are said to be bitmap fonts. They may also consist of a mathematical description of glyph shapes, in which case they are said to be scalable fonts. Common formats for scalable font files are Type 1 (sometimes incorrectly called ATM fonts or PostScript fonts), Speedo and TrueType. The glyph data in a digital font needs to be indexed somehow. How this is done depends on the font file format. In the case of Type 1 fonts, glyphs are identified by glyph names. In the case of TrueType fonts, glyphs are indexed by integers corresponding to one of a number of indexing schemes (usually Unicode --- see below). The X11 system uses the data in font file to generate font instances, which are collections of glyphs at a given size indexed according to a given encod- ing. X11 font instances are specified using a notation known as the X Logi- cal Font Description (XLFD). An XLFD starts with a dash `-', and consists of fourteen fields separated by dashes, for example -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1 Or particular interest are the last two fields `iso8859-1', which specify the font instance's encoding. 1.3 Unicode Unicode () is a coded character set with the goal of uniquely identifying all characters for all scripts, current and histori- cal. While Unicode was explicitly not designed as a glyph encoding scheme, it is often possible to use it as such. Unicode is an open character set, in that codepoint assignments may be added to Unicode at any time (once specified, though, an assignment can never be changed). For this reason, a Unicode font will be sparse, and only define glyphs for a subset of the character registry of Unicode. The Unicode standard is defined in parallel with ISO 10646. Assignments in the two standards are always equivalent, and this document uses the terms ``Unicode'' and ``ISO 10646'' interchangeably. When used in X11, Unicode-encoded fonts should have the last two fields of their XLFD set to `iso10646-1'. 2. New fonts 2.1 Bitmap fonts XFree86 includes two new Unicode-encoded fonts with a large collection of non-ideographic glyphs. While it is possible to use these fonts as main fonts, applications may also use them as fallbacks when a given glyph is not available in the current font. 2.1.1 The Unicode `fixed' font The font file /usr/X11/lib/X11/fonts/misc/6x13.pcf.gz with XLFD -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 is a Unicode-encoded version of the standard `fixed' font with added support for the Latin, Greek, Cyrillic, Georgian, Armenian, IPA and other scripts plus numerous technical symbols. It contains over 2800 characters, covering all characters of ISO 8859 parts 1-5, 7-10, 13-15, as well as all European IBM and Microsoft code pages, KOI8, WGL4, and the repertoires of many other character sets. This font is compatible with the standard 8-bit fixed font and therefore also includes the DEC line-drawing glyphs in the range 0x00 to 0x1F, which are not part of Unicode or ISO 10646-1. An ISO 8859-1 version of this font is still available in file /usr/X11/lib/X11/fonts/misc/6x13-ISO8859-1.pcf.gz with XLFD -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1 The standard aliases `fixed' and `6x13' still point at the ISO 8859-1 ver- sions of the font. 2.1.2 The ClearlyU Unicode font The ClearlyU font set of fonts provides a set of 12pt, 100dpi proportional fonts with many of the glyphs needed for Unicode text. Together, the fonts contain over 4000 glyphs. The main ClearlyU font has XLFD name -mutt-ClearlyU-medium-r-normal--17-120-100-100-p-101-iso10646-1 and resides in the font file /usr/X11/lib/X11/fonts/misc/cu12.pcf.gz Additional ClearlyU fonts include -mutt-ClearlyU Alternate Glyphs-medium-r-normal--17-120-100-100-p-91-iso10646-1 -mutt-ClearlyU Arabic Extra-medium-r-normal--17-120-100-100-p-103-fontspecific-0 -mutt-ClearlyU Ligature-medium-r-normal--17-120-100-100-p-141-fontspecific-0 -mutt-ClearlyU PUA-medium-r-normal--17-120-100-100-p-111-iso10646-1 2.2 Scalable fonts XFree86 includes the ``Lucidux'' family of Type 1 fonts. This family con- sists of the fonts ``Lucidux Serif'', with XLFD -b&h-lucidux serif-medium-*-normal--*-*-*-*-p-*-*-* ``Lucidux Sans'', with XLFD -b&h-lucidux sans-medium-*-normal--*-*-*-*-p-*-*-* and ``Lucidux Mono'', with XLFD -b&h-lucidux mono-medium-*-normal--*-*-*-*-m-*-*-* Each of these fonts currently comes in Roman and oblique variants (bold vari- ants will be included in a future release) and has 337 glyphs covering the basic ``ASCII'' glyph set, the Latin 1 glyph set, as well as the ``Extended Latin'' glyph set. In particular, these fonts include all the glyphs needed for ISO 8859 parts 1, 2, 3, 4, 9 and 15. The Lucidux fonts are original designs by Charles Bigelow and Kris Holmes. Lucidux fonts include seriffed, sans-serif, and monospaced styles which share the same stem weight, x-height, capital height, ascent and descent. Lucidux fonts harmonise with Lucida (R) fonts of the same vertical proportions and weights. The character width metrics of Lucidux roman fonts match those of core fonts bundled with several window systems. Each PFA file has a copy of the license terms in PS comment lines. The license terms are also included in the file COPYRIGHT.BH for convenience, and in the License document. The design and font outlines were donated by Charles Bigelow and Kris Holmes from Bigelow and Holmes Inc., and the hinting was donated by Berthold Horn and Blenda Horn from Y&Y, Inc. For more information, please contact or , or consult Y&Y's web site . 3. Internationalisation of scalable font backends. The scalable font backends (Type 1, Speedo, TrueType) can now automatically re-encode fonts to the encoding specified in the XLFD in `fonts.dir'. For example, a `fonts.dir' file can now contain entries for the Type 1 Courier font such as cour.pfa -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1 cour.pfa -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-2 which will lead to the font being recoded to ISO 8859-1 and ISO 8859-2 respectively. 3.1 The `fontenc' layer Three of the scalable backends (Type 1, Speedo, and the `freetype' TrueType backend) use a common `fontenc' layer for font re-encoding. This allows those 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 does not use the `fontenc' layer, but instead uses its own method for font reencoding. Readers only interested in X-TT may want to skip to Using Symbol Fonts (section 3.5, page 1), as the intervening information does not apply to X-TT. X-TT itself is described in more detail in X-TrueType (section 4.1.2, page 1). In the `fontenc' layer, an encoding is defined by a name (such as `iso8859-1'), eventually 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 the `fontenc' layer; currently, those consist of Unicode, Adobe glyph names, and arbitrary True- Type `cmap's. A number of encodings are hardwired into `fontenc', and are therefore always available; the hardcoded encodings cannot easily be redefined. These include: o `iso10646-1': Unicode; o `iso8859-1': ISO Latin-1 (Western Europe); o `iso8859-2': ISO Latin-2 (Eastern Europe); o `iso8859-3': ISO Latin-3 (Southern Europe); o `iso8859-4': ISO Latin-4 (Northern Europe); o `iso8859-5': ISO Cyrillic; o `iso8859-6': ISO Arabic; o `iso8859-7': ISO Greek; o `iso8859-8': ISO Hebrew; o `iso8859-9': ISO Latin-5 (Turkish); o `iso8859-10': ISO Latin-6 (Nordic); o `iso8859-15': ISO Latin-9, or Latin-0 (Revised Western-European); o `koi8-r': KOI8 Russian; o `koi8-u': KOI8 Ukrainian (see RFC 2319); o `koi8-ru': KOI8 Russian/Ukrainian o `koi8-uni': KOI8 ``Unified'' (Russian, Ukrainian, and Byelorussian); o `koi8-e': KOI8 `European', ISO-IR-111, or ECMA-Cyrillic; o `microsoft-symbol' and `apple-roman': these are only likely to be use- ful with TrueType symbol fonts. New 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 the directory with `fonts.dir'!) for a file named `encodings.dir'. If found, this file is scanned for the unknown encoding, and the requested encoding definition file is read in. The mkfontdir(1) utility, when invoked with the `-e' option fol- lowed by the name of a directory containing encoding files, can be used to automatically build `encodings.dir' files. See the mkfontdir(1) manpage for more details. A number of predefined encoding files have been included with the distribu- tion. Information on writing new encoding files can be found in Format of encodings directory files (section 3.3, page 1) and Format of encodings files (section 3.4, page 1). 3.2 Backend-specific notes about fontenc 3.2.1 Type 1 The Type 1 backend first searches for a mapping with a target of PostScript. If one is found, it is used. If none is found, the backend searches for a mapping with target Unicode, which is then composed with a built-in table mapping codes to glyph names. Note that this table only covers part of the Unicode code points that have been assigned names by Adobe. If neither a PostScript or Unicode mapping is found, the backend defaults to ISO 8859-1. Specifying an encoding value of `adobe-fontspecific' disables the encoding mechanism. This is useful with symbol and wrongly encoded fonts (see below). The Type 1 backend currently limits all encodings to 8-bit codes. 3.2.2 Speedo The Speedo backend searches for a mapping with a target of Unicode, and uses it if found. If none is found, the backend defaults to ISO 8859-1. The Speedo backend limits all encodings to 8-bit codes. 3.2.3 The `freetype' TrueType backend The TrueType backend scans the mappings in order. Mappings with a target of PostScript are ignored; mappings with a TrueType or Unicode target are checked against all the cmaps in the file. The first applicable mapping is used. Authors of encoding files to be used with the TrueType backend should ensure that mappings are mentioned in decreasing order of preference. 3.3 Format of encodings directory files In order to use a font in an encoding that the font backend does not know about, you need to have a `encodings.dir' file in the same directory as the font file used. `encodings.dir' has the same format as `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 encodings/mulearabic-0.enc mulearabic-1 encodings/mulearabic-1.enc mulearabic-2 encodings/mulearabic-2.enc Note that 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 com- pressed or gzipped. `encoding.dir' files are best maintained by the mkfontdir(1) utility. Please see the mkfontdir(1) manpage for more information. 3.4 Format of encoding files The encoding files are ``free form,'' i.e. any string of whitespace is equiv- alent 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 eventually its alternate names (aliases): STARTENCODING mulearabic-0 ALIAS arabic-0 ALIAS something-else The names of the encoding should be suitable for use in an XLFD font name, and therefore contain exactly one dash `-'. The encoding file may then optionally declare the size of the encoding. For a linear encoding (such as Mule Arabic, or ISO 8859-1), the SIZE line speci- fies the maximum code plus one: SIZE 0x2B For a matrix encoding, it should specify two numbers. The first is the num- ber of the last row plus one, the other, the highest column number plus one. For example, in the case of `jisx0208.1990-0' (JIS X 0208(1990), double-byte encoding, high bit clear), it should be SIZE 0x75 0x80 Codes outside the region defined by the size line are supposed to be unde- fined. 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: o Unicode (ISO 10646): STARTMAPPING unicode o a given TrueType `cmap': STARTMAPPING cmap 3 1 o PostScript glyph names STARTMAPPING postscript Every line in a mapping section maps one from the encoding being defined to the target of the mapping. In mappings with a Unicode or TrueType mapping, codes are mapped to codes: 0x21 0x0660 0x22 0x0661 ... As an abbreviation, it is possible to map a contiguous range of codes in a single line. A line consisting of three integers start end target is an abbreviation for the range of lines start target start+1 target+1 ... end target+end-start For example, the line 0x2121 0x215F 0x8140 is an abbreviation for 0x2121 0x8140 0x2122 0x8141 ... 0x215F 0x817E Codes not listed are assumed to map through the identity (i.e. to the same numerical value). In order to override this default mapping, you may specify a range of codes to be undefined by using an `UNDEFINE' line: UNDEFINE 0x00 0x2A or, for a single code UNDEFINE 0x1234 This works because later values override earlier one. PostScript mappings are different. Every line in a PostScript mapping maps a code to a glyph name 0x41 A 0x42 B ... and codes not explicitly listed are undefined. A mapping section ends with an ENDMAPPING line ENDMAPPING After all the mappings have been defined, the file ends with an ENDENCODING line ENDENCODING Lines of the form UNASSIGNED 0x00 0x1F or UNASSIGNED 0x1234 are ignored by the server, but may be used by supporting utilities. In order to make future extensions to the format possible, lines starting with an unknown keyword are ignored, as are mapping sections with an unknown target. 3.5 Using symbol fonts Type 1 symbol fonts should be installed using the `adobe-fontspecific' encod- ing. 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 True- Type 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'. 3.6 Using badly encoded font files A number of text fonts are incorrectly encoded. Incorrect encoding is some- times done by design, in order to make a font for an exotic script appear like an ordinary Western text font. It is often due to the font designer's laziness or incompetence; in particular, 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. Of course, most of the time the proper fix would be to hit the font designer very hard on the head with the PLRM (preferably the first edition, as it was published in hardcover). 3.6.1 Using fonts with the designer's encoding In the case of Type 1 fonts, the font designer can specify a default encod- ing; this encoding is requested by using the `adobe-fontspecific' encoding in the XLFD name. Sometimes, the font designer omitted to specify a reasonable default encoding; in this case, you should experiment with `adobe-standard', `iso8859-1', `microsoft-cp1252', and `microsoft-win3.1', (`microsoft-symbol' doesn't make sense for Type 1 fonts). TrueType fonts do not have a default encoding, and use of the Microsoft Sym- bol encoding yields strange results with text fonts on some (non-X11) plat- forms. However, most TrueType fonts are designed with either Microsoft or Apple platforms in mind, so one of `microsoft-cp1252', `microsoft-win3.1', or `apple-roman' should yield reasonable results. 3.6.2 Specifying an ad hoc encoding file It is always possible to define an encoding file to put the glyphs in a font in any desired order. Again, see the `encodingsadobe-dingbats.enc/' file to see how this is done. 3.6.3 Specifying font aliases By following the directions above, you will find yourself with a number of fonts with unusual names -- specifying encodings such as `adobe-fontspe- cific', `microsoft-win3.1' etc. In order to use these fonts with standard applications, it may be useful to remap them to their proper names. This is done by writing a `fonts.alias' file. The format of this file is sim- ilar to the format of the `fonts.dir' file, except that it maps XLFD names to XLFD names. A `fonts.alias' file might look as follows: 1 "-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" (both XLFD names on a single line). The syntax of the `fonts.alias' file is described in the mkfontdir(1) manual page. 4. New font backends 4.1 New TrueType backends 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 `freetype'. Before using it, please check that the `Module' section of your `XF86Config' file contains a line that reads Load "freetype" 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 Load "xtt" 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 aver- age 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 speci- fying a character-cell spacing `c', as in -misc-mincho-medium-r-normal--0-0-0-0-c-0-jisx0208.1990-0 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. 4.1.1 The `freetype' TrueType backend The `freetype' backend (formerly `xfsft') is a backend based on the FreeType library (see www.freetype.org) with support for the `fontenc' style of inter- nationalisation (see The fontenc layer (section 3.1, page 1)). This backend supports TrueType Font files (*.ttf) and TrueType Collections (*.ttc). 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, :2:mincho.ttc -misc-mincho-medium-r-normal--0-0-0-0-c-0-jisx0208.1990-0 refers to face 2 in the `mincho.ttc' TrueType Collection file. 4.1.2 The `X-TrueType' TrueType backend 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 :option=value: 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 file `min- cho.ttc' is specified using: :fn=2:mincho.ttc -misc-mincho-medium-r-normal--0-0-0-0-c-0-jisx0208.1990-0 More information on the TTCap syntax, and on X-TrueType in general, may be found on 4.2 Support for CID-keyed fonts 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 `BuildCID' and 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 NO. The CID-keyed font backend does not use the `fontenc' layer, but instead uses the standard `CMap' method of recoding CID-keyed fonts. 4.2.1 Using 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: FontPath "/usr/X11R6/lib/X11/fonts/CID/" 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: test/xsuite/xtest/CID 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: xc/fonts/scaled/CID should be replaced by fonts.scale and fonts.dir files with a number of entries of the form: 1 Adobe-Korea1/Munhwa-Regular--Adobe-Korea1-0.cid \ -adobe-munhwa-medium-r-normal--0-0-0-0-p-0-adobe.korea1-0 (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: Munhwa-Regular--Adobe-Korea1-0 is in a subdirectory `Adobe-Korea1'. The PostScript name of a CID-keyed font consists of two parts, the CIDFont- Name and the CMapName, separated by two dashes. For instance, in the case of the font name Munhwa-Regular--Adobe-Korea1-0 the CIDFontName is `Munhwa-Regular' while the CMapName is `Adobe-Korea1'. 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 direc- tory structure looks as following: CID/Adobe-Korea1/CIDFont/Munhwa-Regular CID/Adobe-Korea1/CMap/Adobe-Korea1-0 CID/Adobe-Korea1/AFM/Munhwa-Regular.afm CID/Adobe-Korea1/CFM CID/fonts.dir CID/fonts.scale The file `Munhwa-Regular.afm' is an Adobe Font Metric File (AFM). The direc- tory `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 /usr/X11R6/bin/mkcfm to create the summaries of font metric file (*.cfm), and to put them in appropriate subdirectories. By default, the program works on the directory: /usr/X11R6/lib/X11/fonts/CID A different directory can be specified on the command line of `mkcfm.' `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 direc- tory. Unless `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. 4.2.2 Limitations 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 `KSC-EUC-V'). This limitation is due to the fact that the core X11 protocol only provides support for horizontal writing. Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/fonts.sgml,v 1.7 2000/03/06 22:59:25 dawes Exp $