














		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 (C) 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 documen-
tation is provided ``as is'' without express or implied war-
ranty.

Copyright (C) 1994 X Consortium

Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documenta-
tion files (the ``Software''), to deal in the Software with-
out 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 fol-
lowing 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 PUR-
POSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE X CONSOR-
TIUM 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 Con-
sortium 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.  Introduction

The management of fonts in large, heterogeneous environments
is one of the hardest aspects of using the X Window System.*
Multiple formats and the lack of a consistent mechanism for
exporting font data to all displays on a network prevent the
transparent use of applications across different display
platforms.  The X Font Service protocol is designed to
address this and other issues, with specific emphasis on the
needs of the core X protocol.  Upward-compatible changes
(typically in the form of new requests) are expected as con-
sensus is reached on new features (particularly outline font
support).

Currently, most X displays use network file protocols such
as NFS and TFTP to obtain raw font data which they parse
directly.  Since a common binary format for this data
doesn't exist, displays must be able to interpret a variety
of formats if they are to be used with different application
hosts.	This leads to wasted code and data space and a loss
of interoperability as displays are used in unforeseen envi-
ronments.

By moving the interpretation of font data out of the X
server into a separate service on the network, these prob-
lems can be greatly reduced.  In addition, new technologies,
such as dynamically generating bitmaps from scaled or out-
line fonts, can be provided to all displays transparently.
For horizontal text, caching techniques and increased pro-
cessor power can potentially make rasterization more effi-
cient on large, centralized hosts than on individual dis-
plays.

Each font server provides sets of fonts that may be listed
and queried for header, property, glyph extents, and bitmap
information.  This data is transmitted over the network
using a binary format (with variations to support different
bit- and byte-orders) designed to minimize the amount of
processing required by the display.  Since the font server,
rather than the display, is responsible for parsing the raw
font data, new formats can be used by all displays by modi-
fying a single font server.

From the user's point of view, font servers are simply a new
type of name in the X font path.  Network name services
allow descriptive names (such as DEPARTMENT-FONTS or APPLI-
CATION-FONTS) to be translated into proper network
addresses.  X displays send requests to and read replies
from the font server rather than reading directly from
files.	Since the X Font Service protocol is designed to
allow subsets of the font data to be requested, displays may
-----------
* X Window System is a trademark of X Consortium,
Inc.



			      1





X Font Service Protocol 		    X11, Release 6.4


easily implement a variety of strategies for fine-grained
demand-loading of glyphs.

2.  Architectural Model

In this document, the words ``client'' and ``server'' refer
to the consumer and provider of a font, respectively, unless
otherwise indicated.  It is important to note that in this
context, the X server is also a font client.

The X Font Service protocol does not require any changes to
the core X protocol or to any applications.  To the user,
font servers are simply additional types of font path ele-
ments.	As such, X servers may connect to multiple font
servers, as shown in Figure 2.1.  Although the font protocol
is geared towards the X Window System, it may be also used
by 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 Server

Clients communicate with the font server using the
request/reply/event model over any mutually-understood vir-
tual stream connection (such as TCP/IP, DECnet,* etc.).
Font servers are responsible for providing data in the bit
and byte orders requested by the client.  The set of
requests and events provided in the first version of the X
Font Service protocol is limited to supporting the needs of
the bitmap-oriented core X Window System protocol.  Exten-
sions 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 into
a common format that is transmitted to the client using the
protocol described in Section 4.  New font formats are han-
dled by adding new converters to a font server, as shown in
Figure 2.2.
-----------
*DECnet is a trademark of Digital Equipment Corpo-
ration.



			      2





X Font Service Protocol 		    X11, Release 6.4


		     +------------+
		     |	 client   |
		     | (X server) |
		     +------------+
			   |
			network
			   |
     +--------------------------------------------+
     |						  |
     |		      font server 1		  |
     |						  |
     +-----+-----+-----+-----+----+-----+---+-----+
     | bdf | snf | pcf | atm | f3 | dwf | | | ... |
     +-----+-----+-----+-----+----+-----+-|-+-----+
					  |
				       network
					  |
				    +----------+
				    |	font   |
				    | server 2 |
				    +----------+

	  Figure 2.2:  Where Font Data Comes From

The server may choose to provide named sets of fonts called
``catalogues.''  Clients may specify which of the sets
should be used in listing or opening a font.

An event mechanism similar to that used in the X protocol is
provided for asynchronous notification of clients by the
server.

Clients may provide authorization data for the server to be
used in determining (according to the server's licensing
policy) whether or not access should be granted to particu-
lar fonts.  This is particularly useful for clients whose
authorization changes over time (such as an X server that
can verify the identity of the user).

Implementations that wish to provide additional requests or
events may use the extension mechanism.  Adding to the core
font service protocol (with the accompanying change in the
major or minor version numbers) is reserved to the X Consor-
tium.

3.  Font Server Naming

Font clients that expose font server names to the user are
encouraged to provide ways of naming font servers symboli-
cally (e.g. DEPARTMENT-FONTS).	However, for environments
that lack appropriate name services transport-specific names
are necessary.	Since these names do occur in the protocol,
clients and servers should support at least the applicable
formats described below.  Formats for additional transports



			      3





X Font Service Protocol 		    X11, Release 6.4


may be registered with the X Consortium.

3.1.  TCP/IP Names

The following syntax should be used for TCP/IP names:

	 <TCP name>  ::=  "tcp/" <hostname>":" <ipportnumber> ["/" <cataloguelist>]

where <hostname> is either symbolic (such as
expo.lcs.mit.edu) or numeric decimal (such as 18.30.0.212).
The <ipportnumber> is the port on which the font server is
listening for connections.  The <cataloguelist> string at
the end is optional and specifies a plus-separated list of
catalogues that may be requested.  For example:

	  tcp/expo.lcs.mit.edu:8012/available+special
	  tcp/18.30.0.212:7890


3.2.  DECnet Names

The following syntax should be used for DECnet names:

	 <DECnet name>	::=  "decnet/" <nodename> "::font$" <objname>
		    ["/" <cataloguelist>]

where <nodename> is either symbolic (such as SRVNOD) or the
numeric decimal form of the DECnet address (such as 44.70).
The <objname> is normal, case-insensitive DECnet object
name.  The <cataloguelist> string at the end is optional and
specifies a plus-separated list of catalogues that may be
requested.  For example:

	  DECNET/SRVNOD::FONT$DEFAULT/AVAILABLE
	  decnet/44.70::font$other


4.  Protocol

The protocol described below uses the request/reply/error
model and is specified using the same conventions outlined
in Section 2 of the core X Window System protocol [1]:

o    Data type names are spelled in upper case with no word
     separators, as in:  FONTID

o    Alternate values are capitalized with no word separa-
     tors, as in:  MaxWidth

o    Structure element declarations are in lower case with
     hyphens as word separators, as in:  byte-order-msb






			      4





X Font Service Protocol 		    X11, Release 6.4


			      Note

	  Structure element names are referred to in
	  upper case (e.g. BYTE-ORDER-MSB) when used in
	  descriptions to set them off from the sur-
	  rounding text.  When this document is typeset
	  they will be printed in lower case in a dis-
	  tinct font.


o    Type declarations have the form ``name: type'', as in:
     CARD8: 8-bit byte

o    Comma-separated lists of alternate values are enclosed
     in braces, as in:	{ Min, MaxWidth, Max }

o    Comma-separated lists of structure elements are
     enclosed in brackets, as in:  [ byte1: CARD8, byte2:
     CARD8 ]

A type with a prefix ``LISTof'' represents a counted list of
elements of that type, as in:  LISTofCARD8

4.1.  Data Types

The following data types are used in the core X Font Server
protocol:

ACCESSCONTEXT: ID

     This value is specified in the CreateAC request as the
     identifier to be used when referring to a particular
     AccessContext resource within the server.	These
     resources are used by the server to store client-speci-
     fied authorization information.  This information may
     be used by the server to determine whether or not the
     client should be granted access to particular font
     data.

     In order to preserve the integrity of font licensing
     being performed by the font server, care must be taken
     by a client to properly represent the identity of the
     true user of the font.  Some font clients will in fact
     be servers (for example, X servers) requesting fonts
     for their own clients.  Other font clients may be doing
     work on behalf of a number of different users over time
     (for example, print spoolers).

     AccessContexts must be created (with CreateAC) and
     switched among (with SetAuthorization) to represent all
     of these ``font users'' properly.

ALTERNATESERVER:  [ name:  STRING8,
					   subset:  BOOL ]



			      5





X Font Service Protocol 		    X11, Release 6.4


     This structure specifies the NAME, encoded in ISO
     8859-1 according to Section 3, of another font server
     that may be useful as a substitute for this font
     server.  The SUBSET field indicates whether or not the
     alternate server is likely to only contain a subset of
     the fonts available from this font server.  This infor-
     mation is returned during the initial connection setup
     and may be used by the client to find a backup server
     in case of failure.

AUTH:  [ name:	STRING8,
		data:  LISTofBYTE ]

     This structure specifies the name of an authorization
     protocol and initial data for that protocol.  It is
     used in the authorization negotiation in the initial
     connection setup and in the CreateAC request.

BITMAPFORMAT:

     CARD32 containing the following fields defined by the
     sets 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 are transmit-
     ted in response to QueryXBitmaps8 and QueryXBitmaps16
     requests.

     If the BYTE-ORDER-MSB bit (1 << 0) is set, the Most
     Significant Byte of each scanline unit is returned
     first.  Otherwise, the Least Significant Byte is
     returned first.

     If the BIT-ORDER-MSB bit (1 << 1) is set, the left-most
     bit in each glyph scanline unit is stored in the Most



			      6





