The X Font Service Protocol

Version 2.0 X Consortium Standard

X Version 11, Release 6.4

Jim Fulton Network Computing Devices, Inc.

Revised May 2, 1994

Copyright © 1991 Network Computing Devices, Inc.

Permission to use, copy, modify, distribute, and sell this documentation for any purpose is hereby granted without fee, provided that the above copyright notice and this permission notice appear in all copies. Network Computing Devices, Inc. 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.

Copyright © 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.

1. IntroductionThe management of fonts in large, heterogeneous environmentsis one of the hardest aspects of using the X Window System.*Multiple formats and the lack of a consistent mechanism forexporting font data to all displays on a network prevent thetransparent use of applications across different displayplatforms. The X Font Service protocol is designed toaddress this and other issues, with specific emphasis on theneeds of the core X protocol. Upward-compatible changes(typically in the form of new requests) are expected asconsensus is reached on new features (particularly outlinefont support).Currently, most X displays use network file protocols suchas NFS and TFTP to obtain raw font data which they parsedirectly. Since a common binary format for this datadoesn’t exist, displays must be able to interpret a varietyof formats if they are to be used with different applicationhosts. This leads to wasted code and data space and a lossof interoperability as displays are used in unforeseenenvironments.By moving the interpretation of font data out of the Xserver into a separate service on the network, theseproblems can be greatly reduced. In addition, newtechnologies, such as dynamically generating bitmaps fromscaled or outline fonts, can be provided to all displaystransparently. For horizontal text, caching techniques andincreased processor power can potentially make rasterizationmore efficient on large, centralized hosts than onindividual displays.Each font server provides sets of fonts that may be listedand queried for header, property, glyph extents, and bitmapinformation. This data is transmitted over the networkusing a binary format (with variations to support differentbit- and byte-orders) designed to minimize the amount ofprocessing required by the display. Since the font server,rather than the display, is responsible for parsing the rawfont data, new formats can be used by all displays bymodifying a single font server.From the user’s point of view, font servers are simply a newtype of name in the X font path. Network name servicesallow descriptive names (such as DEPARTMENT-FONTS orAPPLICATION-FONTS) to be translated into proper networkaddresses. X displays send requests to and read repliesfrom the font server rather than reading directly fromfiles. Since the X Font Service protocol is designed toallow subsets of the font data to be requested, displays mayeasily implement a variety of strategies for fine-graineddemand-loading of glyphs.2. Architectural ModelIn this document, the words ‘‘client’’ and ‘‘server’’ referto the consumer and provider of a font, respectively, unlessotherwise indicated. It is important to note that in thiscontext, the X server is also a font client.The X Font Service protocol does not require any changes tothe core X protocol or to any applications. To the user,font servers are simply additional types of font pathelements. As such, X servers may connect to multiple fontservers, as shown in Figure 2.1. Although the font protocolis geared towards the X Window System, it may be also usedby other consumers of font data (such as printer drivers).+--------+ +---------------+| X1 |--------------| || Server | | Font Server |+--------+ +-------| 1 || +---------------++--------+ || X2 |------+ +---------------+| Server |--------------| |+--------+ | Font Server |+-------| 2 |+---------+ | +---------------+| other | || clients |------++---------+Figure 2.1: Connecting to a Font ServerClients communicate with the font server using therequest/reply/event model over any mutually-understoodvirtual stream connection (such as TCP/IP, DECnet,*etc.). Font servers are responsible for providing data inthe bit and byte orders requested by the client. The set ofrequests and events provided in the first version of the XFont Service protocol is limited to supporting the needs ofthe bitmap-oriented core X Window System protocol.Extensions are expected as new needs evolve.A font server reads raw font data from a variety of sources(possibly including other font servers) and converts it intoa common format that is transmitted to the client using theprotocol described in Section 4. New font formats arehandled by adding new converters to a font server, as shownin Figure 2.2. +------------+| client || (X server) |+------------+|network|+--------------------------------------------+| || font server 1 || |+-----+-----+-----+-----+----+-----+---+-----+| bdf | snf | pcf | atm | f3 | dwf | | | ... |+-----+-----+-----+-----+----+-----+-|-+-----+|network|+----------+| font || server 2 |+----------+Figure 2.2: Where Font Data Comes FromThe server may choose to provide named sets of fonts called‘‘catalogues.’’ Clients may specify which of the setsshould be used in listing or opening a font.An event mechanism similar to that used in the X protocol isprovided for asynchronous notification of clients by theserver.Clients may provide authorization data for the server to beused in determining (according to the server’s licensingpolicy) whether or not access should be granted toparticular fonts. This is particularly useful for clientswhose authorization changes over time (such as an X serverthat can verify the identity of the user).Implementations that wish to provide additional requests orevents may use the extension mechanism. Adding to the corefont service protocol (with the accompanying change in themajor or minor version numbers) is reserved to the XConsortium.3. Font Server NamingFont clients that expose font server names to the user areencouraged to provide ways of naming font serverssymbolically (e.g. DEPARTMENT-FONTS). However, forenvironments that lack appropriate name servicestransport-specific names are necessary. Since these namesdo occur in the protocol, clients and servers should supportat least the applicable formats described below. Formatsfor additional transports may be registered with the XConsortium.3.1. TCP/IP NamesThe following syntax should be used for TCP/IP names:<TCP name> ::= "tcp/" <hostname>":" <ipportnumber> ["/" <cataloguelist>]where <hostname> is either symbolic (such asexpo.lcs.mit.edu) or numeric decimal (such as 18.30.0.212).The <ipportnumber> is the port on which the font server islistening for connections. The <cataloguelist> string atthe end is optional and specifies a plus-separated list ofcatalogues that may be requested. For example:tcp/expo.lcs.mit.edu:8012/available+specialtcp/18.30.0.212:78903.2. DECnet NamesThe following syntax should be used for DECnet names:<DECnet name> ::= "decnet/" <nodename> "::font$" <objname>["/" <cataloguelist>]where <nodename> is either symbolic (such as SRVNOD) or thenumeric decimal form of the DECnet address (such as 44.70).The <objname> is normal, case-insensitive DECnet objectname. The <cataloguelist> string at the end is optional andspecifies a plus-separated list of catalogues that may berequested. For example:DECNET/SRVNOD::FONT$DEFAULT/AVAILABLEdecnet/44.70::font$other4. ProtocolThe protocol described below uses the request/reply/errormodel and is specified using the same conventions outlinedin Section 2 of the core X Window System protocol [1]:• Data type names are spelled in upper case with no wordseparators, as in: FONTID• Alternate values are capitalized with no wordseparators, as in: MaxWidth• Structure element declarations are in lower case withhyphens as word separators, as in: byte-order-msbNoteStructure element names are referred to inupper case (e.g. BYTE-ORDER-MSB) when used indescriptions to set them off from thesurrounding text. When this document istypeset they will be printed in lower case ina distinct font.• Type declarations have the form ‘‘name: type’’, as in:CARD8: 8-bit byte• Comma-separated lists of alternate values are enclosedin braces, as in: { Min, MaxWidth, Max }• Comma-separated lists of structure elements areenclosed in brackets, as in: [ byte1: CARD8, byte2:CARD8 ]A type with a prefix ‘‘LISTof’’ represents a counted list ofelements of that type, as in: LISTofCARD84.1. Data TypesThe following data types are used in the core X Font Serverprotocol:ACCESSCONTEXT: IDThis value is specified in the CreateAC request as theidentifier to be used when referring to a particularAccessContext resource within the server. Theseresources are used by the server to storeclient-specified authorization information. Thisinformation may be used by the server to determinewhether or not the client should be granted access toparticular font data.In order to preserve the integrity of font licensingbeing performed by the font server, care must be takenby a client to properly represent the identity of thetrue user of the font. Some font clients will in factbe servers (for example, X servers) requesting fontsfor their own clients. Other font clients may be doingwork on behalf of a number of different users over time(for example, print spoolers).AccessContexts must be created (with CreateAC) andswitched among (with SetAuthorization) to represent allof these ‘‘font users’’ properly.ALTERNATESERVER: [ name: STRING8, subset: BOOL ]This structure specifies the NAME, encoded in ISO8859-1 according to Section 3, of another font serverthat may be useful as a substitute for this fontserver. The SUBSET field indicates whether or not thealternate server is likely to only contain a subset ofthe fonts available from this font server. Thisinformation is returned during the initial connectionsetup and may be used by the client to find a backupserver in case of failure.AUTH: [ name: STRING8,data: LISTofBYTE ]This structure specifies the name of an authorizationprotocol and initial data for that protocol. It isused in the authorization negotiation in the initialconnection setup and in the CreateAC request.BITMAPFORMAT:CARD32 containing the following fields defined by thesets of values given further below[ byte-order-msb: 1 bit,bit-order-msb: 1 bit,image-rect: 2 bits { Min,MaxWidth,Max },zero-pad: 4 bits,scanline-pad: 2 bits { ScanlinePad8,ScanlinePad16,ScanlinePad32,ScanlinePad64 },zero-pad: 2 bits,scanline-unit: 2 bits { ScanlineUnit8,ScanlineUnit16,ScanlineUnit32,ScanlineUnit64 },zero-pad: 2 bits,zero-pad: 16 bits,]This structure specifies how glyph images aretransmitted in response to QueryXBitmaps8 andQueryXBitmaps16 requests.If the BYTE-ORDER-MSB bit (1 << 0) is set, the MostSignificant Byte of each scanline unit is returnedfirst. Otherwise, the Least Significant Byte isreturned first.If the BIT-ORDER-MSB bit (1 << 1) is set, the left-mostbit in each glyph scanline unit is stored in the MostSignificant Bit of each transmitted scanline unit.Otherwise, the left-most bit is stored in the LeastSignificant Bit.The IMAGE-RECT field specifies a rectangle of pixelswithin the glyph image. It contains one of thefollowing alternate values:ImageRectMin (0 << 2)ImageRectMaxWidth (1 << 2)ImageRectMax (2 << 2)For a glyph with extents XCHARINFO in a font withheader information XFONTINFO, the IMAGE-RECT valueshave the following meanings:ImageRectMin- This refers to the minimal boundingrectangle surrounding the inked pixels in theglyph. This is the most compact representation.The edges of the rectangle are:left: XCHARINFO.LBEARINGright: XCHARINFO.RBEARINGtop: XCHARINFO.ASCENTbottom: XCHARINFO.DESCENTImageRectMaxWidth- This refers to the scanlinesbetween the glyph’s ascent and descent, padded onthe left to the minimum left-bearing (or 0,whichever is less) and on the right to the maximumright-bearing (or logical-width, whichever isgreater). All glyph images share a commonhorizontal origin. This is a combination ofImageRectMax in the horizontal direction andImageRectMin in the vertical direction. The edgesof the rectangle are:left: min (XFONTINFO.MIN-BOUNDS.LBEARING, 0)right: max (XFONTINFO.MAX-BOUNDS.RBEARING,XFONTINFO.MAX-BOUNDS.WIDTH)top: XCHARINFO.ASCENTbottom: XCHARINFO.DESCENTImageRectMax - This refers to all scanlines, fromthe maximum ascent (or the font ascent, whicheveris greater) to the maximum descent (or the fontdescent, whichever is greater), padded to the samehorizontal extents as MaxWidth. All glyph imageshave the same sized bitmap and share a commonorigin. This is the least compact representation,but may be the easiest or most efficient(particularly for character cell fonts) for someclients to use. The edges of the rectangle are:left: min (XFONTINFO.MIN-BOUNDS.LBEARING, 0)right: max (XFONTINFO.MAX-BOUNDS.RBEARING,XFONTINFO.MAX-BOUNDS.WIDTH)top: max (XFONTINFO.FONT-ASCENT,XFONTINFO.MAX-BOUNDS.ASCENT)bottom: max (XFONTINFO.FONT-DESCENT,XFONTINFO.MAX-BOUNDS.DESCENT)The SCANLINE-PAD field specifies the number ofbits (8, 16, 32, or 64) to which each glyphscanline is padded before transmitting. Itcontains one of the following alternate values:ScanlinePad8 (0 << 8)ScanlinePad16 (1 << 8)ScanlinePad32 (2 << 8)ScanlinePad64 (3 << 8)The SCANLINE-UNIT field specifies the number ofbits (8, 16, 32, or 64) that should be treated asa unit for swapping. This value must be less thanor equal to the number of bits specified by theSCANLINE-PAD. It contains one of the followingalternate values:ScanlineUnit8 (0 << 12)ScanlineUnit16 (1 << 12)ScanlineUnit32 (2 << 12)ScanlineUnit64 (3 << 12)BITMAPFORMATs are byte-swapped as CARD32s. Allunspecified bits must be zero.Use of an invalid BITMAPFORMAT causes a Formaterror to be returned.BITMAPFORMATMASK: CARD32 maskThis is a mask of bits representing the fields in aBITMAPFORMAT: ByteOrderMask (1 << 0)BitOrderMask (1 << 1)ImageRectMask (1 << 2)ScanlinePadMask (1 << 3)ScanlineUnitMask (1 << 4)Unspecified bits are required to be zero or else aFormat error is returned.BOOL: CARD8This is a boolean value containing one of the followingalternate values:False 0True 1BYTE: 8-bit valueThis is an unsigned byte of data whose encoding isdetermined by the context in which it is used.CARD8: 8-bit unsigned integerCARD16: 16-bit unsigned integerCARD32: 32-bit unsigned integerThese are unsigned numbers. The latter two arebyte-swapped when the server and client have differentbyte orders.CHAR2B: [ byte1, byte2: CARD8 ]This structure specifies an individual character codewithin either a 2-dimensional matrix (using BYTE1 andBYTE2 as the row and column indices, respectively) or avector (using BYTE1 and BYTE2 as most- andleast-significant bytes, respectively). This data typeis treated as a pair of 8-bit values and is neverbyte-swapped. Therefore, the client should alwaystransmit BYTE1 first.EVENTMASK: CARD32 maskThis is a mask of bits indicating which of anextension’s (or the core’s) maskable events the clientwould like to receive. Each bit indicates one or moreevents, and a bit value of one indicates interest in acorresponding set of events. The following bits aredefined for event masks specified for the core protocol(i.e. an EXTENSION-OPCODE of zero in SetEventMask andGetEventMask requests):CatalogueListChangeMask (1 << 0)FontListChangeMask (1 << 1)If CatalogueListChangeMask is set, client is interestedin receiving CatalogueListNotify events. IfFontListChangeMask is set, the client is interested inreceiving FontListNotify events.Extensions that provide additional events may definetheir own event masks. These event masks have theirown scope and may use the same bit values as the coreor other extensions.All unused bits must be set to zero. In SetEventMaskrequests, if any bits are set that are not defined forthe extension (or core) for which this EVENTMASK isintended (according to the EXTENSION- OPCODE given inthe SetEventMask request), an EventMask error isgenerated.This value is swapped as a CARD32.FONTID: IDThis is specified by the client in the requestOpenBitmapFont as the identifier to be used whenreferring to a particular open font.ID: CARD32This is a 32-bit value in which the top 3 bits must beclear, and at least 1 other bit must be set (yielding arange of 1 through 2^29-1). It is specified by theclient to represent objects in the server. Identifiersare scoped according to their type are private to theclient; thus, the same identifier may be used for botha FONTID and an ACCESSCONTEXT as well as by multipleclients.An ID of zero is referred to as None.INT8: 8-bit signed integerINT16: 16-bit signed integerINT32: 32-bit signed integerThese are signed numbers. The latter two arebyte-swapped when the client and server have differentbyte orders.OFFSET32: [ position: CARD32,length: CARD32 ]This structure indicates a position and length within ablock of data.PROPINFO: [ offsets: LISTofPROPOFFSET,data: LISTofBYTE ]This structure describes the list of propertiesprovided by a font. Strings for all of the propertiesnames and values are stored within the data block andare located using a table of offsets and lengths.This structure is padded to 32-bit alignment.PROPOFFSET: [ name: OFFSET32,value: OFFSET32,type: CARD8,zero-pad3: BYTE, BYTE, BYTE ]This structure specifies the position, length, and typeof of data for a property.The NAME field specifies the position and length (whichmust be greater than zero) of the property namerelative to the beginning of the PROPINFO.DATA blockfor this font. The interpretation of the position andlength of the VALUE field is determined by the TYPEfield, which contains one of the following alternatevalues: String 0Unsigned 1Signed 2which have the following meanings:StringThis property contains a counted string of bytes.The data is stored in the PROPINFO.DATA blockbeginning at relative byte VALUE.POSITION(beginning with zero), extending for VALUE.LENGTH(at least zero) bytes.UnsignedThis property contains a unsigned, 32-bit numberstored as a CARD32 in VALUE.POSITION (VALUE.LENGTHis zero).SignedThis property contains a signed, 32-bit numberstored as an INT32 in VALUE.POSITION (VALUE.LENGTHis zero).This structure is zero-padded to 32-bit alignment.RANGE: [ min-char, max-char: CHAR2B ]This structure specifies a range of character codes. Asingle character is represented by MIN-CHAR equalsMAX-CHAR. If the linear interpretation of MAX-CHAR isless than that of MIN-CHAR, or if MIN-CHAR is less thanthe font’s XFONTINFO.CHAR-RANGE.MIN-CHAR, or ifMAX-CHAR is greater than the font’sXFONTINFO.CHAR-RANGE.MAX-CHAR, the range is invalid.RESOLUTION: [ x-resolution: CARD16,y-resolution: CARD16,decipoint-size: CARD16 ]This structure specifies resolution and point size tobe used in resolving partially-specified scaled fontnames. The X-RESOLUTION and Y-RESOLUTION are measuredin pixels-per-inch and must be greater than zero. TheDECIPOINT-SIZE is the preferred font size, measured intenths of a point, and must be greater than zero.STRING8: LISTofCARD8This is a counted list of 1-byte character codes,typically encoded in ISO 8859-1. A character code‘‘c’’ is equivalent to a CHAR2B structure whose BYTE1is zero and whose BYTE2 is ‘‘c’’.TIMESTAMP: CARD32This is the number of milliseconds that have passedsince a server- dependent origin. It is provided inerrors and events and is permitted to wrap.XCHARINFO: [ lbearing, rbearing: INT16,width: INT16,ascent, descent: INT16,attributes: CARD16 ]This structure specifies the ink extents and horizontalescapement (also known as the set- or logical width) ofan individual character. The first five valuesrepresent directed distances in a coordinate systemwhose origin is aligned with the lower-left edge of theleft-most pixel of the glyph baseline (i.e. thebaseline falls between two pixels as shown in Figure3-1 of the ‘‘Bitmap Distribution Format 2.1’’Consortium standard [2]).The LBEARING field specifies the directed distancemeasured to the right from the origin to the left edgeof the left-most inked pixel in the glyph.The RBEARING field specifies the directed distance(measured to the right) from the origin to the rightedge of the right-most inked pixel in the glyph.The WIDTH field specifies the directed distance(measured to the right) from the origin to the positionwhere the next character should appear (called the‘‘escapement point’’). This distance includes anywhitespace used for intercharacter padding and is alsoreferred to as the ‘‘logical width’’ or ‘‘horizontalescapement.’’The ASCENT field specifies the directed distance(measured up) from the baseline to the top edge of thetop-most inked pixel in the glyph.The DESCENT field specifies the directed distance(measured down) from the baseline to the bottom edge ofthe bottom-most inked pixel.The ATTRIBUTES field specifies glyph-specificinformation that is passed through the application. Ifthis value is not being used, it should be zero.The ink bounding box of a glyph is defined to be thesmallest rectangle that encloses all of the inkedpixels. This box has a width of RBEARING - LBEARINGpixels and a height of ASCENT + DESCENT pixels.XFONTINFO: [ flags: CARD32,drawing-direction: { LeftToRight,RightToLeft } char-range: RANGE,default-char: CHAR2B,min-bounds: XCHARINFO,max-bounds: XCHARINFO,font-ascent: INT16,font-descent: INT16,properties: PROPINFO ]This structure specifies attributes related to the fontas a whole.The FLAGS field is a bit mask containing zero or moreof the following boolean values (unspecified bits mustbe zero): AllCharactersExist (1 << 0)InkInside (1 << 1)HorizontalOverlap (1 << 2)which have the following meanings:AllCharactersExistIf this bit is set, all of the characters in therange given by CHAR-RANGE have glyphs encoded inthe font. If this bit is clear, some of thecharacters may not have encoded glyphs.InkInsideIf this bit is set, the inked pixels of each glyphfall within the rectangle described by the font’sascent, descent, origin, and the glyph’sescapement point. If this bit is clear, there maybe glyphs whose ink extends outside thisrectangle.HorizontalOverlapIf this bit is set, the two ink bounding boxes(smallest rectangle enclosing the inked pixels) ofsome pairs of glyphs in the font may overlap whendisplayed side-by-side (i.e. the second characteris imaged at the escapement point of the first) ona common baseline. If this bit is clear, thereare no pairs of glyphs whose ink bounding boxesoverlap.The DRAWING-DIRECTION field contains a hint indicatingwhether most of the character metrics have a positive(or ‘‘LeftToRight’’) logical width or a negative(‘‘RightToLeft’’) logical width. It contains thefollowing alternate values:LeftToRight 0RightToLeft 1The CHAR-RANGE.MIN-CHAR and CHAR-RANGE.MAX-CHAR fieldsspecify the first and last character codes that haveglyphs encoded in this font. All fonts must have atleast one encoded glyph (in which case the MIN-CHAR andMAX-CHAR are equal), but are not required to haveglyphs encoded at all positions between the first andlast characters.The DEFAULT-CHAR field specifies the character code ofthe glyph that the client should substitute forunencoded characters. Requests for extents or bitmapsfor an unencoded character generate zero-filled metricsand a zero-length glyph bitmap, respectively.The MIN-BOUNDS and MAX-BOUNDS fields contain theminimum and maximum values of each of the extents fieldof all encoded characters in the font (i.e.non-existent characters are ignored).The FONT-ASCENT and FONT-DESCENT fields specify thefont designer’s logical height of the font, above andbelow the baseline, respectively. The sum of the twovalues is often used as the vertical line spacing ofthe font. Individual glyphs are permitted to haveascents and descents that are greater than thesevalues.The PROPERTIES field contains the property dataassociated with this font.This structure is padded to 32-bit alignment.4.2. RequestsThis section describes the requests that may be sent by theclient and the replies or errors that are generated inresponse. Versions of the protocol with the same majorversion are required to be upward-compatible.Every request on a given connection is implicitly assigned asequence number, starting with 1, that is used in replies,error, and events. Servers are required to generate repliesand errors in the order in which the corresponding requestsare received. Servers are permitted to add or remove fontsto the list visible to the client between any two requests,but requests must be processed atomically. Each requestpacket is at least 4 bytes long and contains the followingfields: major-opcode: CARD8minor-opcode: CARD8length: CARD16The MAJOR-OPCODE specifies which core request or extensionpackage this packet represents. If the MAJOR-OPCODEcorresponds to a core request, the MINOR-OPCODE contains 8bits of request-specific data. Otherwise, the MINOR-OPCODEspecifies which extension request this packet represents.The LENGTH field specifies the number of 4-byte unitscontained within the packet and must be at least one. Ifthis field contains a value greater than one it is followedby (LENGTH - 1) * 4 bytes of request-specific data. Unlessotherwise specified, unused bytes are not required to bezero.If a request packet contains too little or too much data,the server returns a Length error. If the server runs outof internal resources (such as memory) while processing arequest, it returns an Alloc error. If a server isdeficient (and therefore non-compliant) and is unable toprocess a request, it may return an Implementation error.If a client uses an extension request without previouslyhaving issued a QueryExtension request for that extension,the server responds with a Request error. If the serverencounters a request with an unknown MAJOR-OPCODE orMINOR-OPCODE, it responds with a Request error. At most oneerror is generated per request. If more than one errorcondition is encountered in processing a requests, thechoice of which error is returned is server-dependent.Core requests have MAJOR-OPCODE values between 0 and 127,inclusive. Extension requests have MAJOR-OPCODE valuesbetween 128 and 255, inclusive, that are assigned by by theserver. All MINOR-OPCODE values in extension requests arebetween 0 and 255, inclusive.Each reply is at least 8 bytes long and contains thefollowing fields:type: CARD8 value of 0data-or-unused: CARD8sequence-number: CARD16length: CARD32The TYPE field has a value of zero. The DATA-OR-UNUSEDfield may be used to encode one byte of reply-specific data(see Section 5.2 on request encoding). Theleast-significant 16 bits of the sequence number of therequest that generated the reply are stored in theSEQUENCE-NUMBER field. The LENGTH field specifies thenumber of 4-byte units in this reply packet, including thefields described above, and must be at least two. If LENGTHis greater than two, the fields described above are followedby (LENGTH - 2) * 4 bytes of additional data.Requests that have replies are described using the followingsyntax: RequestNamearg1: type1arg2: type2...argN: typeN=>result1: type1result2: type2... resultM: typeMErrors: kind1, kind2 ..., kindKDescriptionIf a request does not generate a reply, the‘‘=>’’ and resultlines are omitted. If a request may generate multiplereplies, the ‘‘=>’’ is replaced by a ‘‘=>+’’. In theauthorization data exchanges in the initial connection setupand the CreateAC request, ‘‘->’’ indicates data sent by theclient in response to data sent by the server.The protocol begins with the establishment of a connectionover a mutually-understood virtual stream:open connectionbyte-order: BYTEclient-major-protocol-version: CARD16client-minor-protocol-version: CARD16authorization-protocols: LISTofAUTHThe initial byte of the connection specifies the BYTE-ORDERin which subsequent 16-bit and 32-bit numeric values are tobe transmitted. The octal value 102 (ASCII uppercase ‘B’)indicates that the most-significant byte is to betransmitted first; the octal value 154 (ASCII lowercase ‘l’)indicates that the least-significant byte is to betransmitted first. If any other value is encountered theserver closes the connection without any response.The CLIENT-MAJOR-PROTOCOL-VERSION andCLIENT-MINOR-PROTOCOL-VERSION specify which version ofthe font service protocol the client would like to use.If the client can support multiple versions, thehighest version should be given. This version of theprotocol has a major version of 2 and a minor versionof 0.The AUTHORIZATION-PROTOCOLS contains a list of protocolnames and optional initial data for which the clientcan provide information. The server may use this todetermine which protocol to use or as part of theinitial exchange of authorization data.=>status: { Success, Continue,Busy, Denied }server-major-protocol-version: CARD16server-minor-protocol-version: CARD16alternate-servers-hint: LISTofALTERNATESERVERauthorization-index: CARD8authorization-data: LISTofBYTEThe SERVER-MAJOR-PROTOCOL-VERSION andSERVER-MINOR-PROTOCOL-VERSION specify the version ofthe font service protocol that the server expects fromthe client. If the server supports the versionspecified by the client, this version number should bereturned. If the client has requested a higher versionthan is supported by the server, the server’s highestversion should be returned. Otherwise, if the clienthas requested a lower version than is supported by theserver, the server’s lowest version should be returned.It is the client’s responsibility to decide whether ornot it can match this version of the protocol.The ALTERNATE-SERVERS-HINT is a list of other fontservers that may have related sets of fonts (determinedby means outside this protocol, typically by the systemadministrator). Clients may choose to contact thesefont servers if the connection is rejected or lost.The STATUS field indicates whether the server accepted,rejected, or would like more information about theconnection. It has one of the following alternatevalues: Success 0Continue 1Busy 2Denied 3If STATUS is Denied, the server has rejected theclient’s authorization information. If STATUS is Busy,the server has simply decided that it cannot providefonts to this client at this time (it may be able to ata later time). In both cases, AUTHORIZATION-INDEX isset to zero, no authorization-data is returned, and theserver closes the connection after sending the datadescribed so far.Otherwise the AUTHORIZATION-INDEX is set to the index(beginning with 1) into the AUTHORIZATION-PROTOCOLSlist of the protocol that the server will use for thisconnection. If the server does not want to use any ofthe given protocols, this value is set to zero. TheAUTHORIZATION-DATA field is used to send backauthorization protocol-dependent data to the client(such as a challenge, authentication of the server,etc.).If STATUS is Success, the following section of protocol isomitted. Otherwise, if STATUS is Continue, the serverexpects more authorization data from the client (i.e. theconnection setup is not finished, so no requests or eventsmay be sent):->more-authorization-data: STRING8=>status: { Success, Continue,Busy, Denied }more-authorization-data: LISTofBYTEThe values in STATUS have the same meanings as describedabove. This section of protocol is repeated until theserver either accepts (sets STATUS to Success) or rejects(sets STATUS to Denied or Busy) the connection.Once the connection has been accepted and STATUS is Success,an implicit AccessContext is created for the authorizationdata and the protocol continues with the following data sentfrom the server:=>remaining-length: CARD32maximum-request-length: CARD16release-number: CARD32vendor: STRING8The REMAINING-LENGTH specifies the length in 4-byte units ofthe remaining data to be transmitted to the client. TheMAXIMUM-REQUEST-LENGTH specifies the largest request size in4-byte units that is accepted by the server and must have avalue of at least 4096. Requests with a length field largerthan this value are ignored and a Length error is returned.The VENDOR string specifies the name of the manufacturer ofthe font server. The RELEASE-NUMBER specifies theparticular release of the server in a manufacturer-dependentmanner.After the connection is established and the setupinformation has been exchanged, the client may issue any ofrequests described below:NoOp Errors: AllocThis request does nothing. It is typically used inresponse to a KeepAlive event.ListExtensions=> names: LISTofSTRING8Errors: AllocThis request returns the names of the extensionpackages that are supported by the server. Extensionnames are case-sensitive and are encoded in ISO 8859-1.QueryExtensionname: STRING8=> present: BOOLmajor-version: CARD16minor-version: CARD16major-opcode: CARD8first-event: CARD8number-events: CARD8first-error: CARD8number-errors: CARD8Errors: AllocThis request determines whether or not the extensionpackage specified by NAME (encoded in ISO 8859-1) issupported by the server and that there is sufficientnumber of major opcode, event, and error codesavailable. If so, then PRESENT is set to True,MAJOR-VERSION and MINOR-VERSION are set to therespective major and minor version numbers of theprotocol that the server would prefer; MAJOR-OPCODE isset to the value to use in extension requests;FIRST-EVENT is set to the value of the firstextension-specific event code or zero if the extensiondoes not have any events; NUMBER-EVENTS is set to thenumber of new events that the event defines;FIRST-ERROR is set to the value of the firstextension-specific error code or zero if the extensiondoes not define any new errors; and NUMBER-ERRORS isset to the number of new errors the extension defines.Otherwise, PRESENT is set to False and the remainingfields are set to zero.The server is free to return different values todifferent clients. Therefore, clients must use thisrequest before issuing any of the requests in the namedextension package or using the SetEventMaskrequest thisextension’s events. Otherwise, a Request error isreturned.ListCataloguespattern: STRING8 max-names: CARD32=>+replies-following-hint: CARD32names: LISTofSTRING8Errors: AllocThis request returns a list of at most MAX-NAMES namesof collections (called catalogues) of fonts that matchthe specified PATTERN. In the pattern (which isencoded in ISO 8859-1), the ‘?’ character (octal 77)matches any single character; the ‘*’ character (octal52) matches any series of zero or more characters; andalphabetic characters match either upper- or lowercase.The returned NAMES are encoded in ISO 8859-1 and maycontain mixed character cases.If PATTERN is of zero length or MAX-NAMES is equal tozero, one reply containing a zero-length list of namesis returned. This may be used to synchronize theclient with the server.Servers are free to add or remove catalogues to the setreturned by ListCatalogues between any two requests.This request is not cumulative; repeated uses areprocessed in isolation and do result in an iterationthrough the list.To reduce the amount of buffering needed by the server,the list of names may be split across several replypackets, so long as the names arrive in the same orderthat they would have appeared had they been in a singlepacket. The REPLIES-FOLLOWING-HINT field in all butthe last reply contains a positive value that specifiesthe number of replies that are likely, but notrequired, to follow. In the last reply, which maycontain zero or more names, this field is set to zero.SetCataloguesnames: LISTofSTRING8Errors: Alloc, NameThis request sets the list of catalogues whose fontsshould be visible to the client. The union of thefonts provided by each of the named catalogues formsthe set of fonts whose names match patterns inListFonts, ListFontsWithXInfo, and OpenBitmapFontrequests. The catalogue names are case-insensitive andare encoded in ISO 8859-1. A zero-length list resetsthe client’s catalogue list to the server-dependentdefault.If any of the catalogue names are invalid, a Name erroris returned and the request is ignored.GetCatalogues=>names: LISTofSTRING8Errors: AllocThis request returns the current list of cataloguenames (encoded in ISO 8859-1) associated with theclient. These catalogues determine the set of fontsthat are visible to ListFonts, ListFontsWithXInfo, andOpenBitmapFont. A zero-length list indicates theserver’s default set of fonts. Catalogue names arecase-insensitive and may be returned in mixed case.SetEventMaskextension-opcode: CARD8event-mask: EVENTMASKErrors: EventMask, RequestThis request specifies the set of maskable events thatthe extension indicated by EXTENSION-OPCODE (or zerofor the core) should generate for the client. Eventmasks are limited in scope to the extension (or core)for which they are defined, so expressing interest inevents from one or more extensions requires multipleuses of this request.The default event mask if SetEventMask has not beencalled is zero, indicating no interest in any maskableevents. Some events are not maskable and cannot beblocked.If EXTENSION-OPCODE is not a valid extension opcodepreviously returned by QueryExtension or zero, aRequest error is returned. If EVENT-MASK contains anybits that do not correspond to valid events for thespecified extension (or core), an EventMask error isreturned and the request is ignored.GetEventMaskextension-opcode: CARD8=> event-mask: EVENTMASKErrors: RequestThis request returns the set of maskable core eventsthe extension indicated by EXTENSION-OPCODE (or thecore if zero) should generate for the client.Non-maskable events are always sent to the client.If EXTENSION-OPCODE is not a valid extension opcodepreviously returned by QueryExtension or zero, aRequest error is returned.CreateACac: ACCESSCONTEXTauthorization-protocols: LISTofAUTH=> status: { Success, Continue, Denied }authorization-index: CARD8authorization-data: LISTofBYTEErrors: IDChoiceThis request creates a new AccessContext object withinthe server containing the specified authorization data.When this AccessContext is selected by the client usingthe SetAuthorization request, the data may be used bythe server to determine whether or not the clientshould be granted access to particular fontinformation.If STATUS is Denied, the server rejects the client’sauthorization information and does not associate ACwith any valid AccessContext. In this case,AUTHORIZATION-INDEX is set to zero, and zero bytes ofAUTHORIZATION-DATA is returned.Otherwise, AUTHORIZATION-INDEX is set to the index(beginning with 1) into the AUTHORIZATION-PROTOCOLSlist of the protocol that the server will use for thisconnection. If the server does not want to use any ofthe given protocols, this value is set to zero. TheAUTHORIZATION-DATA field is used to send backauthorization protocol-dependent data to the client(such as a challenge, authentication of the server,etc.).If STATUS is Continue, the client is expected tocontinue the request by sending the following protocoland receiving the indicated response from the server.This continues until STATUS is set to either Success orDenied. −>more-authorization-data: STRING8=>status: { Success, Continue, Denied }more-authorization-data: LISTofBYTEOnce the connection has been accepted and STATUS isSuccess, the request is complete.If AC is not in the range [1..2^29-1] or is alreadyassociated with an access context, an IDChoice error isreturned.FreeACac: ACCESSCONTEXTErrors: AccessContext, AllocThis request indicates that the specified AC should nolonger be associated with a valid access context. IfAC is also the current AccessContext (as set by theSetAuthorization request), an implicit SetAuthorizationof None is done to restore the AccessContextestablished for the initial connection setup.Operations on fonts that were opened under AC are notaffected. The client may reuse the value of AC in asubsequent CreateAC request.If AC isn’t associated with any valid authorizationpreviously created by CreateAC, AccessContext error isreturned.SetAuthorizationac: ACCESSCONTEXTErrors: AccessContextThis request sets the AccessContext to be used forsubsequent requests (except for QueryXInfo,QueryXExtents8, QueryXExtents16, QueryXBitmaps8,QueryXBitmaps16, and CloseFont which are done under theAccessContext of the corresponding OpenBitmapFont). AnAC of None restores the AccessContext established forthe initial connection setup.If AC is neither None nor a value associated with avalid AccessContext previously created by CreateAC, anAccessContext error is returned.SetResolutionresolutions: LISTofRESOLUTIONErrors: Resolution, AllocThis request provides a hint as to the resolution andpreferred point size of the drawing surfaces for whichthe client will be requesting fonts. The server mayuse this information to set the RESOLUTION_X andRESOLUTION_Y fields of scalable XLFD font names, toorder sets of names based on their resolutions, and tochoose the server-dependent instance that is used whena partially-specified scalable fontname is opened.If a zero-length list of RESOLUTIONS is given, theserver-dependent default value is restored. Otherwise,if elements of all of the specified RESOLUTIONS arenon-zero, the default resolutions for this client arechanged.If a RESOLUTION entry contains a zero, a Resolutionerror is returned and the default resolutions are notchanged.GetResolution=> resolutions: LISTofRESOLUTIONErrors: AllocThis request returns the current list of defaultresolutions. If a client has not performed aSetResolution, a server-dependent default value isreturned.ListFontspattern: STRING8 max-names: CARD32=>+replies-following-hint: CARD32names: LISTofSTRING8Errors: AllocThis request returns a list of at most MAX-NAMES fontnames that match the specified PATTERN, according tomatching rules of the X Logical Font DescriptionConventions [3]. In the pattern (which is encoded inISO 8859-1) the ‘?’ character (octal 77) matches anysingle character; the ‘*’ character (octal 52) matchesany series of zero or more characters; and alphabeticcharacters match either upper- or lowercase. Thereturned NAMES are encoded in ISO 8859-1 and maycontain mixed character cases. Font names are notrequired to be in XLFD format.If PATTERN is of zero length or MAX-NAMES is equal tozero, one reply containing a zero-length list of namesis returned. This may be used to synchronize theclient with the server.Servers are free to add or remove fonts to the setreturned by ListFonts between any two requests. Thisrequest is not cumulative; repeated uses are processedin isolation and do result in an iteration through thelist.To reduce the amount of buffering needed by the server,the list of names may be split across several replypackets, so long as the names arrive in the same orderthat they would have appeared had they been in a singlepacket. The REPLIES-FOLLOWING-HINT field in all butthe last reply contains a positive value that specifiesthe number of replies that are likely, but notrequired, to follow. In the last reply, which maycontain zero or more names, this field is set to zero.ListFontsWithXInfopattern: STRING8max-names: CARD32=>+replies-following-hint: CARD32info: XFONTINFOname: STRING8Errors: AllocThis request is similar to ListFonts except that aseparate reply containing the name, header, andproperty data is generated for each matching font name.Following these replies, if any, a final replycontaining a zero-length NAME and no INFO is sent.The REPLIES-FOLLOWING-HINT field in all but the lastreply contains a positive value that specifies thenumber of replies that are likely, but not required, tofollow. In the last reply, this field is set to zero.If PATTERN is of zero length or if MAX-NAMES is equalto zero, only the final reply containing a zero-lengthNAME and no INFO is returned. This may be used tosynchronize the client with the server.OpenBitmapFontfontid: FONTIDpattern: STRING8format-mask: BITMAPFORMATMASKformat-hint: BITMAPFORMAT=> otherid: FONTID or Noneotherid-valid: BOOLcachable: BOOLErrors: IDChoice, Name, Format, AccessContext, AllocThis request looks for a server-dependent choice of thefont names that match the specified PATTERN accordingto the rules described for ListFonts. If no matchesare found, a Name error is returned. Otherwise, theserver attempts to open the font associated with thechosen name.Permission to access the font is determined by theserver according the licensing policy used for thisfont. The server may use the client’s currentAccessContext (as set by the most recentSetAuthorization request or the original connectionsetup) to determine any client-specific sets ofpermissions. After the font has been opened, theclient is allowed to specify a new AccessContext withSetAuthorization or release the AccessContext usingFreeAC. QueryXInfo, QueryXExtents8, QueryXExtents16,QueryXBitmaps8, QueryXBitmaps16, CloseFont requests onthis FONTID are performed according to permissionsgranted at the time of the OpenBitmapFont request.If the server is willing and able to detect that theclient has already opened the font successfully(possibly under a different name), the OTHERID fieldmay be set to one of the identifiers previously used toopen the font. The OTHERID-VALID field indicateswhether or not OTHERID is still associated with an openfont: if it is True, the client may use OTHERID as analternative to FONTID. Otherwise, if OTHERID-VALID isFalse, OTHERID is no longer open but has not beenreused by a subsequent OpenBitmapFont request.If OTHERID is set to None, then OTHERID-VALID should beset to False.The FORMAT-MASK indicates which fields in FORMAT-HINTthe client is likely to use in subsequent GetXBitmaps8and GetXBitmaps16 requests. Servers may wish to usethis information to precompute certain values.If CACHABLE is set to True, the client may cache thefont (so that redundant opens of the same font may beavoided) and use it with all AccessContexts during thelife of the client without violating the font’slicensing policy. This flag is typically set whenevera font is unlicensed or is licensed on a per-displaybasis. If CACHABLE is False, the client should reopenthe font for each AccessContext.The server is permitted to add to or remove from theset of fonts returned by ListFonts between any tworequests, though mechanisms outside the protocol.Therefore, it is possible for this request (which isatomic) to return a different font than would resultfrom separate a ListFonts followed by an OpenBitmapFontwith a non-wildcarded font name.If FONTID is not in the range [1..2^29-1] or if it isalready associated with an open font, an IDChoice erroris returned. If no font is available that matches thespecified PATTERN, a Name error is returned. If thefont is present but the client is not permitted access,an AccessContext error is returned. If FORMAT-MASK hasany unspecified bits set or if any of the fields inFORMAT-HINT indicated by FORMAT-MASK are invalid, aFormat error is returned.QueryXInfofontid: FONTID=> info: XFONTINFOErrors: Font, AllocThis request returns the font header and propertyinformation for the open font associated with FONTID.If FONTID is not associated with any open fonts, a Fonterror is returned.QueryXExtents8fontid: FONTIDrange: BOOLchars: STRING8=> extents: LISTofXCHARINFOErrors: Font, Range, AllocThis request is equivalent to QueryXExtents16 exceptthat it uses 1-byte character codes.QueryXExtents16fontid: FONTIDrange: BOOLchars: LISTofCHAR2B=> extents: LISTofXCHARINFOErrors: Font, Range, AllocThis request returns a list of glyph extents from theopen font associated with FONTID for the series ofcharacters specified by RANGE and CHARS.If RANGE is True, each succeeding pair of elements inCHARS is treated as a range of characters for whichextents should be returned. If CHARS contains an oddnumber of elements, the font’sXFONTINFO.CHAR-RANGE.MAX-CHAR is implicitly appended tothe list. If CHARS contains no elements, the list isimplicitly replaced with the font’sXFONTINFO.CHAR-RANGE. If any of the resultingcharacter ranges are invalid, a Range error isreturned. Otherwise, the character ranges areconcatenated in the order given by CHARS to produce aset of character codes for which extents are returned.If RANGE is False, then CHARS specifies the set ofcharacter codes for which extents are returned. IfCHARS is of zero length, then a zero-length list ofextents is returned.The extents for each character code in the resultingset (which may contain duplicates) are returned in theorder in which the character codes appear in the set.At least one metric for each character shall benon-zero unless the character is not encoded in thefont, in which case all-zero metrics are returned. Ablank, zero-width character can be encoded withnon-zero but equal left and right bearings.If FONTID is not associated with any open fonts, a Fonterror is returned. If RANGE is True and CHARS containsany invalid ranges, a Range error is returned.QueryXBitmaps8fontid: FONTIDrange: BOOLchars: STRING8format: BITMAPFORMAT=>+replies-following-hint: CARD32offsets: LISTofOFFSET32bitmaps: LISTofBYTEErrors: Font, Range, Format, AllocThis request is equivalent to QueryXBitmaps16 exceptthat it uses 1-byte character codes.QueryXBitmaps16fontid: FONTIDrange: BOOLchars: LISTofCHAR2Bformat: BITMAPFORMAT=>+replies-following-hint: CARD32offsets: LISTofOFFSET32bitmaps: LISTofBYTEErrors: Font, Range, Format, AllocThis request returns a list of glyph bitmaps from theopen font associated with FONTID for the series ofcharacters specified by RANGE and CHARS.If RANGE is True, each succeeding pair of elements inCHARS is treated as a range of characters for whichbitmaps should be returned. If CHARS contains an oddnumber of elements, the font’sXFONTINFO.CHAR-RANGE.MAX-CHAR is implicitly appended tothe list. If CHARS contains no elements, the list isimplicitly replaced with the font’sXFONTINFO.CHAR-RANGE. If any of the resultingcharacter ranges are invalid, a Range error isreturned. Otherwise, the character ranges areconcatenated in the order given by CHARS to produce aset of character codes for which bitmaps are returned.If RANGE is False, then CHARS specifies the set ofcharacter codes for which bitmaps are returned. IfCHARS is of zero length, then a single reply containinga zero-length list of offsets and bitmaps is returned.If any of the resulting character ranges are invalid, aRange error is returned. Otherwise, the resultingcharacter ranges are concatenated in the order given byCHARS to produce a set of character codes for whichbitmaps are returned.The server is free to return the glyph bitmaps inmultiple replies to reduce the amount of buffering thatis necessary. In this situation, the set of charactersobtained above is partitioned into animplementation-dependent number of ordered,non-overlapping subsets containing runs of one or moreconsecutive characters. The global ordering ofcharacters must be maintained such that concatenatingthe subsets in order that they were produced yields theoriginal set. A reply is generated for each subset, inthe order that it was produced.For each character in a subset, an image of thatcharacter’s glyph is described by a rectangle of bitscorresponding to the pixels specified byFORMAT.IMAGE-RECT. Within the image, set and clearbits represent inked and non-inked pixels,respectively.Each scanline of a glyph image, from top to bottom, iszero-padded on the right to a multiple of the number ofbits specified by FORMAT.SCANLINE-PAD. The scanline isthen divided from left to right into a sequence ofFORMAT.SCANLINE-UNIT bits. The bits of each unit arethen arranged such that the left-most pixel is storedin the most- or least-significant bit, according toFORMAT.BIT-ORDER-MSB. The bytes of each unit are thenarranged such that the most- or least-significant byte,according to FORMAT.BYTE-ORDER-MSB, is transmittedfirst. Finally, the units are arranged such that theleft-most is transmitted first and the right-most istransmitted last.The individual images within a subset are thenconcatenated in a server-dependent order to form theBITMAPS data of the reply. If a glyph image isduplicated within a reply, the server is free to returnfewer (but at least one) copies of the image. If acharacter is not encoded within the font, a zero-lengthbitmap is substituted for this character. Each glyphimage must begin at a bit position that is a multipleof the FORMAT.SCANLINE-UNIT.The OFFSETS array in a reply contains one entry foreach character in the subset being returned, in theorder that the characters appear in the subset. Eachentry specifies the starting location in bytes and sizein bytes of the corresponding glyph image in theBITMAPS data of that reply (i.e. an offset may notrefer to data in another reply).The REPLIES-FOLLOWING-HINT field in all but the lastreply contains a positive value that specifies thenumber of replies that are likely, but not required, tofollow. In the last reply, which may contain data forzero or more characters, this field is set to zero.If FONTID is not associated with any open fonts, a Fonterror is returned. If RANGE is True and CHARS containsany invalid ranges, a Range error is returned. IfFORMAT is invalid, a Format error is returned.CloseFontfontid: FONTIDErrors: Font, AllocThis request indicates that the specified FONTID shouldno longer be associated with an open font. The serveris free to release any client-specific storage orlicenses allocated for the font. The client may reusethe value of FONTID in a subsequent OpenBitmapFontrequest.If FONTID is not associated with any open fonts, a Fonterror is returned.close connectionWhen a connection is closed, a CloseFont is done on allfonts that are open on the connection. In addition,the server is free to release any storage or licensesallocated on behalf of the client that made theconnection.4.3. ErrorsAll errors are at least 16 bytes long and contain thefollowing fields:type: CARD8 value of 1error-code: CARD8sequence-number: CARD16length: CARD32timestamp: TIMESTAMPmajor-opcode: CARD8minor-opcode: CARD8data-or-unused: CARD16The TYPE field has a value of one. The ERROR-CODE fieldspecifies which error occurred. Core errors codes are inthe range 0 through 127, extension error codes are in therange 128 through 255. The SEQUENCE-NUMBER field containsthe least significant 16 bits of the sequence number of therequest that caused the error. The LENGTH field specifiesthe length of the error packet in 4-byte units and must havea value of at least 4. The TIMESTAMP specifies the servertime when the error occurred. The MAJOR-OPCODE andMINOR-OPCODE (zero for core requests) fields specify thetype of request that generated the error. TheDATA-OR-UNUSED field may be used for 16 bits oferror-specific information. If LENGTH is greater than four,these fields are followed by (LENGTH - 4) * 4 bytes of extradata.The following errors are defined for the core protocol:Requestdata-or-unused: CARD16 unusedThis error is generated by any request that has anunknown combination of major and minor request numbers,or by any extension request that is issued before aQueryExtension of that extension.Formatdata-or-unused: CARD16 unusedformat: BITMAPFORMAT bad format valueThis error is generated by the use of an invalidBITMAPFORMAT in the OpenBitmapFont, QueryXBitmaps8, andQueryXBitmaps16 requests. The value that caused theerror is included as extra data.Font data-or-unused: CARD16 unusedfontid: FONTID bad font identifierThis error is generated by an invalid FONTID in theQueryXInfo, QueryXExtents8, QueryXExtents16,QueryXBitmaps8, QueryXBitmaps16, and CloseFontrequests. The value that caused the error is includedas extra data.Rangedata-or-unused: CARD16 unusedrange: RANGE bad rangeThis error is generated by an invalid RANGE in theQueryXExtents8, QueryXExtents16, QueryXBitmaps8,QueryXBitmaps16 requests. The value that caused theerror is included as extra data.EventMaskdata-or-unused: CARD16 unusedevent-mask: EVENTMASK bad event maskThis error is generated by an invalid EVENTMASK in theSetEventMask request. The value that caused the erroris included as extra data.AccessContextdata-or-unused: CARD16 unusedac: ACCESSCONTEXT unaccepted AccessContextThis error is generated by an invalid ACCESSCONTEXT inthe FreeAC or SetAuthorization request or by anOpenBitmapFont request performed without sufficientauthorization. In the first two cases, theACCESSCONTEXT of the errant request is returned asextra data. In the third case, the currentACCESSCONTEXT is returned as extra data.IDChoicedata-or-unused: CARD16 unusedid: ID bad identifierThis error is generated by an invalid or alreadyassociated ACCESSCONTEXT identifier in a CreateACrequest or FONTID identifier in an OpenBitmapFontrequest. The value that caused the error is includedas extra data.Name data-or-unused: CARD16 unusedThis error is generated by a font name pattern thatmatches no fonts in an OpenBitmapFont request or nocatalogue names in a SetCatalogues request.Resolutiondata-or-unused: CARD16 X value of errant resolutiony-resolution: CARD16 Y value of errantresolutionpoint-size: CARD16 point size of errantresolutionThis error is generated in response to an invalidRESOLUTION structure in a SetResolution request. Thevalue that caused the error is included in theDATA-OR-UNUSED field and as extra data.Allocdata-or-unused: CARD16 unusedThis error is generated by any request for which theserver lacks sufficient resources (especially memory).Lengthdata-or-unused: CARD16 unusedlength: CARD32 bad length valueThis error is generated by any request that has alength field greater than (MAXIMUM-REQUEST-LENGTH * 4)bytes. The value that caused the error is included asextra data.Implementationdata-or-unused: CARD16 unusedThis error may be generated in response to any requestthat the server is unable to process because it isdeficient. Use of this error is highly discouraged andindicates lack of conformance to the protocol.Additional errors may be defined by extensions.4.4. EventsEvents may be generated in response to requests or at theserver’s discretion after the initial connection setupinformation has been exchanged. Each event is at least 12bytes long and contains the following fields:type: CARD8 value of 2event-code: CARD8sequence-number: CARD16length: CARD32timestamp: TIMESTAMPThe TYPE field contains the value 2. The EVENT-CODE fieldspecifies the number of the event and is in the range 0-127for core events or the range 128-255 for extensions. TheSEQUENCE-NUMBER field specifies the least significant 16bits of the sequence number of the last request to have beenprocessed by the server. The LENGTH field specifies thenumber of 4-byte units in this event packet and must alwayshave a value of at least 3. The TIMESTAMP field specifiesthe server time when the event occurred. If LENGTH isgreater than three, these fields are followed by (LENGTH -3) * 4 bytes of additional data.Events are described using the following syntax:EventName arg1: type1...argN: typeNDescriptionIf an event does not provide any extra arguments, thearg1...argN lines are omitted from the description.The core X Font Service protocol defines the followingevents:KeepAliveThis unsolicited, nonmaskable event may be sent by theserver to verify that the connection has not beenbroken (for transports that do not provide thisinformation). Clients should acknowledge receipt ofthis request by sending any request (such as NoOp).CatalogueListNotifyadded: BOOLdeleted: BOOLThis event is sent to clients that have includedCatalogueListChangeMask in their core event maskwhenever the list of catalogues that are available haschanged. The ADDED field is True if new catalogueshave been added to the server, otherwise it is False.The DELETED field is True if any existing catalogueshave been removed from the server, otherwise it isFalse.FontListNotifyadded: BOOLdeleted: BOOLThis event is sent to clients that have includedFontListChangeMask in their event mask whenever thelist of fonts that are provided by the currentlyselected catalogues has changed. The ADDED field isTrue if new fonts have been added to any of thecatalogues currently used by the client, otherwise itis False. The DELETED field is True if any existingfonts have been removed from any of catalogues used bythe client, otherwise it is False.Additional events may be defined by extensions.5. Protocol EncodingNumbers that are prefixed with ‘‘#x’’ are in hexadecimal(base 16). All other numbers are in decimal. Requests,replies, errors, events, and compound types are describedusing the syntax:Namecount contents name...count contents namewhere COUNT is the number of bytes in the data streamoccupied by this field, CONTENTS is the name of the type asgiven in Section 4 or the value if this field contains aconstant, and NAME is a description of this field.Objects containing counted lists use a lowercasesingle-letter variable (whose scope is limited to therequest, reply, event, or error in which it is found) torepresent the number of objects in the list. Thesevariables, and any expressions in which they are used,should be treated as unsigned integers. Multiple copies ofan object are indicated by CONTENTS prefix ‘‘LISTof’’.Unused bytes (whose value is undefined) will have a blankCONTENTS field and a NAME field of ‘‘unused’’. Zeroed bytes(whose value must be zero) will have a blank CONTENTS fieldand a NAME field of ‘‘zero’’. The expression pad(e) refersto the number of bytes needed to round a value ‘‘e’’ up tothe closed multiple of four:pad(e) = (4 - (e mod 4)) mod 45.1. Data TypesACCESSCONTEXT4 CARD32 access context with at least one of thefollowing bits set:#x1fffffffbut none of the following bits set:#xe0000000 zeroBITMAPFORMAT4 CARD32 value, union of the following bits:BITMAPFORMATMASK4 CARD32 value, mask of the following bits:BOOL1 BOOL boolean, one of the following values:0 False1 TrueBYTE1 BYTE unsigned byte of dataCARD81 CARD8 8-bit unsigned integerCARD162 CARD16 16-bit unsigned integerCARD324 CARD32 32-bit unsigned integerCHAR2B1 CARD8 byte11 CARD8 byte2EVENTMASK4 CARD32 event maskextensions define their own sets of bitsFONTID4 CARD32 font identifier with at least one ofthe following bits set:INT81 INT8 8-bit signed integerINT162 INT16 16-bit signed integerINT324 INT32 32-bit signed integerOFFSET324 CARD32 position (or integer value)4 CARD32 lengthPROPINFO4 n number of PROPOFFSET components4 m number of bytes of property data20*n PROPOFFSET property offsets into data blockm LISTofBYTE property data blockPROPOFFSET8 OFFSET32 name in data block8 OFFSET32 value in data block1 CARD8 type, one of the following values:0 String1 Unsigned2 Signed3 zeroRANGE2 CHAR2B minimum character code2 CHAR2B maximum character codeRESOLUTION2 CARD16 x resolution in pixels per inch2 CARD16 y resolution in pixels per inch2 CARD16 point size in decipointsSTRNAME1 n length of namen STRING8 nameSTRING8n LISTofBYTE array of 8-bit character valuesTIMESTAMP4 CARD32 milliseconds since server time originXCHARINFO2 INT16 left bearing2 INT16 right bearing2 INT16 width2 INT16 ascent2 INT16 descent2 CARD16 attributesXFONTINFO4 CARD32 flags, union of the following bits:4 RANGE range of characters in font1 CARD8 drawing direction0 LeftToRight1 RightToLeft1 unused2 CHAR2B default character12 XCHARINFO minimum bounds12 XCHARINFO maximum bounds2 INT16 font ascent2 INT16 font descentn PROPINFO property data5.2. RequestsIf STATUS is Busy or Denied, the protocol stops and theconnection is closed. If STATUS is Continue, the client isexpected to respond with additional data, to which theserver responds with a new status value and more data. Thisdialog continues until the status is set to Success, oruntil the server sets STATUS to Busy or Denied and closesthe connection:When STATUS is Success, the protocol resumes with thefollowing sent by the server:Once the connection has been established, the client maysend the following requests:If STATUS is Continue, the client is expected to respondwith additional data, to which the server responds with anew status value and more data. This dialog continues untilthe status is set to Success, Busy, or Denied at which pointthe request is finished.5.3. Errors5.4. Events6. AcknowledgementsThis document represents the culmination of several years ofdebate and experiments done under the auspices of the MIT XConsortium font working group. Although this was a groupeffort, the author remains responsible for any errors oromissions. The protocol presented here was primarilydesigned by Jim Fulton, Keith Packard, and Bob Scheifler.Special thanks goes to Ned Batchelder, Jim Flowers, and AxelDeininger for their invigorating comments which never failedto make this a better document. Stephen Gildea editedversion 2 of this document. Finally, David Lemke deservesgreat credit for designing and coding the sampleimplementation.7. ReferencesAll of the following documents are X Consortium standardsavailable from the X Consortium.[1] Scheifler, Robert W. ‘‘X Window System ProtocolVersion 11’’[2] Adobe Systems. ‘‘Bitmap Distribution Format 2.1’’[3] X Consortium. ‘‘X Logical Font DescriptionConventions, Version 1.5’’ 1

X Font Service Protocol X11, Release 6.4

Appendix A

Suggested Licensing Policies

The authorization data passed by the client in the initial connection setup information may be used by the font server to implement restrictions on which fonts may be accessed. Furthermore, the font server is free to refuse new connections at any time.

Configuration or management of the license restrictions is outside the scope of the font service protocol and is done in a server-dependent manner. Possible policies might include, but are not limited to, combinations of the following:

It should be noted that chaining of font servers (obtaining font data from other font servers) may conflict with certain license policies.
2

X Font Service Protocol X11, Release 6.4

Appendix B

Implementation Suggestions

Font server implementations will probably wish to use techniques such as the following to avoid limits on the number of simultaneous connections:

3

X Font Service Protocol X11, Release 6.4

4

Table of Contents

. . . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . .
1

. . . . . . . . . . . . . . . . . . .
1

. . . . .
2

. . . . . .
3

i