X Logical Font Description Conventions

Version 1.5

X Consortium Standard

X Version 11, Release 6.4

Jim Flowers
Digital Equipment Corporation

Version 1.5 edited by Stephen Gildea
X Consortium, Inc.

X Window System is a trademark of X Consortium, Inc.

Helvetica and Times are registered trademarks of Linotype Company.

ITC Avant Garde Gothic is a registered trademark of International Typeface Corporation.

Times Roman is a registered trademark of Monotype Corporation.

Bitstream Amerigo is a registered trademark of Bitstream Inc.

Stone is a registered trademark of Adobe Systems Inc.

Copyright © 1988, 1994 X Consortium

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Except as contained in this notice, the name of the X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium.

Copyright © 1988, 1989 Digital Equipment Corporation, Maynard MA. All rights reserved.

Permission to use, copy, modify, and distribute this documentation for any purpose and without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. Digital Equipment Corporation makes no representations about the suitability for any purpose of the information in this document. This documentation is provided as is without express or implied warranty.

1. IntroductionIt is a requirement that X client applications must be portable acrossserver implementations, with very different file systems, namingconventions, and font libraries. However, font access requests, asdefined by the X Window System Protocol, neither specifyserver-independent conventions for font names nor provide adequate fontproperties for logically describing typographic fonts.X clients must be able to dynamically determine the fonts available onany given server so that understandable information can be presented tothe user or so that intelligent font fallbacks can be chosen. It isdesirable for the most common queries to be accomplished without theoverhead of opening each font and inspecting font properties, by meansof simple ListFonts requests. For example, if a user selected aHelvetica typeface family, a client application should be able to querythe server for all Helvetica fonts and present only those setwidths,weights, slants, point sizes, and character sets available for thatfamily.This document gives a standard logical font description (hereafterreferred to as XLFD) and the conventions to be used in the core protocolso that clients can query and access screen type libraries in aconsistent manner across all X servers. In addition to completelyspecifying a given font by means of its FontName, the XLFD also providesfor a standard set of key FontProperties that describe the font in moredetail.The XLFD provides an adequate set of typographic font properties, suchas CAP_HEIGHT, X_HEIGHT, and RELATIVE_SETWIDTH, for publishing and otherapplications to do intelligent font matching or substitution whenhandling documents created on some foreign server that use potentiallyunknown fonts. In addition, this information is required by certainclients to position subscripts automatically and determine small capitalheights, recommended leading, word-space values, and so on.2. Requirements and GoalsThe XLFD meets the short-term and long-term goals to have a standardlogical font description that:• Provides unique, descriptive font names that support simple patternmatching• Supports multiple font vendors, arbitrary character sets, andencodings• Supports naming and instancing of scalable and polymorphic fonts• Supports transformations and subsetting of fonts• Is independent of X server and operating or file systemimplementations• Supports arbitrarily complex font matching or substitution• Is extensible2.1. Provide Unique and Descriptive Font NamesIt should be possible to have font names that are long enough anddescriptive enough to have a reasonable probability of being uniquewithout inventing a new registration organization. Resolution andsize-dependent font masters, multivendor font libraries, and so on mustbe anticipated and handled by the font name alone.The name itself should be structured to be amenable to simple patternmatching and parsing, thus allowing X clients to restrict font queriesto some subset of all possible fonts in the server.2.2. Support Multiple Font Vendors and Character SetsThe font name and properties should distinguish between fonts that weresupplied by different font vendors but that possibly share the samename. We anticipate a highly competitive font market where users willbe able to buy fonts from many sources according to their particularrequirements.A number of font vendors deliver each font with all glyphs designed forthat font, where charset mappings are defined by encoding vectors. Someserver implementations may force these mappings to proprietary orstandard charsets statically in the font data. Others may desire toperform the mapping dynamically in the server. Provisions must be madein the font name that allows a font request to specify or identifyspecific charset mappings in server environments where multiple charsetsare supported.2.3. Support Scalable and Polymorphic FontsIf a font source can be scaled to an arbitrary size or varied in otherways, it should be possible for an application to determine that factfrom the font name, and the application should be able to construct afont name for any specific instance.2.4. Support Transformations and Subsetting of FontsArbitrary two-dimensional linear transformations of fonts should be ableto be requested by applications. Since such transformed fonts may beused for special effects requiring a few characters from each of manydifferently transformed fonts, it should be possible to request only afew characters from a font for efficiency.2.5. Be Independent of X Server and Operating or File SystemImplementationsX client applications that require a particular font should be able touse the descriptive name without knowledge of the file system or otherrepository in use by the server. However, it should be possible forservers to translate a given font name into a file name syntax that itknows how to deal with, without compromising the uniqueness of the fontname. This algorithm should be reversible (exactly how this translationis done is implementation dependent).2.6. Support Arbitrarily Complex Font Matching and SubstitutionIn addition to the font name, the XLFD should define a standard list ofdescriptive font properties, with agreed-upon fallbacks for all fonts.This allows client applications to derive font-specific formatting ordisplay data and to perform font matching or substitution when asked tohandle potentially unknown fonts, as required.2.7. Be ExtensibleThe XLFD must be extensible so that new and/or private descriptive fontproperties can be added to conforming fonts without making existing Xclient or server implementations obsolete.3. X Logical Font DescriptionXLFD is divided into two basic components: the FontName, which gives allfont information needed to uniquely identify a font in X protocolrequests (for example, OpenFont, ListFonts, and so on) and a variablelist of optional FontProperties, which describe a font in more detail.The FontName is used in font queries and is returned as data in certainX protocol requests. It is also specified as the data value for theFONT item in the X Consortium Character Bitmap Distribution FormatStandard (BDF V2.1).The FontProperties are supplied on a font-by-font basis and are returnedas data in certain X protocol requests as part of the XFontStruct datastructure. The names and associated data values for each of theFontProperties may also appear as items of theSTARTPROPERTIES...ENDPROPERTIES list in the BDF V2.1 specification.3.1. FontNameEach FontName is logically composed of two strings: a FontNameRegistryprefix that is followed by a FontNameSuffix. The FontName uses the ISO8859-1 encoding. The FontNameRegistry is an x-registered-name (a namethat has been registered with the X Consortium) that identifies theregistration authority that owns the specified FontNameSuffix syntax andsemantics.All font names that conform to this specification are to use aFontNameRegistry prefix, which is defined to be the string "−" (HYPHEN).All FontNameRegistry prefixes of the form: +version−, where thespecified version indicates some future XLFD specification, are reservedby the X Consortium for future extensions to XLFD font names. Ifrequired, extensions to the current XLFD font name shall be constructedby appending new fields to the current structure, each delimited by theexisting field delimiter. The availability of other FontNameRegistryprefixes or fonts that support other registries is server implementationdependent.In the X protocol specification, the FontName is required to be astring; hence, numeric field values are represented in the name asstring equivalents. All FontNameSuffix fields are also defined asFontProperties; numeric property values are represented as signed orunsigned integers, as appropriate.3.1.1. FontName SyntaxThe FontName is a structured, parsable string (of type STRING8) whoseBackus-Naur Form syntax description is as follows:Field values are constructed as strings of ISO 8859-1 graphiccharacters, excluding the following:• "−" (HYPHEN), the XLFD font name delimiter character• "?" (QUESTION MARK) and "*" (ASTERISK), the X protocol font namewildcard characters• "," (COMMA), used by Xlib to separate XLFD font names in a fontset.• """ (QUOTATION MARK), used by some commercial products to quote afont name.Alphabetic case distinctions are allowed but are for human readabilityconcerns only. Conforming X servers will perform matching on font namequery or open requests independent of case. The entire font name stringmust have no more than 255 characters. It is recommended that clientsconstruct font name query patterns by explicitly including all fielddelimiters to avoid unexpected results. Note that SPACE is a validcharacter of a FontName field; for example, the string "ITC Avant GardeGothic" might be a FAMILY_NAME.3.1.2. FontName Field DefinitionsThis section discusses the FontName:• FOUNDRY field• FAMILY_NAME field• WEIGHT_NAME field• SLANT field• SETWIDTH_NAME field• ADD_STYLE_NAME field• PIXEL_SIZE field• POINT_SIZE field• RESOLUTION_X and RESOLUTION_Y fields• SPACING field• AVERAGE_WIDTH field• CHARSET_REGISTRY and CHARSET_ENCODING fields3.1.2.1. FOUNDRY FieldFOUNDRY is an x-registered-name, the name or identifier of the digitaltype foundry that digitized and supplied the font data, or if different,the identifier of the organization that last modified the font shape ormetric information.The reason this distinction is necessary is that a given font design maybe licensed from one source (for example, ITC) but digitized and sold byany number of different type suppliers. Each digital version of theoriginal design, in general, will be somewhat different in metrics andshape from the idealized original font data, because each font foundry,for better or for worse, has its own standards and practices fortweaking a typeface for a particular generation of output technologiesor has its own perception of market needs.It is up to the type supplier to register with the X Consortium asuitable name for this FontName field according to the registrationprocedures defined by the Consortium.The X Consortium shall define procedures for registering foundry andother names and shall maintain and publish, as part of its publicdistribution, a registry of such registered names for use in XLFD fontnames and properties.3.1.2.2. FAMILY_NAME FieldFAMILY_NAME is a string that identifies the range or family of typefacedesigns that are all variations of one basic typographic style. Thismust be spelled out in full, with words separated by spaces, asrequired. This name must be human-understandable and suitable forpresentation to a font user to identify the typeface family.It is up to the type supplier to supply and maintain a suitable stringfor this field and font property, to secure the proper legal title to agiven name, and to guard against the infringement of other’s copyrightsor trademarks. By convention, FAMILY_NAME is not translated.FAMILY_NAME may include an indication of design ownership if considereda valid part of the typeface family name.The following are examples of FAMILY_NAME:• Helvetica• ITC Avant Garde Gothic• Times• Times Roman• Bitstream Amerigo• Stone3.1.2.3. WEIGHT_NAME FieldWEIGHT_NAME is a string that identifies the font’s typographic weight,that is, the nominal blackness of the font, according to the FOUNDRY’sjudgment. This name must be human-understandable and suitable forpresentation to a font user. The value "0" is used to indicate apolymorphic font (see section 6).The interpretation of this field is somewhat problematic because thetypographic judgment of weight has traditionally depended on the overalldesign of the typeface family in question; that is, it is possible thatthe DemiBold weight of one font could be almost equivalent intypographic feel to a Bold font from another family.WEIGHT_NAME is captured as an arbitrary string because it is animportant part of a font’s complete human-understandable name. However,it should not be used for font matching or substitution. For thispurpose, X client applications should use the weight-related fontproperties (RELATIVE_WEIGHT and WEIGHT) that give the coded relativeweight and the calculated weight, respectively.3.1.2.4. SLANT FieldSLANT is a code-string that indicates the overall posture of thetypeface design used in the font. The encoding is as follows:The SLANT codes are for programming convenience only and usually areconverted into their equivalent human-understandable form before beingpresented to a user.3.1.2.5. SETWIDTH_NAME FieldSETWIDTH_NAME is a string that gives the font’s typographicproportionate width, that is, the nominal width per horizontal unit ofthe font, according to the FOUNDRY’s judgment. The value "0" is used toindicate a polymorphic font (see section 6).As with WEIGHT_NAME, the interpretation of this field or font propertyis somewhat problematic, because the designer’s judgment of setwidth hastraditionally depended on the overall design of the typeface family inquestion. For purposes of font matching or substitution, X clientapplications should either use the RELATIVE_SETWIDTH font property thatgives the relative coded proportionate width or calculate theproportionate width.The following are examples of SETWIDTH_NAME:• Normal• Condensed• Narrow• Double Wide3.1.2.6. ADD_STYLE_NAME FieldADD_STYLE_NAME is a string that identifies additional typographic styleinformation that is not captured by other fields but is needed toidentify the particular font. The character "[" anywhere in the fieldis used to indicate a polymorphic font (see section 6).ADD_STYLE_NAME is not a typeface classification field and is only usedfor uniqueness. Its use, as such, is not limited to typographic styledistinctions.The following are examples of ADD_STYLE_NAME:• Serif• Sans Serif• Informal• Decorated3.1.2.7. PIXEL_SIZE FieldPIXEL_SIZE gives the body size of the font at a particular POINT_SIZEand RESOLUTION_Y. PIXEL_SIZE is either an integer-string or a stringbeginning with "[". A string beginning with "[" represents a matrix(see section 4). PIXEL_SIZE usually incorporates additional verticalspacing that is considered part of the font design. (Note, however,that this value is not necessarily equivalent to the height of the fontbounding box.) Zero is used to indicate a scalable font (see section5).PIXEL_SIZE usually is used by X client applications that need to queryfonts according to device-dependent size, regardless of the point sizeor vertical resolution for which the font was designed.3.1.2.8. POINT_SIZE FieldPOINT_SIZE gives the body size for which the font was designed.POINT_SIZE is either an integer-string or a string beginning with "[".A string beginning with "[" represents a matrix (see section 4). Thisfield usually incorporates additional vertical spacing that isconsidered part of the font design. (Note, however, that POINT_SIZE isnot necessarily equivalent to the height of the font bounding box.)POINT_SIZE is expressed in decipoints (where points are as defined inthe X protocol or 72.27 points equal 1 inch). Zero is used to indicatea scalable font (see section 5).POINT_SIZE and RESOLUTION_Y are used by X clients to query fontsaccording to device-independent size to maintain constant text size onthe display regardless of the PIXEL_SIZE used for the font.3.1.2.9. RESOLUTION_X and RESOLUTION_Y FieldsRESOLUTION_X and RESOLUTION_Y are unsigned integer-strings that give thehorizontal and vertical resolution, measured in pixels or dots per inch(dpi), for which the font was designed. Zero is used to indicate ascalable font (see section 5). Horizontal and vertical values arerequired because a separate bitmap font must be designed for displayswith very different aspect ratios (for example, 1:1, 4:3, 2:1, and soon).The separation of pixel or point size and resolution is necessarybecause X allows for servers with very different video characteristics(for example, horizontal and vertical resolution, screen and pixel size,pixel shape, and so on) to potentially access the same font library.The font name, for example, must differentiate between a 14-point fontdesigned for 75 dpi (body size of about 14 pixels) or a 14-point fontdesigned for 150 dpi (body size of about 28 pixels). Further, inservers that implement some or all fonts as continuously scaled andscan-converted outlines, POINT_SIZE and RESOLUTION_Y will help theserver to differentiate between potentially separate font masters fortext, title, and display sizes or for other typographic considerations.3.1.2.10. SPACING FieldSPACING is a code-string that indicates the escapement class of thefont, that is, monospace (fixed pitch), proportional (variable pitch),or charcell (a special monospaced font that conforms to the traditionaldata-processing character cell font model). The encoding is as follows:3.1.2.11. AVERAGE_WIDTH FieldAVERAGE_WIDTH is an integer-string typographic metric value that givesthe unweighted arithmetic mean of the absolute value of the width ofeach glyph in the font (measured in tenths of pixels), multiplied by −1if the dominant writing direction for the font is right-to-left. Aleading "~" (TILDE) indicates a negative value. For monospaced andcharacter cell fonts, this is the width of all glyphs in the font. Zerois used to indicate a scalable font (see section 5).3.1.2.12. CHARSET_REGISTRY and CHARSET_ENCODING FieldsThe character set used to encode the glyphs of the font (and implicitlythe font’s glyph repertoire), as maintained by the X Consortiumcharacter set registry. CHARSET_REGISTRY is an x-registered-name thatidentifies the registration authority that owns the specified encoding.CHARSET_ENCODING is a registered name that identifies the codedcharacter set as defined by that registration authority and, optionally,a subsetting hint.Although the X protocol does not explicitly have any knowledge aboutcharacter set encodings, it is expected that server implementors willprefer to embed knowledge of certain proprietary or standard charsetsinto their font library for reasons of performance and convenience. TheCHARSET_REGISTRY and CHARSET_ENCODING fields or properties allow an Xclient font request to specify a specific charset mapping in serverenvironments where multiple charsets are supported. The availability ofany particular character set is font and server implementationdependent.To prevent collisions when defining character set names, it isrecommended that CHARSET_REGISTRY and CHARSET_ENCODING name pairs beconstructed according to the following conventions:The X Consortium shall maintain and publish a registry of such characterset names for use in X protocol font names and properties as specifiedin XLFD.The ISO Latin-1 character set shall be registered by the X Consortium asthe CHARSET_REGISTRY-CHARSET_ENCODING value pair: "ISO8859-1".If the CHARSET_ENCODING contains a "[" (LEFT SQUARE BRACKET), the "["and the characters after it up to a "]" (RIGHT SQUARE BRACKET) are asubsetting hint telling the font source that the client is interestedonly in a subset of the characters of the font. The font source can,optionally, return a font that contains only those characters or anysuperset of those characters. The client can expect to obtain validglyphs and metrics only for those characters, and not for any othercharacters in the font. The font properties may optionally becalculated by considering only the characters in the subset.The BNF for the subsetting hint isEach Range specifies characters that are to be part of the subsetincluded in the font. A Range containing two Numbers specifies thefirst and last character, inclusively, of a range of characters. ARange that is a single Number specifies a single character to beincluded in the font. A HexNumber is interpreted as a hexadecimalnumber. A DecNumber is interpreted as a decimal number. The fontconsists of the union of all the Ranges in the RangeList.For example,-misc-fixed-medium-r-normal--0-0-0-0-c-0-iso8859-1[65 70 80_90]tells the font source that the client is interested only in characters65, 70, and 80−90.3.1.3. ExamplesThe following examples of font names are derived from the screen fontsshipped with the X Consortium distribution.3.2. Font PropertiesAll font properties are optional but will generally include the fontname fields and, on a font-by-font basis, any other useful fontdescriptive and use information that may be required to use the fontintelligently. The XLFD specifies an extensive set of standard X fontproperties, their interpretation, and fallback rules when the propertyis not defined for a given font. The goal is to provide clientapplications with enough font information to be able to make automaticformatting and display decisions with good typographic results.Font property names use the ISO 8859-1 encoding.Additional standard X font property definitions may be defined in thefuture and private properties may exist in X fonts at any time. Privatefont properties should be defined to conform to the general mechanismdefined in the X protocol to prevent overlap of name space and ambiguousproperty names, that is, private font property names are of the form:"_" (LOW LINE), followed by the organizational identifier, followed by"_" (LOW LINE), and terminated with the property name.The Backus-Naur Form syntax description of X font properties is asfollows:3.2.1. FOUNDRYFOUNDRY is as defined in the FontName except that the property type isATOM.FOUNDRY cannot be calculated or defaulted if not supplied as a fontproperty.3.2.2. FAMILY_NAMEFAMILY_NAME is as defined in the FontName except that the property typeis ATOM.FAMILY_NAME cannot be calculated or defaulted if not supplied as a fontproperty.3.2.3. WEIGHT_NAMEWEIGHT_NAME is as defined in the FontName except that the property typeis ATOM.WEIGHT_NAME can be defaulted if not supplied as a font property, asfollows:if (WEIGHT_NAME undefined) thenWEIGHT_NAME = ATOM("Medium")3.2.4. SLANTSLANT is as defined in the FontName except that the property type isATOM.SLANT can be defaulted if not supplied as a font property, as follows:if (SLANT undefined) thenSLANT = ATOM("R")3.2.5. SETWIDTH_NAMESETWIDTH_NAME is as defined in the FontName except that the propertytype is ATOM.SETWIDTH_NAME can be defaulted if not supplied as a font property, asfollows:if (SETWIDTH_NAME undefined) thenSETWIDTH_NAME = ATOM("Normal")3.2.6. ADD_STYLE_NAMEADD_STYLE_NAME is as defined in the FontName except that the propertytype is ATOM.ADD_STYLE_NAME can be defaulted if not supplied as a font property, asfollows:if (ADD_STYLE_NAME undefined) thenADD_STYLE_NAME = ATOM("")3.2.7. PIXEL_SIZEPIXEL_SIZE is as defined in the FontName except that the property typeis INT32.X clients requiring pixel values for the various typographic fixedspaces (em space, en space, and thin space) can use the followingalgorithm for computing these values from other properties specified fora font:DeciPointsPerInch = 722.7EMspace = ROUND ((RESOLUTION_X * POINT_SIZE) / DeciPointsPerInch)ENspace = ROUND (EMspace / 2)THINspace = ROUND (EMspace / 3)where a slash (/) denotes real division, an asterisk (*) denotes realmultiplication, and ROUND denotes a function that rounds its realargument a up or down to the next integer. This rounding is doneaccording to X = FLOOR (a + 0.5), where FLOOR is a function that roundsits real argument down to the nearest integer.PIXEL_SIZE can be approximated if not supplied as a font property,according to the following algorithm:DeciPointsPerInch = 722.7if (PIXEL_SIZE undefined) thenPIXEL_SIZE = ROUND ((RESOLUTION_Y * POINT_SIZE) / DeciPointsPerInch)3.2.8. POINT_SIZEPOINT_SIZE is as defined in the FontName except that the property typeis INT32.X clients requiring device-independent values for em space, en space,and thin space can use the following algorithm:EMspace = ROUND (POINT_SIZE / 10)ENspace = ROUND (POINT_SIZE / 20)THINspace = ROUND (POINT_SIZE / 30)Design POINT_SIZE cannot be calculated or approximated.3.2.9. RESOLUTION_XRESOLUTION_X is as defined in the FontName except that the property typeis CARD32.RESOLUTION_X cannot be calculated or approximated.3.2.10. RESOLUTION_YRESOLUTION_Y is as defined in the FontName except that the property typeis CARD32.RESOLUTION_X cannot be calculated or approximated.3.2.11. SPACINGSPACING is as defined in the FontName except that the property type isATOM.SPACING can be calculated if not supplied as a font property, accordingto the definitions given above for the FontName.3.2.12. AVERAGE_WIDTHAVERAGE_WIDTH is as defined in the FontName except that the propertytype is INT32.AVERAGE_WIDTH can be calculated if not provided as a font property,according to the following algorithm:if (AVERAGE_WIDTH undefined) thenAVERAGE_WIDTH = ROUND (MEAN (ABS (width of each glyph in font)) * 10)* (if (dominant writing direction L-to-R) then 1 else −1)where MEAN is a function that returns the arithmetic mean of itsarguments.X clients that require values for the number of characters per inch(pitch) of a monospaced font can use the following algorithm using theAVERAGE_WIDTH and RESOLUTION_X font properties:if (SPACING not proportional) thenCharPitch = (RESOLUTION_X * 10) / AVERAGE_WIDTH3.2.13. CHARSET_REGISTRYCHARSET_REGISTRY is as defined in the FontName except that the propertytype is ATOM.CHARSET_REGISTRY cannot be defaulted if not supplied as a font property.3.2.14. CHARSET_ENCODINGCHARSET_ENCODING is as defined in the FontName except that the propertytype is ATOM.CHARSET_ENCODING cannot be defaulted if not supplied as a font property.3.2.15. MIN_SPACEMIN_SPACE is an integer value (of type INT32) that gives the recommendedminimum word-space value to be used with this font.MIN_SPACE can be approximated if not provided as a font property,according to the following algorithm:if (MIN_SPACE undefined) thenMIN_SPACE = ROUND(0.75 * NORM_SPACE)3.2.16. NORM_SPACENORM_SPACE is an integer value (of type INT32) that gives therecommended normal word-space value to be used with this font.NORM_SPACE can be approximated if not provided as a font property,according to the following algorithm:DeciPointsPerInch = 722.7if (NORM_SPACE undefined) thenif (SPACE glyph exists) thenNORM_SPACE = width of SPACEelse NORM_SPACE = ROUND((0.33 * RESOLUTION_X * POINT_SIZE)/ DeciPointsPerInch)3.2.17. MAX_SPACEMAX_SPACE is an integer value (of type INT32) that gives the recommendedmaximum word-space value to be used with this font.MAX_SPACE can be approximated if not provided as a font property,according to the following algorithm:if (MAX_SPACE undefined) thenMAX_SPACE = ROUND(1.5 * NORM_SPACE)3.2.18. END_SPACEEND_SPACE is an integer value (of type INT32) that gives the recommendedspacing at the end of sentences.END_SPACE can be approximated if not provided as a font property,according to the following algorithm:if (END_SPACE undefined) thenEND_SPACE = NORM_SPACE3.2.19. AVG_CAPITAL_WIDTHAVG_CAPITAL_WIDTH is an integer value (of type INT32) that gives theunweighted arithmetic mean of the absolute value of the width of eachcapital glyph in the font, in tenths of pixels, multiplied by −1 if thedominant writing direction for the font is right-to-left. This propertyapplies to both Latin and non-Latin fonts. For Latin fonts, capitalsare the glyphs A through Z. This property is usually used for fontmatching or substitution.AVG_CAPITAL_WIDTH can be calculated if not provided as a font property,according to the following algorithm:if (AVG_CAPITAL_WIDTH undefined) thenif (capitals exist) thenAVG_CAPITAL_WIDTH = ROUND (MEAN(ABS (width of each capital glyph)) * 10)* (if (dominant writing direction L-to-R) then 1 else −1)else AVG_CAPITAL_WIDTH undefined3.2.20. AVG_LOWERCASE_WIDTHAVG_LOWERCASE_WIDTH is an integer value (of type INT32) that gives theunweighted arithmetic mean width of the absolute value of the width ofeach lowercase glyph in the font in tenths of pixels, multiplied by −1if the dominant writing direction for the font is right-to-left. ForLatin fonts, lowercase are the glyphs a through z. This property isusually used for font matching or substitution.Where appropriate, AVG_LOWERCASE_WIDTH can be approximated if notprovided as a font property, according to the following algorithm:if (AVG_LOWERCASE_WIDTH undefined) thenif (lowercase exists) thenAVG_LOWERCASE_WIDTH = ROUND (MEAN(ABS (width of each lowercase glyph)) * 10)* (if (dominant writing direction L-to-R) then 1 else −1)else AVG_LOWERCASE_WIDTH undefined3.2.21. QUAD_WIDTHQUAD_WIDTH is an integer typographic metric (of type INT32) that givesthe width of a quad (em) space. NoteBecause all typographic fixed spaces (em, en, and thin) areconstant for a given font size (that is, they do not varyaccording to setwidth), the use of this font property has beendeprecated. X clients that require typographic fixed spacevalues are encouraged to discontinue use of QUAD_WIDTH andcompute these values from other font properties (for example,PIXEL_SIZE). X clients that require a font-dependent widthvalue should use either the FIGURE_WIDTH or one of the averagecharacter width font properties (AVERAGE_WIDTH,AVG_CAPITAL_WIDTH or AVG_LOWERCASE_WIDTH).3.2.22. FIGURE_WIDTHFIGURE_WIDTH is an integer typographic metric (of type INT32) that givesthe width of the tabular figures and the dollar sign, if suitable fortabular setting (all widths equal). For Latin fonts, these tabularfigures are the Arabic numerals 0 through 9.FIGURE_WIDTH can be approximated if not supplied as a font property,according to the following algorithm:if (numerals and DOLLAR sign are defined & widths are equal) thenFIGURE_WIDTH = width of DOLLARelse FIGURE_WIDTH property undefined3.2.23. SUPERSCRIPT_XSUPERSCRIPT_X is an integer value (of type INT32) that gives therecommended horizontal offset in pixels from the position point to the Xorigin of synthetic superscript text. If the current position point isat [X,Y], then superscripts should begin at [X + SUPERSCRIPT_X, Y −SUPERSCRIPT_Y].SUPERSCRIPT_X can be approximated if not provided as a font property,according to the following algorithm:if (SUPERSCRIPT_X undefined) thenif (TANGENT(ITALIC_ANGLE) defined) thenSUPERSCRIPT_X = ROUND((0.40 * CAP_HEIGHT) / TANGENT(ITALIC_ANGLE))else SUPERSCRIPT_X = ROUND(0.40 * CAP_HEIGHT)where TANGENT is a trigonometric function that returns the tangent ofits argument, which is in 1/64 degrees.3.2.24. SUPERSCRIPT_YSUPERSCRIPT_Y is an integer value (of type INT32) that gives therecommended vertical offset in pixels from the position point to the Yorigin of synthetic superscript text. If the current position point isat [X,Y], then superscripts should begin at [X + SUPERSCRIPT_X, Y −SUPERSCRIPT_Y].SUPERSCRIPT_Y can be approximated if not provided as a font property,according to the following algorithm:if (SUPERSCRIPT_Y undefined) thenSUPERSCRIPT_Y = ROUND(0.40 * CAP_HEIGHT)3.2.25. SUBSCRIPT_XSUBSCRIPT_X is an integer value (of type INT32) that gives therecommended horizontal offset in pixels from the position point to the Xorigin of synthetic subscript text. If the current position point is at[X,Y], then subscripts should begin at [X + SUBSCRIPT_X, Y +SUBSCRIPT_Y].SUBSCRIPT_X can be approximated if not provided as a font property,according to the following algorithm:if (SUBSCRIPT_X undefined) thenif (TANGENT(ITALIC_ANGLE) defined) thenSUBSCRIPT_X = ROUND((0.40 * CAP_HEIGHT) / TANGENT(ITALIC_ANGLE))else SUBSCRIPT_X = ROUND(0.40 * CAP_HEIGHT)3.2.26. SUBSCRIPT_YSUBSCRIPT_Y is an integer value (of type INT32) that gives therecommended vertical offset in pixels from the position point to the Yorigin of synthetic subscript text. If the current position point is at[X,Y], then subscripts should begin at [X + SUBSCRIPT_X, Y +SUBSCRIPT_Y].SUBSCRIPT_Y can be approximated if not provided as a font property,according to the following algorithm:if (SUBSCRIPT_Y undefined) thenSUBSCRIPT_Y = ROUND(0.40 * CAP_HEIGHT)3.2.27. SUPERSCRIPT_SIZESUPERSCRIPT_SIZE is an integer value (of type INT32) that gives therecommended body size of synthetic superscripts to be used with thisfont, in pixels. This will generally be smaller than the size of thecurrent font; that is, superscripts are imaged from a smaller fontoffset according to SUPERSCRIPT_X and SUPERSCRIPT_Y.SUPERSCRIPT_SIZE can be approximated if not provided as a font property,according to the following algorithm:if (SUPERSCRIPT_SIZE undefined) thenSUPERSCRIPT_SIZE = ROUND(0.60 * PIXEL_SIZE)3.2.28. SUBSCRIPT_SIZESUBSCRIPT_SIZE is an integer value (of type INT32) that gives therecommended body size of synthetic subscripts to be used with this font,in pixels. As with SUPERSCRIPT_SIZE, this will generally be smallerthan the size of the current font; that is, subscripts are imaged from asmaller font offset according to SUBSCRIPT_X and SUBSCRIPT_Y.SUBSCRIPT_SIZE can be approximated if not provided as a font property,according to the algorithm:if (SUBSCRIPT_SIZE undefined) thenSUBSCRIPT_SIZE = ROUND(0.60 * PIXEL_SIZE)3.2.29. SMALL_CAP_SIZESMALL_CAP_SIZE is an integer value (of type INT32) that gives therecommended body size of synthetic small capitals to be used with thisfont, in pixels. Small capitals are generally imaged from a smallerfont of slightly more weight. No offset [X,Y] is necessary.SMALL_CAP_SIZE can be approximated if not provided as a font property,according to the following algorithm:if (SMALL_CAP_SIZE undefined) thenSMALL_CAP_SIZE = ROUND(PIXEL_SIZE * ((X_HEIGHT+ ((CAP_HEIGHT − X_HEIGHT) / 3)) / CAP_HEIGHT))3.2.30. UNDERLINE_POSITIONUNDERLINE_POSITION is an integer value (of type INT32) that gives therecommended vertical offset in pixels from the baseline to the top ofthe underline. If the current position point is at [X,Y], the top ofthe baseline is given by [X, Y + UNDERLINE_POSITION].UNDERLINE_POSITION can be approximated if not provided as a fontproperty, according to the following algorithm:if (UNDERLINE_POSITION undefined) thenUNDERLINE_POSITION = ROUND((maximum descent) / 2)where maximum descent is the maximum descent (below the baseline) inpixels of any glyph in the font.3.2.31. UNDERLINE_THICKNESSUNDERLINE_THICKNESS is an integer value (of type INT32) that gives therecommended underline thickness, in pixels.UNDERLINE_THICKNESS can be approximated if not provided as a fontproperty, according to the following algorithm:CapStemWidth = average width of the stems of capitalsif (UNDERLINE_THICKNESS undefined) thenUNDERLINE_THICKNESS = CapStemWidth3.2.32. STRIKEOUT_ASCENTSTRIKEOUT_ASCENT is an integer value (of type INT32) that gives thevertical ascent for boxing or voiding glyphs in this font. If thecurrent position is at [X,Y] and the string extent is EXTENT, theupper-left corner of the strikeout box is at [X, Y − STRIKEOUT_ASCENT]and the lower-right corner of the box is at [X + EXTENT, Y +STRIKEOUT_DESCENT].STRIKEOUT_ASCENT can be approximated if not provided as a font property,according to the following algorithm:if (STRIKEOUT_ASCENT undefined)STRIKEOUT_ASCENT = maximum ascentwhere maximum ascent is the maximum ascent (above the baseline) inpixels of any glyph in the font.3.2.33. STRIKEOUT_DESCENTSTRIKEOUT_DESCENT is an integer value (of type INT32) that gives thevertical descent for boxing or voiding glyphs in this font. If thecurrent position is at [X,Y] and the string extent is EXTENT, theupper-left corner of the strikeout box is at [X, Y − STRIKEOUT_ASCENT]and the lower-right corner of the box is at [X + EXTENT, Y +STRIKEOUT_DESCENT].STRIKEOUT_DESCENT can be approximated if not provided as a fontproperty, according to the following algorithm:if (STRIKEOUT_DESCENT undefined)STRIKEOUT_DESCENT = maximum descentwhere maximum descent is the maximum descent (below the baseline) inpixels of any glyph in the font.3.2.34. ITALIC_ANGLEITALIC_ANGLE is an integer value (of type INT32) that gives the nominalposture angle of the typeface design, in 1/64 degrees, measured from theglyph origin counterclockwise from the three o’clock position.ITALIC_ANGLE can be defaulted if not provided as a font property,according to the following algorithm:if (ITALIC_ANGLE undefined) thenITALIC_ANGLE = (90 * 64)3.2.35. CAP_HEIGHTCAP_HEIGHT is an integer value (of type INT32) that gives the nominalheight of the capital letters contained in the font, as specified by theFOUNDRY or typeface designer.Certain clients require CAP_HEIGHT to compute scale factors andpositioning offsets for synthesized glyphs where this information ordesigned glyphs are not explicitly provided by the font (for example,small capitals, superiors, inferiors, and so on). CAP_HEIGHT is also acritical factor in font matching and substitution.CAP_HEIGHT can be approximated if not provided as a font property,according to the following algorithm:if (CAP_HEIGHT undefined) thenif (Latin font) thenCAP_HEIGHT = XCharStruct.ascent[glyph X]else if (capitals exist) thenCAP_HEIGHT = XCharStruct.ascent[some unaccented capital glyph]else CAP_HEIGHT undefined3.2.36. X_HEIGHTX_HEIGHT is an integer value (of type INT32) that gives the nominalheight above the baseline of the lowercase glyphs contained in the font,as specified by the FOUNDRY or typeface designer.As with CAP_HEIGHT, X_HEIGHT is required by certain clients to computescale factors for synthesized small capitals where this information isnot explicitly provided by the font resource. X_HEIGHT is a criticalfactor in font matching and substitution.X_HEIGHT can be approximated if not provided as a font property,according to the following algorithm:if (X_HEIGHT undefined) thenif (Latin font) thenX_HEIGHT = XCharStruct.ascent[glyph x]else if (lowercase exists) thenX_HEIGHT = XCharStruct.ascent[some unaccented lc glyph without an ascender]else X_HEIGHT undefined3.2.37. RELATIVE_SETWIDTHRELATIVE_SETWIDTH is an unsigned integer value (of type CARD32) thatgives the coded proportionate width of the font, relative to all knownfonts of the same typeface family, according to the type designer’s orFOUNDRY’s judgment.RELATIVE_SETWIDTH ranges from 10 to 90 or is 0 if undefined or unknown.The following reference values are defined:RELATIVE_SETWIDTH can be defaulted if not provided as a font property,according to the following algorithm:if (RELATIVE_SETWIDTH undefined) thenRELATIVE_SETWIDTH = 50For polymorphic fonts, RELATIVE_SETWIDTH is not necessarily a linearfunction of the font’s setwidth axis.X clients that want to obtain a calculated proportionate width of thefont (that is, a font-independent way of identifying the proportionatewidth across all fonts and all font vendors) can use the followingalgorithm:SETWIDTH = AVG_CAPITAL_WIDTH / (CAP_HEIGHT * 10)where SETWIDTH is a real number with zero being the narrowest calculatedsetwidth.3.2.38. RELATIVE_WEIGHTRELATIVE_WEIGHT is an unsigned integer value (of type CARD32) that givesthe coded weight of the font, relative to all known fonts of the sametypeface family, according to the type designer’s or FOUNDRY’s judgment.RELATIVE_WEIGHT ranges from 10 to 90 or is 0 if undefined or unknown.The following reference values are defined:RELATIVE_WEIGHT can be defaulted if not provided as a font property,according to the following algorithm:if (RELATIVE_WEIGHT undefined) thenRELATIVE_WEIGHT = 50For polymorphic fonts, RELATIVE_WEIGHT is not necessarily a linearfunction of the font’s weight axis.3.2.39. WEIGHTCalculated WEIGHT is an unsigned integer value (of type CARD32) thatgives the calculated weight of the font, computed as the ratio ofcapital stem width to CAP_HEIGHT, in the range 0 to 1000, where 0 is thelightest weight.WEIGHT can be calculated if not supplied as a font property, accordingto the following algorithm:CapStemWidth = average width of the stems of capitalsif (WEIGHT undefined) thenWEIGHT = ROUND ((CapStemWidth * 1000) / CAP_HEIGHT)A calculated value for weight is necessary when matching fonts fromdifferent families because both the RELATIVE_WEIGHT and the WEIGHT_NAMEare assigned by the typeface supplier, according to its tradition andpractice, and therefore, are somewhat subjective. Calculated WEIGHTprovides a font-independent way of identifying the weight across allfonts and all font vendors.3.2.40. RESOLUTIONRESOLUTION is an integer value (of type INT32) that gives the resolutionfor which this font was created, measured in 1/100 pixels per point.NoteAs independent horizontal and vertical design resolutioncomponents are required to accommodate displays with nonsquareaspect ratios, the use of this font property has beendeprecated, and independent RESOLUTION_X and RESOLUTION_Y fontname fields/properties have been defined (see sections 3.1.2.9and 3.1.2.10). X clients are encouraged to discontinue use ofthe RESOLUTION property and are encouraged to use theappropriate X,Y resolution properties, as required.3.2.41. FONTFONT is a string (of type ATOM) that gives the full XLFD name of thefont--that is, the value can be used to open another instance of thesame font.If not provided, the FONT property cannot be calculated.3.2.42. FACE_NAMEFACE_NAME is a human-understandable string (of type ATOM) that gives thefull device-independent typeface name, including the owner, weight,slant, set, and so on but not the resolution, size, and so on. Thisproperty may be used as feedback during font selection.FACE_NAME cannot be calculated or approximated if not provided as a fontproperty.3.2.43. FULL_NAMEFULL_NAME is the same as FACE_NAME. Its use is deprecated, but it isfound on some old fonts.3.2.44. COPYRIGHTCOPYRIGHT is a human-understandable string (of type ATOM) that gives thecopyright information of the legal owner of the digital font data.This information is a required component of a font but is independent ofthe particular format used to represent it (that is, it cannot becaptured as a comment that could later be thrown away for efficiencyreasons).COPYRIGHT cannot be calculated or approximated if not provided as a fontproperty.3.2.45. NOTICENOTICE is a human-understandable string (of type ATOM) that gives thecopyright information of the legal owner of the font design or, if notapplicable, the trademark information for the typeface FAMILY_NAME.Typeface design and trademark protection laws vary from country tocountry, the USA having no design copyright protection currently whilevarious countries in Europe offer both design and typeface family nametrademark protection. As with COPYRIGHT, this information is a requiredcomponent of a font but is independent of the particular format used torepresent it.NOTICE cannot be calculated or approximated if not provided as a fontproperty.3.2.46. DESTINATIONDESTINATION is an unsigned integer code (of type CARD32) that gives thefont design destination, that is, whether it was designed as a screenproofing font to match printer font glyph widths (WYSIWYG), as anoptimal video font (possibly with corresponding printer font) forextended screen viewing (video text), and so on.The font design considerations are very different, and at currentdisplay resolutions, the readability and legibility of these two kindsof screen fonts are very different. DESTINATION allows publishingclients that use X to model the printed page and video text clients,such as on-line documentation browsers, to query for X screen fonts thatsuit their particular requirements.The encoding is as follows:3.2.47. FONT_TYPEFONT_TYPE is a human-understandable string (of type ATOM) that describesthe format of the font data as they are read from permanent storage bythe current font source. It is a static attribute of the source data.It can be used by clients to select a type of bitmap or outline fontwithout regard to the rasterizer used to render the font.Predefined values are as follows:Other values may be registered with the X Consortium.3.2.48. FONT_VERSIONFONT_VERSION is a human-understandable string (of type ATOM) thatdescribes the formal or informal version of the font. None is a validvalue.3.2.49. RASTERIZER_NAMERASTERIZER_NAME is a human-understandable string (of type ATOM) that isthe specific name of the rasterizer that has performed somerasterization operation (such as scaling from outlines) on this font.To define a RASTERIZER_NAME, the following format is recommended:Examples: X Consortium Bit ScalerX Consortium Type 1 RasterizerX Consortium Speedo RasterizerAdobe Type ManagerSun TypeScalerIf RASTERIZER_NAME is not defined, or is None, no rasterizationoperation has been applied to the FONT_TYPE.3.2.50. RASTERIZER_VERSIONRASTERIZER_VERSION is a human-understandable string (of type ATOM) thatrepresents the formal or informal version of a font rasterizer. TheRASTERIZER_VERSION should match the corresponding product version numberknown to users, when applicable.3.2.51. RAW_ASCENTFor a font with a transformation matrix, RAW_ASCENT is the font ascentin 1000 pixel metrics (see section 4.1).3.2.52. RAW_DESCENTFor a font with a transformation matrix, RAW_DESCENT is the font descentin 1000 pixel metrics (see section 4.1).3.2.53. RAW_*For a font with a transformation matrix, all font properties thatrepresent horizontal or vertical sizes or displacements will beaccompanied by a new property, named as the original except prefixedwith "RAW_", that is computed as described in section 4.1.3.2.54. AXIS_NAMESAXIS_NAMES is a list of all the names of the axes for a polymorphicfont, separated by a null (0) byte. These names are suitable forpresentation in a user interface (see section 6).3.2.55. AXIS_LIMITSAXIS_LIMITS is a list of integers, two for each axis, giving the minimumand maximum allowable values for that axis of a polymorphic font (seesection 6).3.2.56. AXIS_TYPESAXIS_TYPES is like AXIS_NAMES, but can be registered as having specificsemantics (see section 6).3.3. Built-in Font Property AtomsThe following font property atom definitions were predefined in theinitial version of the core protocol:4. Matrix TransformationsAn XLFD name presented to the server can have the POINT_SIZE orPIXEL_SIZE field begin with the character "[". If the first characterof the field is "[", the character must be followed with ASCIIrepresentations of four floating point numbers and a trailing "]", withwhite space separating the numbers and optional white space separatingthe numbers from the "[" and "]" characters. Numbers use standardfloating point syntax but use the character "~" to represent a minussign in the mantissa or exponent.The BNF for a matrix transformation string is as follows:The string "[a b c d]" represents a graphical transformation of theglyphs in the font by the matrixAll transformations occur around the origin of the glyph. Therelationship between the current scalar values and the matrixtransformation values is that the scalar value "N" in the POINT_SIZEfield produces the same glyphs as the matrix "[N/10 0 0 N/10]" in thatfield, and the scalar value "N" in the PIXEL_SIZE field produces thesame glyphs as the matrix "[N*RESOLUTION_X/RESOLUTION_Y 0 0 N]" in thatfield.If matrices are specified for both the POINT_SIZE and PIXEL_SIZE, theymust bear the following relationship to each other within animplementation-specific tolerance:PIXEL_SIZE_MATRIX = [Sx 0 0 Sy] * POINT_SIZE_MATRIXwhereSx = RESOLUTION_X / 72.27Sy = RESOLUTION_Y / 72.27If either the POINT_SIZE or PIXEL_SIZE field is unspecified (either "0"or wildcarded), the preceding formulas can be used to compute one fromthe other.4.1. Metrics and Font PropertiesIn this section, the phrase "1000 pixel metrics" means the metrics thatwould be obtained if the rasterizer took the base untransformed designused to generate the transformed font and scaled it linearly to a heightof 1000 pixels, with no rotation component. Note that there may be noway for the application to actually request this font since therasterizer may use different outlines or rasterization techniques atthat size from the ones used to generate the transformed font.Notes on properties and metrics:The per-char ink metrics (lbearing, rbearing, ascent, and descent)represent the ink extent of the transformed glyph around its origin.The per-char width is the x component of the transformed characterwidth.The font ascent and descent are the y component of the transformed fontascent or descent.The FONT property returns a name reflecting the matrix being used--thatis, the name returned can be used to open another instance of the samefont. The returned name is not necessarily an exact copy of therequested name. If, for example, the user requests−misc−fixed−medium−r−normal−−0−[2e1 0 0.0 +10.0]−72−72−c−0−iso8859−1the resulting FONT property might be−misc−fixed−medium−r−normal−−[19.9 0 0 10]−[20 0 010]−72−72−c−0−iso8859−1The FONT property will always include matrices in both the PIXEL_SIZEand the POINT_SIZE fields.To allow accurate client positioning of transformed characters, theattributes field of the XCharInfo contains the width of the character in1000 pixel metrics. This attributes field should be interpreted as asigned integer.There will always be 2 new font properties defined, RAW_ASCENT andRAW_DESCENT, that hold the ascent and descent in 1000 pixel metrics.All font properties that represent horizontal widths or displacementshave as their value the x component of the transformed width ordisplacement. All font properties that represent vertical heights ordisplacements have as their value the y component of the transformedheight or displacement. Each such property will be accompanied by a newproperty, named as the original except prefixed with "RAW_", that givesthe value of the width, height, or displacement in 1000 pixel metrics.5. Scalable FontsThe XLFD is designed to support scalable fonts. A scalable font is afont source from which instances of arbitrary size can be derived. Ascalable font source might be one or more outlines together with zero ormore hand-tuned bitmap fonts at specific sizes and resolutions, or itmight be a programmatic description together with zero or more bitmapfonts, or some other format (perhaps even just a single bitmap font).The following definitions are useful for discussing scalable fonts:Well-formed XLFD patternA pattern string containing 14 hyphens, one of which is the firstcharacter of the pattern. Wildcard characters are permitted in thefields of a well-formed XLFD pattern.Scalable font nameA well-formed XLFD pattern containing no wildcards and containingthe digit "0" in the PIXEL_SIZE, POINT_SIZE, and AVERAGE_WIDTHfields.Scalable fieldsThe XLFD fields PIXEL_SIZE, POINT_SIZE, RESOLUTION_X, RESOLUTION_Y,and AVERAGE_WIDTH.Derived instanceThe result of replacing the scalable fields of a font name withvalues to yield a font name that could actually be produced fromthe font source. A scaling engine is permitted, but not required,to interpret the scalable fields in font names to supportanamorphic scaling.Global listThe list of names that would be returned by an X server for aListFonts protocol request on the pattern "*" if there were noprotocol restrictions on the total number of names returned.The global list consists of font names derived from font sources. If asingle font source can support multiple character sets (specified in theCHARSET_REGISTRY and CHARSET_ENCODING fields), each such character setshould be used to form a separate font name in the list. For anonscalable font source, the simple font name for each character set isincluded in the global list. For a scalable font source, a scalablefont name for each character set is included in the list. In additionto the scalable font name, specific derived instance names may also beincluded in the list. The relative order of derived instances withrespect to the scalable font name is not constrained. Finally, fontname aliases may also be included in the list. The relative order ofaliases with respect to the real font name is not constrained.The values of the RESOLUTION_X and RESOLUTION_Y fields of a scalablefont name are implementation dependent, but to maximize backwardcompatibility, they should be reasonable nonzero values, for example, aresolution close to that provided by the screen (in a single-screenserver). Because some existing applications rely on seeing a collectionof point and pixel sizes, server vendors are strongly encouraged in thenear term to provide a mechanism for including, for each scalable fontname, a set of specific derived instance names. For font sources thatcontain a collection of hand-tuned bitmap fonts, including names ofthese instances in the global list is recommended and sufficient.The X protocol request OpenFont on a scalable font name returns a fontcorresponding to an implementation-dependent derived instance of thatfont name.The X protocol request ListFonts on a well-formed XLFD pattern returnsthe following. Starting with the global list, if the actual patternargument has values containing no wildcards in scalable fields, thensubstitute each such field into the corresponding field in each scalablefont name in the list. For each resulting font name, if the remainingscalable fields cannot be replaced with values to produce a derivedinstance, remove the font name from the list. Now take the modifiedlist, and perform a simple pattern match against the pattern argument.ListFonts returns the resulting list.For example, given the global list:-Linotype-Times-Bold-I-Normal--0-0-100-100-P-0-ISO8859-1-Linotype-Times-Bold-R-Normal--0-0-100-100-P-0-ISO8859-1-Linotype-Times-Medium-I-Normal--0-0-100-100-P-0-ISO8859-1-Linotype-Times-Medium-R-Normal--0-0-100-100-P-0-ISO8859-1a ListFonts request with the pattern:-*-Times-*-R-Normal--*-120-100-100-P-*-ISO8859-1would return:-Linotype-Times-Bold-R-Normal--0-120-100-100-P-0-ISO8859-1-Linotype-Times-Medium-R-Normal--0-120-100-100-P-0-ISO8859-1ListFonts on a pattern containing wildcards that is not a well-formedXLFD pattern is only required to return the list obtained by performinga simple pattern match against the global list. X servers arepermitted, but not required, to use a more sophisticated matchingalgorithm.6. Polymorphic FontsFonts that can be varied in ways other than size or resolution arecalled polymorphic fonts. Multiple Master Type 1 font programs are onetype of a polymorphic font. Current examples of axes along which thefonts can be varied are width, weight, and optical size; others mightinclude formality or x-height.To support polymorphic fonts, special values indicating variability aredefined for the following XLFD fields:WEIGHT_NAMESLANTSETWIDTH_NAMEADD_STYLE_NAMEThe string "0" is the special polymorphic value. In the WEIGHT_NAME,SLANT, or SETWIDTH_NAME field, "0" must be the entire field. There maybe multiple polymorphic values in the ADD_STYLE_NAME field. They aresurrounded by "[" and "]" and separated by a Space, as "[0 0]". Thepolymorphic values may coexist with other data in the field. It isrecommended that the polymorphic values be at the end of theADD_STYLE_NAME field.The font-matching algorithms for a font with polymorphic fields areidentical to the matching algorithms for a font with scalable fields.There are three new font properties to describe the axes of variation,AXIS_NAMES, AXIS_LIMITS, and AXIS_TYPES. AXIS_NAMES is a list of allthe names of the axes for the font, separated by a null (0) byte. Thesenames are suitable for presentation in a user interface. AXIS_LIMITS isa list of integers, two for each axis, giving the minimum and maximumallowable values for that axis. AXIS_TYPES is like AXIS_NAMES, but canbe registered as having specific semantics.The axes are listed in the properties in the same order as they appearin the font name. They are matched with font name fields by looking forthe special polymorphic values in the font name.Examples:The Adobe Myriad MM font program has width and weight axes. Weight canvary from 215 to 830, and width from 300 to 700.Name:-Adobe-Myriad MM-0-R-0--0-0-0-0-P-0-ISO8859-1AXIS_NAMES:Weight, WidthAXIS_LIMITS:215, 830, 300, 700AXIS_TYPES:Adobe-Weight, Adobe-WidthSample derived instance:-Adobe-Myriad MM-412-R-575--*-120-100-100-P-*-ISO8859-1The Adobe Minion MM Italic font program has width, weight, and opticalsize axes.Name:-Adobe-Minion MM-0-I-0-[0]-0-0-0-0-P-0-ISO8859-1AXIS_NAMES:Weight, Width, Optical sizeAXIS_LIMITS:345, 620, 450, 600, 6, 72AXIS_TYPES:Adobe-Weight, Adobe-Width, Adobe-OpticalSizeSample derived instance:-Adobe-Minion MM-550-I-480-[18]-*-180-100-100-P-*-ISO8859-1The Adobe Minion MM Swash Italic font program has the same axes andvalues. This shows how "[0]" in the ADD_STYLE_NAME field can coexistwith other words.Name:-Adobe-Minion MM-0-I-0-Swash[0]-0-0-0-0-P-0-ISO8859-1AXIS_NAMES:Weight, Width, Optical sizeAXIS_LIMITS:345, 620, 450, 600, 6, 72AXIS_TYPES:Adobe-Weight, Adobe-Width, Adobe-OpticalSizeSample derived instance:-Adobe-Minion MM-550-I-480-Swash[18]-*-180-100-100-P-*-ISO8859-1The XYZ Abc font, a hypothetical font, has optical size and x-heightaxes. This shows how there can be more than one polymorphic value inthe ADD_STYLE_NAME field.Name:-XYZ-Abc-Medium-R-Normal-[0 0]-0-0-0-0-P-0-ISO8859-1AXIS_NAMES:Optical size, X-heightAXIS_LIMITS:6, 72, 400, 600AXIS_TYPES:XYZ-OpticalSize, XYZ-XheightSample derived instance:-XYZ-Abc-Medium-R-Normal-[14 510]-*-140-100-100-P-*-ISO8859-1If an axis allows negative values, a client requests a negative value byusing "~" (TILDE) as a minus sign.Axis types can be registered with the X Consortium, along with theirsemantics.If a font name that contains the polymorphic value or a wildcard in apolymorphic field is presented to a font source, the font source is freeto substitute any value that is convenient. However, font sourcesshould try to use a value that would be considered normal or medium forthe particular font. For example, if an optical size variable isunresolved, the font source should provide a value appropriate to thesize of the font.The result of specifying an out-of-range value for a polymorphic fieldis undefined. The font source may treat this as a BadName error, treatthe value as if it were the closest legal value, or extrapolate to tryto accommodate the value.7. Affected Elements of Xlib and the X ProtocolThe following X protocol requests must support the XLFD conventions:• OpenFont − for the name argument• ListFonts − for the pattern argument• ListFontsWithInfo − for the pattern argumentIn addition, the following Xlib functions must support the XLFDconventions:• XLoadFont − for the name argument• XListFontsWithInfo − for the pattern argument• XLoadQueryFont − for the name argument• XListFonts − for the pattern argument8. BDF ConformanceThe bitmap font distribution and interchange format adopted by the XConsortium (BDF V2.1) provides a general mechanism for identifying thefont name of an X font and a variable list of font properties, but itdoes not mandate the syntax or semantics of the font name or thesemantics of the font properties that might be provided in a BDF font.This section identifies the requirements for BDF fonts that conform toXLFD.8.1. XLFD Conformance RequirementsA BDF font conforms to the XLFD specification if and only if thefollowing conditions are satisfied:• The value for the BDF item FONT conforms to the syntax and semanticdefinition of a XLFD FontName string.• The FontName begins with the X FontNameRegistry prefix: "−".• All XLFD FontName fields are defined.• Any FontProperties provided conform in name and semantics to theXLFD FontProperty definitions.A simple method of testing for conformance would entail verifying thatthe FontNameRegistry prefix is the string "−", that the number of fielddelimiters in the string and coded field values are valid, and that eachfont property name either matches a standard XLFD property name orfollows the definition of a private property.8.2. FONT_ASCENT, FONT_DESCENT, and DEFAULT_CHARFONT_ASCENT, FONT_DESCENT, and DEFAULT_CHAR are provided in the BDFspecification as properties that are moved to the XFontStruct by the BDFfont compiler in generating the X server-specific binary font encoding.If present, these properties shall comply with the following semanticdefinitions.8.2.1. FONT_ASCENTFONT_ASCENT is an integer value (of type INT32) that gives therecommended typographic ascent above the baseline for determininginterline spacing. Specific glyphs of the font may extend beyond this.If the current position point for line n is at [X,Y], then the origin ofthe next line m = n + 1 (allowing for a possible font change) is [X, Y +FONT_DESCENTn + FONT_ASCENTm].FONT_ASCENT can be approximated if not provided as a font property,according to the following algorithm:if (FONT_ASCENT undefined) thenFONT_ASCENT = maximum ascentwhere maximum ascent is the maximum ascent (above the baseline) inpixels of any glyph in the font.8.2.2. FONT_DESCENTFONT_DESCENT is an integer value (of type INT32) that gives therecommended typographic descent below the baseline for determininginterline spacing. Specific glyphs of the font may extend beyond this.If the current position point for line n is at [X,Y], then the origin ofthe next line m = n+1 (allowing for a possible font change) is [X, Y +FONT_DESCENTn + FONT_ASCENTm].The logical extent of the font is inclusive between the Y-coordinatevalues: Y − FONT_ASCENT and Y + FONT_DESCENT + 1.FONT_DESCENT can be approximated if not provided as a font property,according to the following algorithm:if (FONT_DESCENT undefined) thenFONT_DESCENT = maximum descentwhere maximum descent is the maximum descent (below the baseline) inpixels of any glyph in the font.8.2.3. DEFAULT_CHARThe DEFAULT_CHAR is an unsigned integer value (of type CARD32) thatspecifies the index of the default character to be used by the X serverwhen an attempt is made to display an undefined or nonexistent characterin the font. (For a font using a 2-byte matrix format, the index bytesare encoded in the integer as byte1 * 65536 + byte2.) If theDEFAULT_CHAR itself specifies an undefined or nonexistent character inthe font, then no display is performed.DEFAULT_CHAR cannot be approximated if not provided as a font property.1

X Logical Font Description Conventions X11, Release 6.4

2

Table of Contents

i