X Font Service Protocol 		    X11, Release 6.4


     Significant Bit of each transmitted scanline unit.
     Otherwise, the left-most bit is stored in the Least
     Significant Bit.

     The IMAGE-RECT field specifies a rectangle of pixels
     within the glyph image.  It contains one of the follow-
     ing alternate values:


		    ImageRectMin	(0 << 2)
		    ImageRectMaxWidth	(1 << 2)
		    ImageRectMax	(2 << 2)

     For a glyph with extents XCHARINFO in a font with
     header information XFONTINFO, the IMAGE-RECT values
     have the following meanings:

	  ImageRectMin- This refers to the minimal bounding
	  rectangle surrounding the inked pixels in the
	  glyph.  This is the most compact representation.
	  The edges of the rectangle are:

			     left: XCHARINFO.LBEARING
			     right:	XCHARINFO.RBEARING
			     top:  XCHARINFO.ASCENT
			     bottom:	XCHARINFO.DESCENT


	  ImageRectMaxWidth- This refers to the scanlines
	  between the glyph's ascent and descent, padded on
	  the left to the minimum left-bearing (or 0,
	  whichever is less) and on the right to the maximum
	  right-bearing (or logical-width, whichever is
	  greater).  All glyph images share a common hori-
	  zontal origin.  This is a combination of
	  ImageRectMax in the horizontal direction and
	  ImageRectMin in the vertical direction.  The edges
	  of the rectangle are:

		    left:     min (XFONTINFO.MIN-BOUNDS.LBEARING, 0)
		    right:    max (XFONTINFO.MAX-BOUNDS.RBEARING,
				  XFONTINFO.MAX-BOUNDS.WIDTH)
		    top:      XCHARINFO.ASCENT
		    bottom:   XCHARINFO.DESCENT


	  ImageRectMax - This refers to all scanlines, from
	  the maximum ascent (or the font ascent, whichever
	  is greater) to the maximum descent (or the font
	  descent, whichever is greater), padded to the same
	  horizontal extents as MaxWidth.  All glyph images
	  have the same sized bitmap and share a common ori-
	  gin.	This is the least compact representation,
	  but may be the easiest or most efficient



			      7





X Font Service Protocol 		    X11, Release 6.4


	  (particularly for character cell fonts) for some
	  clients 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 of
	  bits (8, 16, 32, or 64) to which each glyph scan-
	  line is padded before transmitting.  It contains
	  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 of
	  bits (8, 16, 32, or 64) that should be treated as
	  a unit for swapping.	This value must be less than
	  or equal to the number of bits specified by the
	  SCANLINE-PAD.  It contains one of the following
	  alternate values:

			 ScanlineUnit8	     (0 << 12)
			 ScanlineUnit16      (1 << 12)
			 ScanlineUnit32      (2 << 12)
			 ScanlineUnit64      (3 << 12)

	  BITMAPFORMATs are byte-swapped as CARD32s.  All
	  unspecified bits must be zero.

	  Use of an invalid BITMAPFORMAT causes a Format
	  error to be returned.

BITMAPFORMATMASK:   CARD32 mask

     This is a mask of bits representing the fields in a
     BITMAPFORMAT:

		    ByteOrderMask	(1 << 0)
		    BitOrderMask	(1 << 1)
		    ImageRectMask	(1 << 2)
		    ScanlinePadMask	     (1 << 3)
		    ScanlineUnitMask	     (1 << 4)

     Unspecified bits are required to be zero or else a For-
     mat error is returned.





			      8





X Font Service Protocol 		    X11, Release 6.4


BOOL:  CARD8

     This is a boolean value containing one of the following
     alternate values:


		    False		0
		    True	   1


BYTE:  8-bit value

     This is an unsigned byte of data whose encoding is
     determined by the context in which it is used.


CARD8:	8-bit unsigned integer


CARD16:  16-bit unsigned integer


CARD32:  32-bit unsigned integer

     These are unsigned numbers.  The latter two are byte-
     swapped when the server and client have different byte
     orders.


CHAR2B:  [ byte1, byte2:  CARD8 ]

     This structure specifies an individual character code
     within either a 2-dimensional matrix (using BYTE1 and
     BYTE2 as the row and column indices, respectively) or a
     vector (using BYTE1 and BYTE2 as most- and least-sig-
     nificant bytes, respectively).  This data type is
     treated as a pair of 8-bit values and is never byte-
     swapped.  Therefore, the client should always transmit
     BYTE1 first.


EVENTMASK:  CARD32 mask

     This is a mask of bits indicating which of an exten-
     sion's (or the core's) maskable events the client would
     like to receive.  Each bit indicates one or more
     events, and a bit value of one indicates interest in a
     corresponding set of events.  The following bits are
     defined for event masks specified for the core protocol
     (i.e. an EXTENSION-OPCODE of zero in SetEventMask and
     GetEventMask requests):






			      9





X Font Service Protocol 		    X11, Release 6.4


		    CatalogueListChangeMask	  (1 << 0)
		    FontListChangeMask		  (1 << 1)

     If CatalogueListChangeMask is set, client is interested
     in receiving CatalogueListNotify events.  If
     FontListChangeMask is set, the client is interested in
     receiving FontListNotify events.

     Extensions that provide additional events may define
     their own event masks.  These event masks have their
     own scope and may use the same bit values as the core
     or other extensions.

     All unused bits must be set to zero.  In SetEventMask
     requests, if any bits are set that are not defined for
     the extension (or core) for which this EVENTMASK is
     intended (according to the EXTENSION- OPCODE given in
     the SetEventMask request), an EventMask error is gener-
     ated.

     This value is swapped as a CARD32.

FONTID:   ID

     This is specified by the client in the request Open-
     BitmapFont as the identifier to be used when referring
     to a particular open font.

ID:  CARD32

     This is a 32-bit value in which the top 3 bits must be
     clear, and at least 1 other bit must be set (yielding a
     range of 1 through 2^29-1).  It is specified by the
     client to represent objects in the server.  Identifiers
     are scoped according to their type are private to the
     client; thus, the same identifier may be used for both
     a FONTID and an ACCESSCONTEXT as well as by multiple
     clients.

     An ID of zero is referred to as None.

INT8:  8-bit signed integer

INT16:	16-bit signed integer

INT32:	32-bit signed integer

     These are signed numbers.	The latter two are byte-
     swapped when the client and server have different byte
     orders.

OFFSET32:      [  position:   CARD32,
		 length: CARD32 ]




			     10





X Font Service Protocol 		    X11, Release 6.4


     This structure indicates a position and length within a
     block of data.

PROPINFO: [ offsets:	      LISTofPROPOFFSET,
		 data:		   LISTofBYTE ]

     This structure describes the list of properties pro-
     vided by a font.  Strings for all of the properties
     names and values are stored within the data block and
     are 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 type
     of of data for a property.

     The NAME field specifies the position and length (which
     must be greater than zero) of the property name rela-
     tive to the beginning of the PROPINFO.DATA block for
     this font.  The interpretation of the position and
     length of the VALUE field is determined by the TYPE
     field, which contains one of the following alternate
     values:

		    String		0
		    Unsigned	   1
		    Signed	   2


     which have the following meanings:

     String
	  This property contains a counted string of bytes.
	  The data is stored in the PROPINFO.DATA block
	  beginning at relative byte VALUE.POSITION (begin-
	  ning with zero), extending for VALUE.LENGTH (at
	  least zero) bytes.

     Unsigned
	  This property contains a unsigned, 32-bit number
	  stored as a CARD32 in VALUE.POSITION (VALUE.LENGTH
	  is zero).

     Signed
	  This property contains a signed, 32-bit number
	  stored as an INT32 in VALUE.POSITION (VALUE.LENGTH
	  is zero).

     This structure is zero-padded to 32-bit alignment.



			     11





X Font Service Protocol 		    X11, Release 6.4


RANGE:	  [ min-char, max-char:    CHAR2B ]

     This structure specifies a range of character codes.  A
     single character is represented by MIN-CHAR equals MAX-
     CHAR.  If the linear interpretation of MAX-CHAR is less
     than that of MIN-CHAR, or if MIN-CHAR is less than the
     font's XFONTINFO.CHAR-RANGE.MIN-CHAR, or if MAX-CHAR is
     greater than the font's XFONTINFO.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 to
     be used in resolving partially-specified scaled font
     names.  The X-RESOLUTION and Y-RESOLUTION are measured
     in pixels-per-inch and must be greater than zero.	The
     DECIPOINT-SIZE is the preferred font size, measured in
     tenths of a point, and must be greater than zero.

STRING8:       LISTofCARD8

     This is a counted list of 1-byte character codes, typi-
     cally encoded in ISO 8859-1.  A character code ``c'' is
     equivalent to a CHAR2B structure whose BYTE1 is zero
     and whose BYTE2 is ``c''.

TIMESTAMP:     CARD32

     This is the number of milliseconds that have passed
     since a server- dependent origin.	It is provided in
     errors 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 horizontal
     escapement (also known as the set- or logical width) of
     an individual character.  The first five values repre-
     sent directed distances in a coordinate system whose
     origin is aligned with the lower-left edge of the left-
     most pixel of the glyph baseline (i.e. the baseline
     falls between two pixels as shown in Figure 3-1 of the
     ``Bitmap Distribution Format 2.1'' Consortium standard
     [2]).

     The LBEARING field specifies the directed distance mea-
     sured to the right from the origin to the left edge of
     the left-most inked pixel in the glyph.

     The RBEARING field specifies the directed distance



			     12





X Font Service Protocol 		    X11, Release 6.4


     (measured to the right) from the origin to the right
     edge of the right-most inked pixel in the glyph.

     The WIDTH field specifies the directed distance (mea-
     sured to the right) from the origin to the position
     where the next character should appear (called the
     ``escapement point'').  This distance includes any
     whitespace used for intercharacter padding and is also
     referred to as the ``logical width'' or ``horizontal
     escapement.''

     The ASCENT field specifies the directed distance (mea-
     sured up) from the baseline to the top edge of the top-
     most inked pixel in the glyph.

     The DESCENT field specifies the directed distance (mea-
     sured down) from the baseline to the bottom edge of the
     bottom-most inked pixel.

     The ATTRIBUTES field specifies glyph-specific informa-
     tion that is passed through the application.  If this
     value is not being used, it should be zero.

     The ink bounding box of a glyph is defined to be the
     smallest rectangle that encloses all of the inked pix-
     els.  This box has a width of RBEARING - LBEARING pix-
     els 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 font
     as a whole.

     The FLAGS field is a bit mask containing zero or more
     of the following boolean values (unspecified bits must
     be zero):

		    AllCharactersExist	(1 << 0)
		    InkInside		(1 << 1)
		    HorizontalOverlap	     (1 << 2)


     which have the following meanings:





			     13





X Font Service Protocol 		    X11, Release 6.4


     AllCharactersExist
	  If this bit is set, all of the characters in the
	  range given by CHAR-RANGE have glyphs encoded in
	  the font.  If this bit is clear, some of the char-
	  acters may not have encoded glyphs.

     InkInside
	  If this bit is set, the inked pixels of each glyph
	  fall within the rectangle described by the font's
	  ascent, descent, origin, and the glyph's escape-
	  ment point.  If this bit is clear, there may be
	  glyphs whose ink extends outside this rectangle.

     HorizontalOverlap
	  If this bit is set, the two ink bounding boxes
	  (smallest rectangle enclosing the inked pixels) of
	  some pairs of glyphs in the font may overlap when
	  displayed side-by-side (i.e. the second character
	  is imaged at the escapement point of the first) on
	  a common baseline.  If this bit is clear, there
	  are no pairs of glyphs whose ink bounding boxes
	  overlap.

     The DRAWING-DIRECTION field contains a hint indicating
     whether most of the character metrics have a positive
     (or ``LeftToRight'') logical width or a negative
     (``RightToLeft'') logical width.  It contains the fol-
     lowing alternate values:


		    LeftToRight 	0
		    RightToLeft 	1

     The CHAR-RANGE.MIN-CHAR and CHAR-RANGE.MAX-CHAR fields
     specify the first and last character codes that have
     glyphs encoded in this font.  All fonts must have at
     least one encoded glyph (in which case the MIN-CHAR and
     MAX-CHAR are equal), but are not required to have
     glyphs encoded at all positions between the first and
     last characters.

     The DEFAULT-CHAR field specifies the character code of
     the glyph that the client should substitute for unen-
     coded characters.	Requests for extents or bitmaps for
     an unencoded character generate zero-filled metrics and
     a zero-length glyph bitmap, respectively.

     The MIN-BOUNDS and MAX-BOUNDS fields contain the mini-
     mum and maximum values of each of the extents field of
     all encoded characters in the font (i.e. non-existent
     characters are ignored).

     The FONT-ASCENT and FONT-DESCENT fields specify the
     font designer's logical height of the font, above and



			     14





X Font Service Protocol 		    X11, Release 6.4


     below the baseline, respectively.	The sum of the two
     values is often used as the vertical line spacing of
     the font.	Individual glyphs are permitted to have
     ascents and descents that are greater than these val-
     ues.

     The PROPERTIES field contains the property data associ-
     ated with this font.

     This structure is padded to 32-bit alignment.

4.2.  Requests

This section describes the requests that may be sent by the
client and the replies or errors that are generated in
response.  Versions of the protocol with the same major ver-
sion are required to be upward-compatible.

Every request on a given connection is implicitly assigned a
sequence number, starting with 1, that is used in replies,
error, and events.  Servers are required to generate replies
and errors in the order in which the corresponding requests
are received.  Servers are permitted to add or remove fonts
to the list visible to the client between any two requests,
but requests must be processed atomically.  Each request
packet is at least 4 bytes long and contains the following
fields:

	       major-opcode:		CARD8
	       minor-opcode:		CARD8
	       length:			CARD16

The MAJOR-OPCODE specifies which core request or extension
package this packet represents.  If the MAJOR-OPCODE corre-
sponds to a core request, the MINOR-OPCODE contains 8 bits
of request-specific data.  Otherwise, the MINOR-OPCODE spec-
ifies which extension request this packet represents.  The
LENGTH field specifies the number of 4-byte units contained
within the packet and must be at least one.  If this field
contains a value greater than one it is followed by (LENGTH
- 1) * 4 bytes of request-specific data.  Unless otherwise
specified, unused bytes are not required to be zero.

If a request packet contains too little or too much data,
the server returns a Length error.  If the server runs out
of internal resources (such as memory) while processing a
request, it returns an Alloc error.  If a server is defi-
cient (and therefore non-compliant) and is unable to process
a request, it may return an Implementation error.  If a
client uses an extension request without previously having
issued a QueryExtension request for that extension, the
server responds with a Request error.  If the server encoun-
ters a request with an unknown MAJOR-OPCODE or MINOR-OPCODE,
it responds with a Request error.  At most one error is



			     15





X Font Service Protocol 		    X11, Release 6.4


generated per request.	If more than one error condition is
encountered in processing a requests, the choice of which
error is returned is server-dependent.

Core requests have MAJOR-OPCODE values between 0 and 127,
inclusive.  Extension requests have MAJOR-OPCODE values
between 128 and 255, inclusive, that are assigned by by the
server.  All MINOR-OPCODE values in extension requests are
between 0 and 255, inclusive.

Each reply is at least 8 bytes long and contains the follow-
ing fields:


	       type:			CARD8 value of 0
	       data-or-unused:		CARD8
	       sequence-number: 	CARD16
	       length:		   CARD32

The TYPE field has a value of zero.  The DATA-OR-UNUSED
field may be used to encode one byte of reply-specific data
(see Section 5.2 on request encoding).	The least-signifi-
cant 16 bits of the sequence number of the request that gen-
erated the reply are stored in the SEQUENCE-NUMBER field.
The LENGTH field specifies the number of 4-byte units in
this reply packet, including the fields described above, and
must be at least two.  If LENGTH is greater than two, the
fields described above are followed by (LENGTH - 2) * 4
bytes of additional data.

Requests that have replies are described using the following
syntax:


	       RequestName
		   arg1:  type1
		   arg2:  type2
		   ...
		   argN:  typeN
		    =>
		  result1:  type1
		  result2:  type2
	       ...
		   resultM:  typeM

	       Errors:	kind1, kind2 ..., kindK

	       Description

If a request does not generate a reply, the``=>'' and result
lines are omitted.  If a request may generate multiple
replies, the ``=>'' is replaced by a ``=>+''.  In the autho-
rization data exchanges in the initial connection setup and
the CreateAC request, ``->'' indicates data sent by the



			     16





X Font Service Protocol 		    X11, Release 6.4


client in response to data sent by the server.

The protocol begins with the establishment of a connection
over a mutually-understood virtual stream:


	      open connection
	       byte-order:			  BYTE
	       client-major-protocol-version:	       CARD16
	       client-minor-protocol-version:	       CARD16
	       authorization-protocols: 	  LISTofAUTH

The initial byte of the connection specifies the BYTE-ORDER
in which subsequent 16-bit and 32-bit numeric values are to
be transmitted.  The octal value 102 (ASCII uppercase `B')
indicates that the most-significant byte is to be transmit-
ted first; the octal value 154 (ASCII lowercase `l') indi-
cates that the least-significant byte is to be transmitted
first.	If any other value is encountered the server closes
the connection without any response.

     The CLIENT-MAJOR-PROTOCOL-VERSION and CLIENT-MINOR-PRO-
     TOCOL-VERSION specify which version of the font service
     protocol the client would like to use.  If the client
     can support multiple versions, the highest version
     should be given.  This version of the protocol has a
     major version of 2 and a minor version of 0.

     The AUTHORIZATION-PROTOCOLS contains a list of protocol
     names and optional initial data for which the client
     can provide information.  The server may use this to
     determine which protocol to use or as part of the ini-
     tial exchange of authorization data.

	       =>
	       status:			     { Success, Continue,
					       Busy, Denied }
	       server-major-protocol-version:	       CARD16
	       server-minor-protocol-version:	       CARD16
	       alternate-servers-hint:		  LISTofALTERNATESERVER
	       authorization-index:		  CARD8
	       authorization-data:	     LISTofBYTE

     The SERVER-MAJOR-PROTOCOL-VERSION and SERVER-MINOR-PRO-
     TOCOL-VERSION specify the version of the font service
     protocol that the server expects from the client.	If
     the server supports the version specified by the
     client, this version number should be returned.  If the
     client has requested a higher version than is supported
     by the server, the server's highest version should be
     returned.	Otherwise, if the client has requested a
     lower version than is supported by the server, the
     server's lowest version should be returned.  It is the
     client's responsibility to decide whether or not it can



			     17





X Font Service Protocol 		    X11, Release 6.4


     match this version of the protocol.

     The ALTERNATE-SERVERS-HINT is a list of other font
     servers that may have related sets of fonts (determined
     by means outside this protocol, typically by the system
     administrator).  Clients may choose to contact these
     font servers if the connection is rejected or lost.

     The STATUS field indicates whether the server accepted,
     rejected, or would like more information about the con-
     nection.  It has one of the following alternate values:


			 Success	0
			 Continue	1
			 Busy		2
			 Denied 	3

     If STATUS is Denied, the server has rejected the
     client's authorization information.  If STATUS is Busy,
     the server has simply decided that it cannot provide
     fonts to this client at this time (it may be able to at
     a later time).  In both cases, AUTHORIZATION-INDEX is
     set to zero, no authorization-data is returned, and the
     server closes the connection after sending the data
     described so far.

     Otherwise the AUTHORIZATION-INDEX is set to the index
     (beginning with 1) into the AUTHORIZATION-PROTOCOLS
     list of the protocol that the server will use for this
     connection.  If the server does not want to use any of
     the given protocols, this value is set to zero.  The
     AUTHORIZATION-DATA field is used to send back autho-
     rization protocol-dependent data to the client (such as
     a challenge, authentication of the server, etc.).

If STATUS is Success, the following section of protocol is
omitted.  Otherwise, if STATUS is Continue, the server
expects more authorization data from the client (i.e. the
connection setup is not finished, so no requests or events
may be sent):

	  ->
	  more-authorization-data:	STRING8
	  =>
	  status:		   { Success, Continue,
				     Busy, Denied }
	  more-authorization-data:	LISTofBYTE

The values in STATUS have the same meanings as described
above.	This section of protocol is repeated until the
server either accepts (sets STATUS to Success) or rejects
(sets STATUS to Denied or Busy) the connection.




			     18





X Font Service Protocol 		    X11, Release 6.4


Once the connection has been accepted and STATUS is Success,
an implicit AccessContext is created for the authorization
data and the protocol continues with the following data sent
from the server:

	  =>
	  remaining-length:		CARD32
	  maximum-request-length:  CARD16
	  release-number:		CARD32
	  vendor:		   STRING8

The REMAINING-LENGTH specifies the length in 4-byte units of
the remaining data to be transmitted to the client.  The
MAXIMUM-REQUEST-LENGTH specifies the largest request size in
4-byte units that is accepted by the server and must have a
value of at least 4096.  Requests with a length field larger
than this value are ignored and a Length error is returned.
The VENDOR string specifies the name of the manufacturer of
the font server.  The RELEASE-NUMBER specifies the particu-
lar release of the server in a manufacturer-dependent man-
ner.

After the connection is established and the setup informa-
tion has been exchanged, the client may issue any of
requests described below:

NoOp

     Errors:  Alloc

     This request does nothing.  It is typically used in
     response to a KeepAlive event.

ListExtensions

  =>

     names:  LISTofSTRING8

     Errors:  Alloc

     This request returns the names of the extension pack-
     ages that are supported by the server.  Extension names
     are case-sensitive and are encoded in ISO 8859-1.

QueryExtension

     name:  STRING8

  =>

     present:  BOOL
     major-version:  CARD16
     minor-version:  CARD16



			     19





X Font Service Protocol 		    X11, Release 6.4


     major-opcode:  CARD8
     first-event:  CARD8
     number-events:  CARD8
     first-error:  CARD8
     number-errors:  CARD8

     Errors: Alloc

     This request determines whether or not the extension
     package specified by NAME (encoded in ISO 8859-1) is
     supported by the server and that there is sufficient
     number of major opcode, event, and error codes avail-
     able.  If so, then PRESENT is set to True, MAJOR-VER-
     SION and MINOR-VERSION are set to the respective major
     and minor version numbers of the protocol that the
     server would prefer; MAJOR-OPCODE is set to the value
     to use in extension requests; FIRST-EVENT is set to the
     value of the first extension-specific event code or
     zero if the extension does not have any events; NUMBER-
     EVENTS is set to the number of new events that the
     event defines; FIRST-ERROR is set to the value of the
     first extension-specific error code or zero if the
     extension does not define any new errors; and NUMBER-
     ERRORS is set to the number of new errors the extension
     defines.

     Otherwise, PRESENT is set to False and the remaining
     fields are set to zero.

     The server is free to return different values to dif-
     ferent clients.  Therefore, clients must use this
     request before issuing any of the requests in the named
     extension package or using the SetEventMaskrequest this
     extension's events.  Otherwise, a Request error is
     returned.

ListCatalogues

     pattern:  STRING8 max-names:  CARD32

  =>+

     replies-following-hint:  CARD32
     names:    LISTofSTRING8

     Errors: Alloc

     This request returns a list of at most MAX-NAMES names
     of collections (called catalogues) of fonts that match
     the specified PATTERN.  In the pattern (which is
     encoded in ISO 8859-1), the `?' character (octal 77)
     matches any single character; the `*' character (octal
     52) matches any series of zero or more characters; and
     alphabetic characters match either upper- or lowercase.



			     20





X Font Service Protocol 		    X11, Release 6.4


     The returned NAMES are encoded in ISO 8859-1 and may
     contain mixed character cases.

     If PATTERN is of zero length or MAX-NAMES is equal to
     zero, one reply containing a zero-length list of names
     is returned.  This may be used to synchronize the
     client with the server.

     Servers are free to add or remove catalogues to the set
     returned by ListCatalogues between any two requests.
     This request is not cumulative; repeated uses are pro-
     cessed in isolation and do result in an iteration
     through the list.

     To reduce the amount of buffering needed by the server,
     the list of names may be split across several reply
     packets, so long as the names arrive in the same order
     that they would have appeared had they been in a single
     packet.  The REPLIES-FOLLOWING-HINT field in all but
     the last reply contains a positive value that specifies
     the number of replies that are likely, but not
     required, to follow.  In the last reply, which may con-
     tain zero or more names, this field is set to zero.

SetCatalogues

     names:  LISTofSTRING8

     Errors: Alloc, Name

     This request sets the list of catalogues whose fonts
     should be visible to the client.  The union of the
     fonts provided by each of the named catalogues forms
     the set of fonts whose names match patterns in List-
     Fonts, ListFontsWithXInfo, and OpenBitmapFont requests.
     The catalogue names are case-insensitive and are
     encoded in ISO 8859-1.  A zero-length list resets the
     client's catalogue list to the server-dependent
     default.

     If any of the catalogue names are invalid, a Name error
     is returned and the request is ignored.

GetCatalogues

   =>

     names:  LISTofSTRING8

     Errors: Alloc

     This request returns the current list of catalogue
     names (encoded in ISO 8859-1) associated with the
     client.  These catalogues determine the set of fonts



			     21





X Font Service Protocol 		    X11, Release 6.4


     that are visible to ListFonts, ListFontsWithXInfo, and
     OpenBitmapFont.  A zero-length list indicates the
     server's default set of fonts.  Catalogue names are
     case-insensitive and may be returned in mixed case.

SetEventMask

     extension-opcode:	CARD8
     event-mask:  EVENTMASK

     Errors: EventMask, Request

     This request specifies the set of maskable events that
     the extension indicated by EXTENSION-OPCODE (or zero
     for the core) should generate for the client.  Event
     masks are limited in scope to the extension (or core)
     for which they are defined, so expressing interest in
     events from one or more extensions requires multiple
     uses of this request.

     The default event mask if SetEventMask has not been
     called is zero, indicating no interest in any maskable
     events.  Some events are not maskable and cannot be
     blocked.

     If EXTENSION-OPCODE is not a valid extension opcode
     previously returned by QueryExtension or zero, a
     Request error is returned.  If EVENT-MASK contains any
     bits that do not correspond to valid events for the
     specified extension (or core), an EventMask error is
     returned and the request is ignored.

GetEventMask

     extension-opcode:	CARD8

  =>

     event-mask:  EVENTMASK

     Errors: Request

     This request returns the set of maskable core events
     the extension indicated by EXTENSION-OPCODE (or the
     core if zero) should generate for the client.  Non-
     maskable events are always sent to the client.

     If EXTENSION-OPCODE is not a valid extension opcode
     previously returned by QueryExtension or zero, a
     Request error is returned.

CreateAC





			     22





X Font Service Protocol 		    X11, Release 6.4


     ac:  ACCESSCONTEXT
     authorization-protocols:  LISTofAUTH

  =>

     status:   { Success, Continue, Denied }
     authorization-index:	   CARD8
     authorization-data:      LISTofBYTE

     Errors: IDChoice

     This request creates a new AccessContext object within
     the server containing the specified authorization data.
     When this AccessContext is selected by the client using
     the SetAuthorization request, the data may be used by
     the server to determine whether or not the client
     should be granted access to particular font informa-
     tion.

     If STATUS is Denied, the server rejects the client's
     authorization information and does not associate AC
     with any valid AccessContext.  In this case, AUTHORIZA-
     TION-INDEX is set to zero, and zero bytes of AUTHORIZA-
     TION-DATA is returned.

     Otherwise, AUTHORIZATION-INDEX is set to the index
     (beginning with 1) into the AUTHORIZATION-PROTOCOLS
     list of the protocol that the server will use for this
     connection.  If the server does not want to use any of
     the given protocols, this value is set to zero.  The
     AUTHORIZATION-DATA field is used to send back autho-
     rization protocol-dependent data to the client (such as
     a challenge, authentication of the server, etc.).

     If STATUS is Continue, the client is expected to con-
     tinue the request by sending the following protocol and
     receiving the indicated response from the server.	This
     continues until STATUS is set to either Success or
     Denied.

		    ->
		    more-authorization-data:	  STRING8
		    =>
		    status:		     { Success, Continue, Denied }
		    more-authorization-data:	  LISTofBYTE

     Once the connection has been accepted and STATUS is
     Success, the request is complete.

     If AC is not in the range [1..2^29-1] or is already
     associated with an access context, an IDChoice error is
     returned.





			     23





X Font Service Protocol 		    X11, Release 6.4


FreeAC

     ac:  ACCESSCONTEXT

     Errors: AccessContext, Alloc

     This request indicates that the specified AC should no
     longer be associated with a valid access context.	If
     AC is also the current AccessContext (as set by the
     SetAuthorization request), an implicit SetAuthorization
     of None is done to restore the AccessContext estab-
     lished for the initial connection setup.  Operations on
     fonts that were opened under AC are not affected.	The
     client may reuse the value of AC in a subsequent Cre-
     ateAC request.

     If AC isn't associated with any valid authorization
     previously created by CreateAC, AccessContext error is
     returned.

SetAuthorization

     ac:  ACCESSCONTEXT

     Errors: AccessContext

     This request sets the AccessContext to be used for sub-
     sequent requests (except for QueryXInfo, QueryXEx-
     tents8, QueryXExtents16, QueryXBitmaps8,
     QueryXBitmaps16, and CloseFont which are done under the
     AccessContext of the corresponding OpenBitmapFont).  An
     AC of None restores the AccessContext established for
     the initial connection setup.

     If AC is neither None nor a value associated with a
     valid AccessContext previously created by CreateAC, an
     AccessContext error is returned.

SetResolution

     resolutions:  LISTofRESOLUTION

     Errors: Resolution, Alloc

     This request provides a hint as to the resolution and
     preferred point size of the drawing surfaces for which
     the client will be requesting fonts.  The server may
     use this information to set the RESOLUTION_X and RESO-
     LUTION_Y fields of scalable XLFD font names, to order
     sets of names based on their resolutions, and to choose
     the server-dependent instance that is used when a par-
     tially-specified scalable fontname is opened.

     If a zero-length list of RESOLUTIONS is given, the



			     24





X Font Service Protocol 		    X11, Release 6.4


     server-dependent default value is restored.  Otherwise,
     if elements of all of the specified RESOLUTIONS are
     non-zero, the default resolutions for this client are
     changed.

     If a RESOLUTION entry contains a zero, a Resolution
     error is returned and the default resolutions are not
     changed.

GetResolution

  =>

     resolutions:  LISTofRESOLUTION

     Errors: Alloc

     This request returns the current list of default reso-
     lutions.  If a client has not performed a SetResolu-
     tion, a server-dependent default value is returned.

ListFonts

     pattern:  STRING8 max-names:  CARD32

  =>+

     replies-following-hint:  CARD32
     names:  LISTofSTRING8

     Errors: Alloc

     This request returns a list of at most MAX-NAMES font
     names that match the specified PATTERN, according to
     matching rules of the X Logical Font Description Con-
     ventions [3].  In the pattern (which is encoded in ISO
     8859-1) the `?' character (octal 77) matches any single
     character; the `*' character (octal 52) matches any
     series of zero or more characters; and alphabetic char-
     acters match either upper- or lowercase.  The returned
     NAMES are encoded in ISO 8859-1 and may contain mixed
     character cases.  Font names are not required to be in
     XLFD format.

     If PATTERN is of zero length or MAX-NAMES is equal to
     zero, one reply containing a zero-length list of names
     is returned.  This may be used to synchronize the
     client with the server.

     Servers are free to add or remove fonts to the set
     returned by ListFonts between any two requests.  This
     request is not cumulative; repeated uses are processed
     in isolation and do result in an iteration through the
     list.



			     25





X Font Service Protocol 		    X11, Release 6.4


     To reduce the amount of buffering needed by the server,
     the list of names may be split across several reply
     packets, so long as the names arrive in the same order
     that they would have appeared had they been in a single
     packet.  The REPLIES-FOLLOWING-HINT field in all but
     the last reply contains a positive value that specifies
     the number of replies that are likely, but not
     required, to follow.  In the last reply, which may con-
     tain zero or more names, this field is set to zero.

ListFontsWithXInfo

     pattern:  STRING8
     max-names:  CARD32

  =>+

     replies-following-hint:  CARD32
     info:  XFONTINFO
     name:  STRING8

     Errors: Alloc

     This request is similar to ListFonts except that a sep-
     arate reply containing the name, header, and property
     data is generated for each matching font name.  Follow-
     ing these replies, if any, a final reply containing a
     zero-length NAME and no INFO is sent.

     The REPLIES-FOLLOWING-HINT field in all but the last
     reply contains a positive value that specifies the num-
     ber of replies that are likely, but not required, to
     follow.  In the last reply, this field is set to zero.

     If PATTERN is of zero length or if MAX-NAMES is equal
     to zero, only the final reply containing a zero-length
     NAME and no INFO is returned.  This may be used to syn-
     chronize the client with the server.

OpenBitmapFont

     fontid:  FONTID
     pattern:  STRING8
     format-mask:  BITMAPFORMATMASK
     format-hint:  BITMAPFORMAT

  =>

     otherid:  FONTID or None
     otherid-valid:  BOOL
     cachable:	BOOL

     Errors: IDChoice, Name, Format, AccessContext, Alloc




			     26





X Font Service Protocol 		    X11, Release 6.4


     This request looks for a server-dependent choice of the
     font names that match the specified PATTERN according
     to the rules described for ListFonts.  If no matches
     are found, a Name error is returned.  Otherwise, the
     server attempts to open the font associated with the
     chosen name.

     Permission to access the font is determined by the
     server according the licensing policy used for this
     font.  The server may use the client's current Access-
     Context (as set by the most recent SetAuthorization
     request or the original connection setup) to determine
     any client-specific sets of permissions.  After the
     font has been opened, the client is allowed to specify
     a new AccessContext with SetAuthorization or release
     the AccessContext using FreeAC.  QueryXInfo, QueryXEx-
     tents8, QueryXExtents16, QueryXBitmaps8,
     QueryXBitmaps16, CloseFont requests on this FONTID are
     performed according to permissions granted at the time
     of the OpenBitmapFont request.

     If the server is willing and able to detect that the
     client has already opened the font successfully (possi-
     bly under a different name), the OTHERID field may be
     set to one of the identifiers previously used to open
     the font.	The OTHERID-VALID field indicates whether or
     not OTHERID is still associated with an open font: if
     it is True, the client may use OTHERID as an alterna-
     tive to FONTID.  Otherwise, if OTHERID-VALID is False,
     OTHERID is no longer open but has not been reused by a
     subsequent OpenBitmapFont request.

     If OTHERID is set to None, then OTHERID-VALID should be
     set to False.

     The FORMAT-MASK indicates which fields in FORMAT-HINT
     the client is likely to use in subsequent GetXBitmaps8
     and GetXBitmaps16 requests.  Servers may wish to use
     this information to precompute certain values.

     If CACHABLE is set to True, the client may cache the
     font (so that redundant opens of the same font may be
     avoided) and use it with all AccessContexts during the
     life of the client without violating the font's licens-
     ing policy.  This flag is typically set whenever a font
     is unlicensed or is licensed on a per-display basis.
     If CACHABLE is False, the client should reopen the font
     for each AccessContext.

     The server is permitted to add to or remove from the
     set of fonts returned by ListFonts between any two
     requests, though mechanisms outside the protocol.
     Therefore, it is possible for this request (which is
     atomic) to return a different font than would result



			     27





X Font Service Protocol 		    X11, Release 6.4


     from separate a ListFonts followed by an OpenBitmapFont
     with a non-wildcarded font name.

     If FONTID is not in the range [1..2^29-1] or if it is
     already associated with an open font, an IDChoice error
     is returned.  If no font is available that matches the
     specified PATTERN, a Name error is returned.  If the
     font is present but the client is not permitted access,
     an AccessContext error is returned.  If FORMAT-MASK has
     any unspecified bits set or if any of the fields in
     FORMAT-HINT indicated by FORMAT-MASK are invalid, a
     Format error is returned.

QueryXInfo

     fontid:  FONTID

  =>

     info:  XFONTINFO

     Errors: Font, Alloc

     This request returns the font header and property
     information for the open font associated with FONTID.

     If FONTID is not associated with any open fonts, a Font
     error is returned.

QueryXExtents8

     fontid:  FONTID
     range:  BOOL
     chars:  STRING8

  =>

     extents:  LISTofXCHARINFO

     Errors: Font, Range, Alloc

     This request is equivalent to QueryXExtents16 except
     that it uses 1-byte character codes.

QueryXExtents16

     fontid:  FONTID
     range:  BOOL
     chars:  LISTofCHAR2B

  =>

     extents:  LISTofXCHARINFO




			     28





X Font Service Protocol 		    X11, Release 6.4


     Errors: Font, Range, Alloc

     This request returns a list of glyph extents from the
     open font associated with FONTID for the series of
     characters specified by RANGE and CHARS.

     If RANGE is True, each succeeding pair of elements in
     CHARS is treated as a range of characters for which
     extents should be returned.  If CHARS contains an odd
     number of elements, the font's XFONTINFO.CHAR-
     RANGE.MAX-CHAR is implicitly appended to the list.  If
     CHARS contains no elements, the list is implicitly
     replaced with the font's XFONTINFO.CHAR-RANGE.  If any
     of the resulting character ranges are invalid, a Range
     error is returned.  Otherwise, the character ranges are
     concatenated in the order given by CHARS to produce a
     set of character codes for which extents are returned.

     If RANGE is False, then CHARS specifies the set of
     character codes for which extents are returned.  If
     CHARS is of zero length, then a zero-length list of
     extents is returned.

     The extents for each character code in the resulting
     set (which may contain duplicates) are returned in the
     order in which the character codes appear in the set.
     At least one metric for each character shall be non-
     zero unless the character is not encoded in the font,
     in which case all-zero metrics are returned.  A blank,
     zero-width character can be encoded with non-zero but
     equal left and right bearings.

     If FONTID is not associated with any open fonts, a Font
     error is returned.  If RANGE is True and CHARS contains
     any invalid ranges, a Range error is returned.

QueryXBitmaps8

     fontid:  FONTID
     range:  BOOL
     chars:  STRING8
     format:  BITMAPFORMAT

  =>+

     replies-following-hint:  CARD32
     offsets:  LISTofOFFSET32
     bitmaps:  LISTofBYTE

     Errors: Font, Range, Format, Alloc

     This request is equivalent to QueryXBitmaps16 except
     that it uses 1-byte character codes.




			     29





X Font Service Protocol 		    X11, Release 6.4


QueryXBitmaps16

     fontid:  FONTID
     range:  BOOL
     chars:  LISTofCHAR2B
     format:  BITMAPFORMAT

  =>+

     replies-following-hint:  CARD32
     offsets:  LISTofOFFSET32
     bitmaps:  LISTofBYTE

     Errors: Font, Range, Format, Alloc

     This request returns a list of glyph bitmaps from the
     open font associated with FONTID for the series of
     characters specified by RANGE and CHARS.

     If RANGE is True, each succeeding pair of elements in
     CHARS is treated as a range of characters for which
     bitmaps should be returned.  If CHARS contains an odd
     number of elements, the font's XFONTINFO.CHAR-
     RANGE.MAX-CHAR is implicitly appended to the list.  If
     CHARS contains no elements, the list is implicitly
     replaced with the font's XFONTINFO.CHAR-RANGE.  If any
     of the resulting character ranges are invalid, a Range
     error is returned.  Otherwise, the character ranges are
     concatenated in the order given by CHARS to produce a
     set of character codes for which bitmaps are returned.

     If RANGE is False, then CHARS specifies the set of
     character codes for which bitmaps are returned.  If
     CHARS is of zero length, then a single reply containing
     a zero-length list of offsets and bitmaps is returned.

     If any of the resulting character ranges are invalid, a
     Range error is returned.  Otherwise, the resulting
     character ranges are concatenated in the order given by
     CHARS to produce a set of character codes for which
     bitmaps are returned.

     The server is free to return the glyph bitmaps in mul-
     tiple replies to reduce the amount of buffering that is
     necessary.  In this situation, the set of characters
     obtained above is partitioned into an implementation-
     dependent number of ordered, non-overlapping subsets
     containing runs of one or more consecutive characters.
     The global ordering of characters must be maintained
     such that concatenating the subsets in order that they
     were produced yields the original set.  A reply is gen-
     erated for each subset, in the order that it was pro-
     duced.




			     30





X Font Service Protocol 		    X11, Release 6.4


     For each character in a subset, an image of that char-
     acter's glyph is described by a rectangle of bits cor-
     responding to the pixels specified by FORMAT.IMAGE-
     RECT.  Within the image, set and clear bits represent
     inked and non-inked pixels, respectively.

     Each scanline of a glyph image, from top to bottom, is
     zero-padded on the right to a multiple of the number of
     bits specified by FORMAT.SCANLINE-PAD.  The scanline is
     then divided from left to right into a sequence of FOR-
     MAT.SCANLINE-UNIT bits.  The bits of each unit are then
     arranged such that the left-most pixel is stored in the
     most- or least-significant bit, according to FOR-
     MAT.BIT-ORDER-MSB.  The bytes of each unit are then
     arranged such that the most- or least-significant byte,
     according to FORMAT.BYTE-ORDER-MSB, is transmitted
     first.  Finally, the units are arranged such that the
     left-most is transmitted first and the right-most is
     transmitted last.

     The individual images within a subset are then concate-
     nated in a server-dependent order to form the BITMAPS
     data of the reply.  If a glyph image is duplicated
     within a reply, the server is free to return fewer (but
     at least one) copies of the image.  If a character is
     not encoded within the font, a zero-length bitmap is
     substituted for this character.  Each glyph image must
     begin at a bit position that is a multiple of the FOR-
     MAT.SCANLINE-UNIT.

     The OFFSETS array in a reply contains one entry for
     each character in the subset being returned, in the
     order that the characters appear in the subset.  Each
     entry specifies the starting location in bytes and size
     in bytes of the corresponding glyph image in the
     BITMAPS data of that reply (i.e. an offset may not
     refer to data in another reply).

     The REPLIES-FOLLOWING-HINT field in all but the last
     reply contains a positive value that specifies the num-
     ber of replies that are likely, but not required, to
     follow.  In the last reply, which may contain data for
     zero or more characters, this field is set to zero.

     If FONTID is not associated with any open fonts, a Font
     error is returned.  If RANGE is True and CHARS contains
     any invalid ranges, a Range error is returned.  If FOR-
     MAT is invalid, a Format error is returned.

CloseFont

     fontid:  FONTID





			     31





X Font Service Protocol 		    X11, Release 6.4


     Errors: Font, Alloc

     This request indicates that the specified FONTID should
     no longer be associated with an open font.  The server
     is free to release any client-specific storage or
     licenses allocated for the font.  The client may reuse
     the value of FONTID in a subsequent OpenBitmapFont
     request.

     If FONTID is not associated with any open fonts, a Font
     error is returned.

close connection

     When a connection is closed, a CloseFont is done on all
     fonts that are open on the connection.  In addition,
     the server is free to release any storage or licenses
     allocated on behalf of the client that made the connec-
     tion.

4.3.  Errors

All errors are at least 16 bytes long and contain the fol-
lowing fields:

     type:  CARD8  value of 1
     error-code:  CARD8
     sequence-number:  CARD16
     length:  CARD32
     timestamp:  TIMESTAMP
     major-opcode:  CARD8
     minor-opcode:  CARD8
     data-or-unused:  CARD16

The TYPE field has a value of one.  The ERROR-CODE field
specifies which error occurred.  Core errors codes are in
the range 0 through 127, extension error codes are in the
range 128 through 255.	The SEQUENCE-NUMBER field contains
the least significant 16 bits of the sequence number of the
request that caused the error.	The LENGTH field specifies
the length of the error packet in 4-byte units and must have
a value of at least 4.	The TIMESTAMP specifies the server
time when the error occurred.  The MAJOR-OPCODE and MINOR-
OPCODE (zero for core requests) fields specify the type of
request that generated the error.  The DATA-OR-UNUSED field
may be used for 16 bits of error-specific information.	If
LENGTH is greater than four, these fields are followed by
(LENGTH - 4) * 4 bytes of extra data.

The following errors are defined for the core protocol:

Request





			     32





X Font Service Protocol 		    X11, Release 6.4


     data-or-unused:  CARD16  unused

     This error is generated by any request that has an
     unknown combination of major and minor request numbers,
     or by any extension request that is issued before a
     QueryExtension of that extension.

Format

     data-or-unused:  CARD16  unused
     format:  BITMAPFORMAT    bad format value

     This error is generated by the use of an invalid
     BITMAPFORMAT in the OpenBitmapFont, QueryXBitmaps8, and
     QueryXBitmaps16 requests.	The value that caused the
     error is included as extra data.

Font

     data-or-unused:  CARD16  unused
     fontid:  FONTID	 bad font identifier

     This error is generated by an invalid FONTID in the
     QueryXInfo, QueryXExtents8, QueryXExtents16,
     QueryXBitmaps8, QueryXBitmaps16, and CloseFont
     requests.	The value that caused the error is included
     as extra data.

Range

     data-or-unused:  CARD16  unused
     range:  RANGE  bad range

     This error is generated by an invalid RANGE in the
     QueryXExtents8, QueryXExtents16, QueryXBitmaps8,
     QueryXBitmaps16 requests.	The value that caused the
     error is included as extra data.

EventMask

     data-or-unused:  CARD16  unused
     event-mask:  EVENTMASK   bad event mask

     This error is generated by an invalid EVENTMASK in the
     SetEventMask request.  The value that caused the error
     is included as extra data.

AccessContext

     data-or-unused:  CARD16  unused
     ac:  ACCESSCONTEXT  unaccepted AccessContext

     This error is generated by an invalid ACCESSCONTEXT in
     the FreeAC or SetAuthorization request or by an



			     33





X Font Service Protocol 		    X11, Release 6.4


     OpenBitmapFont request performed without sufficient
     authorization.  In the first two cases, the ACCESSCON-
     TEXT of the errant request is returned as extra data.
     In the third case, the current ACCESSCONTEXT is
     returned as extra data.

IDChoice

     data-or-unused:  CARD16  unused
     id:  ID   bad identifier

     This error is generated by an invalid or already asso-
     ciated ACCESSCONTEXT identifier in a CreateAC request
     or FONTID identifier in an OpenBitmapFont request.  The
     value that caused the error is included as extra data.

Name

     data-or-unused:  CARD16  unused

     This error is generated by a font name pattern that
     matches no fonts in an OpenBitmapFont request or no
     catalogue names in a SetCatalogues request.

Resolution

     data-or-unused:  CARD16  X value of errant resolution
     y-resolution:  CARD16	   Y value of errant resolu-
     tion
     point-size:  CARD16      point size of errant resolu-
     tion

     This error is generated in response to an invalid RESO-
     LUTION structure in a SetResolution request.  The value
     that caused the error is included in the DATA-OR-UNUSED
     field and as extra data.

Alloc

     data-or-unused:  CARD16  unused

     This error is generated by any request for which the
     server lacks sufficient resources (especially memory).

Length

     data-or-unused:  CARD16  unused
     length:  CARD32	 bad length value

     This error is generated by any request that has a
     length field greater than (MAXIMUM-REQUEST-LENGTH * 4)
     bytes.  The value that caused the error is included as
     extra data.




			     34





X Font Service Protocol 		    X11, Release 6.4


Implementation

     data-or-unused:  CARD16  unused

     This error may be generated in response to any request
     that the server is unable to process because it is
     deficient.  Use of this error is highly discouraged and
     indicates lack of conformance to the protocol.

     Additional errors may be defined by extensions.

4.4.  Events

Events may be generated in response to requests or at the
server's discretion after the initial connection setup
information has been exchanged.  Each event is at least 12
bytes long and contains the following fields:

     type:  CARD8   value of 2
     event-code:  CARD8
     sequence-number:  CARD16
     length:  CARD32
     timestamp:  TIMESTAMP

The TYPE field contains the value 2.  The EVENT-CODE field
specifies the number of the event and is in the range 0-127
for core events or the range 128-255 for extensions.  The
SEQUENCE-NUMBER field specifies the least significant 16
bits of the sequence number of the last request to have been
processed by the server.  The LENGTH field specifies the
number of 4-byte units in this event packet and must always
have a value of at least 3.  The TIMESTAMP field specifies
the server time when the event occurred.  If LENGTH is
greater 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: typeN

		 Description

If an event does not provide any extra arguments, the
arg1...argN lines are omitted from the description.

The core X Font Service protocol defines the following
events:

KeepAlive




			     35





X Font Service Protocol 		    X11, Release 6.4


     This unsolicited, nonmaskable event may be sent by the
     server to verify that the connection has not been bro-
     ken (for transports that do not provide this informa-
     tion).  Clients should acknowledge receipt of this
     request by sending any request (such as NoOp).

CatalogueListNotify

     added:  BOOL
     deleted:  BOOL

     This event is sent to clients that have included Cata-
     logueListChangeMask in their core event mask whenever
     the list of catalogues that are available has changed.
     The ADDED field is True if new catalogues have been
     added to the server, otherwise it is False.  The
     DELETED field is True if any existing catalogues have
     been removed from the server, otherwise it is False.

FontListNotify

     added:  BOOL
     deleted:  BOOL

     This event is sent to clients that have included
     FontListChangeMask in their event mask whenever the
     list of fonts that are provided by the currently
     selected catalogues has changed.  The ADDED field is
     True if new fonts have been added to any of the cata-
     logues currently used by the client, otherwise it is
     False.  The DELETED field is True if any existing fonts
     have been removed from any of catalogues used by the
     client, otherwise it is False.

     Additional events may be defined by extensions.

5.  Protocol Encoding

Numbers that are prefixed with ``#x'' are in hexadecimal
(base 16).  All other numbers are in decimal.  Requests,
replies, errors, events, and compound types are described
using the syntax:


	      Name
	       count	      contents	name
	       ...
	       count	      contents	name

where COUNT is the number of bytes in the data stream occu-
pied by this field, CONTENTS is the name of the type as
given in Section 4 or the value if this field contains a
constant, and NAME is a description of this field.




			     36





X Font Service Protocol 		    X11, Release 6.4


Objects containing counted lists use a lowercase single-let-
ter variable (whose scope is limited to the request, reply,
event, or error in which it is found) to represent the num-
ber of objects in the list.  These variables, and any
expressions in which they are used, should be treated as
unsigned integers.  Multiple copies of an object are indi-
cated by CONTENTS prefix ``LISTof''.

Unused bytes (whose value is undefined) will have a blank
CONTENTS field and a NAME field of ``unused''.	Zeroed bytes
(whose value must be zero) will have a blank CONTENTS field
and a NAME field of ``zero''.  The expression pad(e) refers
to the number of bytes needed to round a value ``e'' up to
the closed multiple of four:


	       pad(e) = (4 - (e mod 4)) mod 4


5.1.  Data Types

ACCESSCONTEXT
4    CARD32    access context with at least one of the fol-
lowing bits set:
#x1fffffff
but none of the following bits set:
#xe0000000	    zero



ALTERNATESERVER
1   BOOL      subset
1   n	      length of name
n   STRING8   name
p	      unused, p=pad(n+2)


AUTH
2   n	      length of name
2   d	      length of data
n   STRING8   name
p	      unused, p=pad(n)
d   STRING8   data
q	      unused, q=pad(d)



BITMAPFORMAT
4    CARD32    value, union of the following bits:

   #x00000001	     ByteOrderMSB
   #x00000002	     BitOrderMSB
   #x00000000	     ImageRectMin




			     37





X Font Service Protocol 		    X11, Release 6.4


   #x00000004	     ImageRectMaxWidth
   #x00000008	     ImageRectMax
   #x00000000	     ScanlinePad8
   #x00000100	     ScanlinePad16
   #x00000200	     ScanlinePad32
   #x00000300	     ScanlinePad64
   #x00000000	     ScanlineUnit8
   #x00001000	     ScanlineUnit16
   #x00002000	     ScanlineUnit32
   #x00003000	     ScanlineUnit64
except for the following bits which must be zero:
   #xffffccf0	     zero
and the following of which at most one bit may be set:
    #x0000000c	     at most one bit can be set



BITMAPFORMATMASK
4    CARD32    value, mask of the following bits:

     #x00000001        ByteOrderMask
     #x00000002        BitOrderMask
     #x00000004        ImageRectMask
     #x00000008        ScanlinePadMask
     #x00000010        ScanlineUnitMask
except for the following bits which must be zero:
     #xffffffe0        zero



BOOL
1    BOOL boolean, one of the following values:
	  0    False
	  1    True


BYTE
1    BYTE unsigned byte of data


CARD8
1    CARD8     8-bit unsigned integer


CARD16
2    CARD16    16-bit unsigned integer


CARD32
4    CARD32    32-bit unsigned integer


CHAR2B
1    CARD8     byte1



			     38





X Font Service Protocol 		    X11, Release 6.4


1    CARD8     byte2


EVENTMASK
4	  CARD32	 event mask

for core events, this is union of the following bits:
    #00000001	     CatalogueListChangeMask
    #00000002	     FontListChangeMask
but none of the following bits set:
    #fffffffc

extensions define their own sets of bits


FONTID
4    CARD32    font identifier with at least one of
			 the following bits set:

	  #x1fffffff
but none of the following bits set:
   #xe0000000		 zero



INT8
1    INT8      8-bit signed integer


INT16
2    INT16     16-bit signed integer


INT32
4    INT32     32-bit signed integer


OFFSET32
4    CARD32    position (or integer value)
4    CARD32    length


PROPINFO
4    n		    number of PROPOFFSET components
4    m		    number of bytes of property data
20*n PROPOFFSET     property offsets into data block
m    LISTofBYTE     property data block


PROPOFFSET
8    OFFSET32	    name in data block
8    OFFSET32	    value in data block
1    CARD8	    type, one of the following values:
     0	       String



			     39





X Font Service Protocol 		    X11, Release 6.4


     1	       Unsigned
     2	       Signed
3	       zero


RANGE
2    CHAR2B    minimum character code
2    CHAR2B    maximum character code


RESOLUTION
2    CARD16    x resolution in pixels per inch
2    CARD16    y resolution in pixels per inch
2    CARD16    point size in decipoints


STRNAME
1    n	  length of name
n    STRING8   name


STRING8
n    LISTofBYTE     array of 8-bit character values


TIMESTAMP
4    CARD32    milliseconds since server time origin


XCHARINFO
2    INT16     left bearing
2    INT16     right bearing
2    INT16     width
2    INT16     ascent
2    INT16     descent
2    CARD16    attributes


XFONTINFO
4    CARD32    flags, union of the following bits:

 #x00000001    AllCharactersExist
 #x00000002    InkInside
 #x00000004    HorizontalOverlap
but none of the following bits set:
 #xfffffff8    zero

4	  RANGE 	 range of characters in font
1	  CARD8 	 drawing direction
	  0	    LeftToRight
	  1	    RightToLeft
1			 unused
2	  CHAR2B	 default character
12	  XCHARINFO minimum bounds



			     40





X Font Service Protocol 		    X11, Release 6.4


12	  XCHARINFO maximum bounds
2	  INT16 	 font ascent
2	  INT16 	 font descent
n	  PROPINFO	 property data

5.2.  Requests


open connection
1    BYTE		     byte order, one of the values:
     #x42		     Most Significant Byte first
     #x6c		     Least Significant Byte first
1    CARD8		     number of auth in auth-data
2    2			     client-major-protocol-version
2    0			     client-minor-protocol-version
2    a/4		     length of auth-data
a    LISTofAUTH 	     auth-data
=>
2    CARD16		     status
     0			     Success
     1			     Continue
     2			     Busy
     3			     Denied
2    2			     major version
2    0			     minor version
1    CARD8		     number of alternate-servers-hint
1    CARD8		     authorization-index
2    a/4		     length of alternate-servers-hint
2    (d+q)/4		     length of authorization-data
a    LISTofALTERNATESERVER   alternate-servers-hint
d    LISTofBYTE 	     authorization-data
q			     unused, q=pad(d)


If STATUS is Busy or Denied, the protocol stops and the con-
nection is closed.  If STATUS is Continue, the client is
expected to respond with additional data, to which the
server responds with a new status value and more data.	This
dialog continues until the status is set to Success, or
until the server sets STATUS to Busy or Denied and closes
the connection:


->
4    1+(d+q)/4		    length
d    LISTofBYTE 	    more-authorization-data
q			    unused, q=pad(d)
=>
4    2+(d+q)/4		    length
2    CARD16		    status
     0			    Success
     1			    Continue
     2			    Busy




			     41





X Font Service Protocol 		    X11, Release 6.4


     3			    Denied
2			    unused
d    LISTofBYTE 	    more-authorization-data
q			    unused, q=pad(d)


When STATUS is Success, the protocol resumes with the fol-
lowing sent by the server:


4    3+(v+w)/4		    length of rest of data
2    CARD16		    maximum-request-length
2    v			    length of vendor string
4    CARD32		    release-number
v    STRING8		    vendor-string
w			    unused, w=pad(v)


Once the connection has been established, the client may
send the following requests:

NoOp
1    0			    major-opcode
1			    unused
2    1			    length



ListExtensions
1    1			    major-opcode
1			    unused
2    1			    length
=>
1    0			    type reply
1    CARD8		    number of names
2    CARD16		    sequence-number
4    2+(n+p)/4		    length
n    LISTofSTRNAME	    names
p			    unused, p=pad(n)



QueryExtension
1    2			    major-opcode
1    n			    length of name
2    1+(n+p)/4		    length
n    STRING8		    name
p			    unused, p=pad(n)
=>
1    0			    type reply
1    BOOL		    present
2    CARD16		    sequence-number
4    5			    length




			     42





X Font Service Protocol 		    X11, Release 6.4


2    CARD16		    major-version
2    CARD16		    minor-version
1    CARD8		    major-opcode
1    CARD8		    first-event
1    CARD8		    number-events
1    CARD8		    first-error
1    CARD8		    number-errors
3			    unused



ListCatalogues
1     3 		     major-opcode
1			     unused
2     3+(n+p)/4 	     length
4     CARD32		     max-names
2     n 		     length of pattern
2			     unused
n     STRING8		     pattern
p			     unused, p=pad(n)
=>+
1     0 		     type reply
1			     unused
2     CARD16		     sequence-number
4     4+(n+p)/4 	     length
4     CARD32		     replies-following-hint
4     CARD32		     number of catalogue-names
n     LISTofSTRNAME	     catalogue-names
p			     unused, p=pad(n)



SetCatalogues
1    4			    major-opcode
1    CARD8		    number of catalogue-names
2    1+(n+p)/4		    length
n    LISTofSTRNAME	    catalogue-names
p			    unused, p=pad(n)



GetCatalogues
1    5			    major-opcode
1			    unused
2    1			    length
=>
1    0			    type reply
1    CARD8		    number of catalogue-names
2    CARD16		    sequence-number
4    2+(n+p)/4		    length
n    LISTofSTRNAME	    catalogue-names
p			    unused, p=pad(n)





			     43





X Font Service Protocol 		    X11, Release 6.4


SetEventMask
1    6			    major-opcode
1    CARD8		    extension-opcode
2    2			    length
4    EVENTMASK		    event-mask



GetEventMask
1    7			    major-opcode
1    CARD8		    extension-opcode
2    1			    length
=>
1    0			    type reply
1			    unused
2    CARD16		    sequence-number
4    3			    length
4    EVENTMASK		    event-mask



CreateAC
1    8			    major-opcode
1    CARD8		    number of authorization-protocols
2    2+a/4		    length
4    ACCESSCONTEXT	    ac
a    LISTofAUTH 	    authorization-protocols
=>
1    0			    type reply
1    CARD8		    authorization-index
2    CARD16		    sequence-number
4    3+(d+q)/4		    length
2    CARD16		    status
     0			    Success
     1			    Continue
     2			    Busy
     3			    Denied
2			    unused
d    LISTofBYTE 	    authorization-data
q			    unused, q=pad(d)


If STATUS is Continue, the client is expected to respond
with additional data, to which the server responds with a
new status value and more data.  This dialog continues until
the status is set to Success, Busy, or Denied at which point
the request is finished.


->
4    1+(d+q)/4		    length
d    LISTofBYTE 	    more-authorization-data
q			    unused, q=pad(d)




			     44





X Font Service Protocol 		    X11, Release 6.4


=>
4    2+(d+q)/4		    length
2    CARD16		    status
     0			    Success
     1			    Continue
     2			    Busy
     3			    Denied
2			    unused
d    LISTofBYTE 	    authorization-data
q			    unused, q=pad(d)



FreeAC
1    9			    major-opcode
1			    unused
2    2			    length
4    ACCESSCONTEXT	    ac



SetAuthorization
1    10 		    major-opcode
1			    unused
2    2			    length
4    ACCESSCONTEXT	    ac



SetResolution
1     11		     major-opcode
1     n 		     number of resolutions
2     1+(6*n+p)/4	     length
6*n   LISTofRESOLUTION	     resolutions
p     p=pad(6*n)



GetResolution
1     12		     major-opcode
1			     unused
2     1 		     length
=>
1     0 		     type reply
1     n 		     number of resolutions
2     CARD16		     sequence-number
4     2+(6*n+p)/4	     length
6*n   LISTofRESOLUTION	     resolutions
p			     p=pad(6*n)



ListFonts




			     45





X Font Service Protocol 		    X11, Release 6.4


1     13		     major-opcode
1			     unused
2     3+(n+p)/4 	     length
4     CARD32		     max-names
2     n 		     length of pattern
2			     unused
n     STRING8		     pattern
p			     unused, p=pad(n)
=>+
1     0 		     type reply
1			     unused
2     CARD16		     sequence-number
4     4+(n+p)/4 	     length
4     CARD32		     replies-following-hint
4     CARD32		     number of font-names
n     LISTofSTRNAME	     font-names
p			     unused, p=pad(n)



ListFontsWithXInfo
1    14 		    major-opcode
1			    unused
2    3+(n+p)/4		    length
4    CARD32		    max-names
2    n			    length of pattern
2			    unused
n    STRING8		    pattern
p			    unused, p=pad(n)
=>+(except for last in series)
1    0			    type reply
1    n			    length of name
2    CARD16		    sequence-number
4    3+(n+p+f)/4	    length
4    CARD32		    replies-hint
f    XFONTINFO		    font info
n    STRING8		    name
p			    unused, p=pad(n)

=>(last in series)
1    0			    type reply
1    0			    last-reply indicator
2    CARD16		    sequence-number
4    2			    reply length



OpenBitmapFont
1    15 		    major-opcode
1			    unused
2    4+(n+p)/4		    length
4    FONTID		    fontid
4    BITMAPFORMATMASK	    format-mask




			     46





X Font Service Protocol 		    X11, Release 6.4


4    BITMAPFORMAT	    format
n    STRNAME		    pattern
p			    unused, p=pad(n)
=>
1    0			    type reply
1    BOOL		    otherid-valid
2    CARD16		    sequence-number
4    4			    length
4    FONTID		    otherid
1    BOOL		    cachable
3			    unused



QueryXInfo
1    16 		    major-opcode
1			    unused
2    2			    length
4    FONTID		    fontid
=>
1    0			    type reply
1			    unused
2    CARD16		    sequence-number
4    2+f/4		    length
f    XFONTINFO		    font info
p			    unused, p=pad(f)



QueryXExtents8
1      17		      major-opcode
1      BOOL		      range
2      3+(n+p)/4	      length
4      FONTID		      fontid
4      n		      number chars entries
n      STRING8		      chars
p			      unused, p=pad(n)
=>
1      0		      type reply
1			      unused
2      CARD16		      sequence-number
4      3+3*n		      length
4      n		      number of extents
12*n   LISTofXCHARINFO	      extents



QueryXExtents16
1      18		      major-opcode
1      BOOL		      range
2      3+(2*n+p)/4	      length
4      FONTID		      fontid
4      n		      number chars entries




			     47





X Font Service Protocol 		    X11, Release 6.4


2*n    LISTofCHAR2B	      chars
p			      unused, p=pad(2*n)
=>
1      0		      type reply
1			      unused
2      CARD16		      sequence-number
4      3+3*n		      length
4      n		      number of extents
12*n   LISTofXCHARINFO	      extents



QueryXBitmaps8
1     19		     major-opcode
1     BOOL		     range
2     4+(n+p)/4 	     length
4     FONTID		     fontid
4     BITMAPFORMAT	     format
4     n 		     number of chars entries
n     STRING8		     chars
p			     unused, p=pad(n)
=>+
1     0 		     type reply
1			     unused
2     CARD16		     sequence-number
4     5+2*n+(m+p)/4	     length
4     CARD32		     replies-following-hint
4     n 		     number of offsets
4     m 		     number of bytes of glyph images
8*n   LISTofOFFSET32	     offsets
m     LISTofBYTE	     glyph images
p			     unused, p=pad(m)



QueryXBitmaps16
1     20		     major-opcode
1     BOOL		     range
2     4+(2*n+p)/4	     length
4     FONTID		     fontid
4     BITMAPFORMAT	     format
4     n 		     number of chars entries
2*n   LISTofCHAR2B	     chars
p			     unused, p=pad(2*n)
=>
1     0 		     type reply
1			     unused
2     CARD16		     sequence-number
4     5+2*n+(m+p)/4	     length
4     CARD32		     replies-following-hint
4     n 		     number of offsets
4     m 		     number of bytes of glyph images
8*n   LISTofOFFSET32	     offsets




			     48





X Font Service Protocol 		    X11, Release 6.4


m     LISTofBYTE	     glyph images
p			     unused, p=pad(m)



CloseFont
1    21 		    major-opcode
1			    unused
2    2			    length
4    FONTID		    fontid


5.3.  Errors


Request
1   1			   type error
1   0			   Request
2   CARD16		   sequence-number
4   4			   length
4   TIMESTAMP		   timestamp
1   CARD8		   major-opcode
1   CARD8		   minor-opcode
2			   unused



Format
1   1			   type error
1   1			   Format
2   CARD16		   sequence-number
4   5			   length
4   TIMESTAMP		   timestamp
1   CARD8		   major-opcode
1   CARD8		   minor-opcode
2			   unused
4   BITMAPFORMAT	   bad-format



Font
1   1			   type error
1   2			   Font
2   CARD16		   sequence-number
4   5			   length
4   TIMESTAMP		   timestamp
1   CARD8		   major-opcode
1   CARD8		   minor-opcode
2			   unused
4   FONTID		   bad-fontid







			     49





X Font Service Protocol 		    X11, Release 6.4


Range
1   1			   type error
1   3			   Range
2   CARD16		   sequence-number
4   5			   length
4   TIMESTAMP		   timestamp
1   CARD8		   major-opcode
1   CARD8		   minor-opcode
2			   unused
4   RANGE		   bad-range



EventMask
1   1			   type error
1   4			   EventMask
2   CARD16		   sequence-number
4   5			   length
4   TIMESTAMP		   timestamp
1   CARD8		   major-opcode
1   CARD8		   minor-opcode
2			   unused
4   EVENTMASK		   event-mask



AccessContext
1   1			   type error
1   5			   AccessContext
2   CARD16		   sequence-number
4   5			   length
4   TIMESTAMP		   timestamp
1   CARD8		   major-opcode
1   CARD8		   minor-opcode
2			   unused
4   ACCESSCONTEXT	   access context



IDChoice
1   1			   type error
1   6			   IDChoice
2   CARD16		   sequence-number
4   5			   length
4   TIMESTAMP		   timestamp
1   CARD8		   major-opcode
1   CARD8		   minor-opcode
2			   unused
4   FONTID		   bad-fontid



Name




			     50





X Font Service Protocol 		    X11, Release 6.4


1   1			   type error
1   7			   Name
2   CARD16		   sequence-number
4   4			   length
4   TIMESTAMP		   timestamp
1   CARD8		   major-opcode
1   CARD8		   minor-opcode
2			   unused



Resolution
1   1			   type error
1   8			   Resolution
2   CARD16		   sequence-number
4   5			   length
4   TIMESTAMP		   timestamp
1   CARD8		   major-opcode
1   CARD8		   minor-opcode
6   RESOLUTION		   resolution



Alloc
1   1			   type error
1   9			   Alloc
2   CARD16		   sequence-number
4   4			   length
4   TIMESTAMP		   timestamp
1   CARD8		   major-opcode
1   CARD8		   minor-opcode
2			   unused



Length
1   1			   type error
1   10			   Length
2   CARD16		   sequence-number
4   5			   length
4   TIMESTAMP		   timestamp
1   CARD8		   major-opcode
1   CARD8		   minor-opcode
2			   unused
4   CARD32		   bad-length



Implementation
1   1			   type error
1   11			   Implementation
2   CARD16		   sequence-number
4   4			   length




			     51





X Font Service Protocol 		    X11, Release 6.4


4   TIMESTAMP		   timestamp
1   CARD8		   major-opcode
1   CARD8		   minor-opcode
2			   unused


5.4.  Events


KeepAlive
1   2			   type event
1   0			   event KeepAlive
2   CARD16		   sequence-number
4   3			   length
4   TIMESTAMP		   timestamp



CatalogueListNotify
1   2			   type event
1   1			   event CatalogueListNotify
2   CARD16		   sequence-number
4   4			   length
4   TIMESTAMP		   timestamp
1   BOOL		   added
1   BOOL		   deleted
2			   unused



FontListNotify
1   2			   type event
1   2			   event FontListNotify
2   CARD16		   sequence-number
4   4			   length
4   TIMESTAMP		   timestamp
1   BOOL		   added
1   BOOL		   deleted
2			   unused


6.  Acknowledgements

This document represents the culmination of several years of
debate and experiments done under the auspices of the MIT X
Consortium font working group.	Although this was a group
effort, the author remains responsible for any errors or
omissions.  The protocol presented here was primarily
designed by Jim Fulton, Keith Packard, and Bob Scheifler.
Special thanks goes to Ned Batchelder, Jim Flowers, and Axel
Deininger for their invigorating comments which never failed
to make this a better document.  Stephen Gildea edited ver-
sion 2 of this document.  Finally, David Lemke deserves
great credit for designing and coding the sample



			     52





X Font Service Protocol 		    X11, Release 6.4


implementation.

7.  References

All of the following documents are X Consortium standards
available from the X Consortium.

[1]  Scheifler, Robert W.  ``X Window System Protocol Ver-
sion 11''

[2]  Adobe Systems.  ``Bitmap Distribution Format 2.1''

[3]  X Consortium.  ``X Logical Font Description Conven-
tions, Version 1.5''











































			     53





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 connec-
tions 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 follow-
ing:

a.   No restrictions - anyone may access any fonts.  The
     server neither refuses any connections nor generates
     AccessContext errors on any fonts.  For environments
     without specially-licensed fonts, this is sufficient.

b.   Per-machine - only those clients connecting from a
     known set of machines are permitted access.  The server
     could get the address of the connection and look in a
     list of allowed machines.

c.   Per-user - only a known set of users may access the
     fonts.  The server can use the authorization data (such
     as a Kerberos ticket or a Secure RPC credential) to
     verify the identity of the user and then look in a list
     of allowed users.

d.   Simultaneous Use - only a certain number of clients may
     use a given font at any one time.	Additional clients
     would receive AccessContext errors if they attempt to
     open the font.  This is only effective if the initial
     clients keep the font open for the entire time that it
     is being used (even if all of the data has been trans-
     mitted and is being cached).

e.   Postage Meter - a particular font may only be accessed
     a limited number of times before its license must be
     renewed.  Each time the font is opened, the server
     decrements a counter.  When the counter reaches zero,
     all further attempts to open the font return an Access-
     Context error.

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






			     54





X Font Service Protocol 		    X11, Release 6.4


			 Appendix B

		 Implementation Suggestions


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

a.   The initial connection information returned by the font
     server contains the names of other font servers that
     may be used as substitutes.  A font server may refuse
     to accept a connection, indicating that the client
     should try one of the alternatives instead.

b.   On operating systems that support processing forking,
     font servers might choose to fork so that the child can
     continue processing the existing connections and the
     parent can accept new connections.  Such implementa-
     tions are encouraged to use shared memory so that in-
     memory font databases can be shared.

c.   On operating systems that support passing stream file
     descriptors between processes, cooperating font servers
     could collect connections in a single process when
     there are few connections and spread them among several
     processes as the load increases.

d.   If a font client is unable to connect to a server (as
     opposed to having the connection terminated), it should
     retry for an implementation-dependent length of time
     (see Xlib's handling of ECONNREFUSED in XConnDis.c).

























			     55





X Font Service Protocol 		    X11, Release 6.4



























































			     56








			Table of Contents


     1. Introduction . . . . . . . . . . . . . . . . . .   1
     2. Architectural Model  . . . . . . . . . . . . . .   2
     3. Font Server Naming . . . . . . . . . . . . . . .   3
     3.1. TCP/IP Names . . . . . . . . . . . . . . . . .   4
     3.2. DECnet Names . . . . . . . . . . . . . . . . .   4
     4. Protocol . . . . . . . . . . . . . . . . . . . .   4
     4.1. Data Types . . . . . . . . . . . . . . . . . .   5
     4.2. Requests . . . . . . . . . . . . . . . . . . .  15
     4.3. Errors . . . . . . . . . . . . . . . . . . . .  32
     4.4. Events . . . . . . . . . . . . . . . . . . . .  35
     5. Protocol Encoding  . . . . . . . . . . . . . . .  36
     5.1. Data Types . . . . . . . . . . . . . . . . . .  37
     5.2. Requests . . . . . . . . . . . . . . . . . . .  41
     5.3. Errors . . . . . . . . . . . . . . . . . . . .  49
     5.4. Events . . . . . . . . . . . . . . . . . . . .  52
     6. Acknowledgements . . . . . . . . . . . . . . . .  52
     7. References . . . . . . . . . . . . . . . . . . .  53
     Appendix A - Suggested Licensing Policies . . . . .  54
     Appendix B - Implementation Suggestions . . . . . .  55



































			      i


