














                [1mThe X Font Service Protocol[0m

                        [1mVersion 2.0[0m
                   [1mX Consortium Standard[0m

                 [1mX Version 11, Release 6.4[0m






                         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.
































































[1m1.  Introduction[0m

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 ad-
dress 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 di-
rectly.  Since a common binary format for this data  doesn't
exist,  displays must be able to interpret a variety of for-
mats 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 us-
ing 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  al-
low  descriptive names (such as DEPARTMENT-FONTS or APPLICA-
TION-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 easily  implement  a
-----------
* [4mX[24m [4mWindow[24m [4mSystem[24m is a trademark of X  Consortium,
Inc.



                              [1m1[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


variety  of  strategies  for  fine-grained demand-loading of
glyphs.

[1m2.  Architectural Model[0m

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 re-
quest/reply/event model over any mutually-understood virtual
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 Ser-
vice protocol is limited to supporting the needs of the bit-
map-oriented  core X Window System protocol.  Extensions are
expected as new needs evolve.

A font server reads raw font data from a variety of  sources
(possibly including other font servers) and converts it 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.



                              [1m2[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


                     +------------+
                     |   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.

[1m3.  Font Server Naming[0m

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



                              [1m3[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


may be registered with the X Consortium.

[1m3.1.  TCP/IP Names[0m

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


[1m3.2.  DECnet Names[0m

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


[1m4.  Protocol[0m

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
     Structure  element  names are referred to in upper case
     (e.g. BYTE-ORDER-MSB) when used in descriptions to  set
     them off from the surrounding text.  When this document



                              [1m4[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     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 en-
     closed 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

[1m4.1.  Data Types[0m

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 re-
     sources 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).

     must  be created (with and switched among (with to rep-
     resent all of these ``font users'' properly.

ALTERNATESERVER:  [ name:  STRING8,
                                           subset:  BOOL ]

     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



                              [1m5[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     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 and 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 re-
     turned 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
     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:




                              [1m6[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


                    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:

          This refers to the minimal bounding rectangle sur-
          rounding  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


          This  refers  to the scanlines between the glyph's
          ascent and descent, padded on the left to the min-
          imum left-bearing (or 0, whichever is less) and on
          the right to the maximum right-bearing  (or  logi-
          cal-width,  whichever  is greater).  All glyph im-
          ages share a common horizontal origin.  This is  a
          combination  of ImageRectMax in the horizontal di-
          rection and ImageRectMin in  the  vertical  direc-
          tion.  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 (particu-
          larly  for  character cell fonts) for some clients
          to use.  The edges of the rectangle are:











                              [1m7[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


                    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 er-
          ror 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.

BOOL:  CARD8

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



                              [1m8[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


                    False               0
                    True           1


BYTE:  8-bit value

     This  is an unsigned byte of data whose encoding is de-
     termined 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 and requests):


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

     If  is  set,  client is interested in receiving events.
     If is  set,  the  client  is  interested  in  receiving
     events.

     Extensions  that  provide  additional events may define



                              [1m9[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     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  requests,  if
     any bits are set that are not defined for the extension
     (or core) for which this EVENTMASK is intended (accord-
     ing  to the EXTENSION- OPCODE given in the request), an
     error is generated.

     This value is swapped as a CARD32.

FONTID:   ID

     This is specified by the client in the request  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 ]

     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.



                             [1m10[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     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 be-
          ginning at relative byte VALUE.POSITION (beginning
          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.

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.




                             [1m11[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


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
     (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.''



                             [1m12[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     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:

     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.



                             [1m13[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     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
     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  as-
     cents and descents that are greater than these values.

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

     This structure is padded to 32-bit alignment.







                             [1m14[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


[1m4.2.  Requests[0m

This section describes the requests that may be sent by  the
client  and  the replies or errors that are generated in re-
sponse.  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  request  for  that extension, the server responds
with a error.  If the server encounters a  request  with  an
unknown MAJOR-OPCODE or MINOR-OPCODE, it responds with a er-
ror.  At most one error is generated per request.   If  more
than  one error condition is encountered in processing a re-
quests, the choice of which error is returned is  server-de-
pendent.

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





                             [1m15[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


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
                   [4marg1[24m:  type1
                   [4marg2[24m:  type2
                   ...
                   [4margN[24m:  typeN
                    =>
                  [4mresult1[24m:  type1
                  [4mresult2[24m:  type2
               ...
                   [4mresultM[24m:  typeM

               Errors:  [4mkind1[24m, [4mkind2[24m ..., [4mkindK[0m

               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
client in response to data sent by the server.

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









                             [1m16[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


              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
     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



                             [1m17[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     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 de-
     scribed 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  ex-
pects more authorization data from the client (i.e. the con-
nection 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.

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:





                             [1m18[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


          =>
          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 re-
quests described below:


     Errors:  Alloc

     This request does nothing.  It is typically used in re-
     sponse to a event.


  =>

     [4mnames[24m:  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.


     [4mname[24m:  STRING8

  =>

     [4mpresent[24m:  BOOL
     [4mmajor-version[24m:  CARD16
     [4mminor-version[24m:  CARD16
     [4mmajor-opcode[24m:  CARD8
     [4mfirst-event[24m:  CARD8
     [4mnumber-events[24m:  CARD8
     [4mfirst-error[24m:  CARD8
     [4mnumber-errors[24m:  CARD8

     Errors:




                             [1m19[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     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  ex-
     tension  does not define any new errors; and NUMBER-ER-
     RORS 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 re-
     quest before issuing any of the requests in  the  named
     extension package or using the this extension's events.
     Otherwise, a error is returned.


     [4mpattern[24m:  STRING8 [4mmax-names[24m:  CARD32

  =>+

     [4mreplies-following-hint[24m:  CARD32
     [4mnames[24m:    LISTofSTRING8

     Errors:

     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  en-
     coded  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.
     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 between any two requests.  This request  is



                             [1m20[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     not  cumulative;  repeated uses are processed in isola-
     tion 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  re-
     quired,  to  follow.  In the last reply, which may con-
     tain zero or more names, this field is set to zero.


     [4mnames[24m:  LISTofSTRING8

     Errors:

     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 and re-
     quests.  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 de-
     fault.

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


   =>

     [4mnames[24m:  LISTofSTRING8

     Errors:

     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
     that  are  visible  to and A zero-length list indicates
     the server's default set of fonts.  Catalogue names are
     case-insensitive and may be returned in mixed case.


     [4mextension-opcode[24m:  CARD8
     [4mevent-mask[24m:  EVENTMASK

     Errors:

     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)



                             [1m21[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     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 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 or zero, a  error  is  returned.
     If  EVENT-MASK contains any bits that do not correspond
     to valid events for the specified extension (or  core),
     an error is returned and the request is ignored.


     [4mextension-opcode[24m:  CARD8

  =>

     [4mevent-mask[24m:  EVENTMASK

     Errors:

     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 or zero, a error is returned.


     [4mac[24m:  ACCESSCONTEXT
     [4mauthorization-protocols[24m:  LISTofAUTH

  =>

     [4mstatus[24m:   { Success, Continue, Denied }
     [4mauthorization-index[24m:          CARD8
     [4mauthorization-data[24m:      LISTofBYTE

     Errors:

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

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



                             [1m22[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     returned.

     Otherwise, AUTHORIZATION-INDEX is set to the index (be-
     ginning  with  1) into the AUTHORIZATION-PROTOCOLS list
     of the protocol that the server will use for this  con-
     nection.  If the server does not want to use any of the
     given protocols, this value is set to zero.  The AUTHO-
     RIZATION-DATA  field is used to send back authorization
     protocol-dependent data to the client (such as a  chal-
     lenge, 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  De-
     nied.

                    ->
                    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 as-
     sociated  with  an access context, an IDChoice error is
     returned.


     [4mac[24m:  ACCESSCONTEXT

     Errors:

     This request indicates that the specified AC should  no
     longer  be  associated with a valid access context.  If
     AC is also the current (as set by the request), an  im-
     plicit  of  None is done to restore the established 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 request.

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


     [4mac[24m:  ACCESSCONTEXT

     Errors:

     This  request  sets  the  to be used for subsequent re-
     quests (except for and which are done under the of  the
     corresponding  An  AC  of None restores the established



                             [1m23[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     for the initial connection setup.

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


     [4mresolutions[24m:  LISTofRESOLUTION

     Errors:

     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
     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 er-
     ror  is  returned  and  the default resolutions are not
     changed.


  =>

     [4mresolutions[24m:  LISTofRESOLUTION

     Errors:

     This request returns the current list of default  reso-
     lutions.   If a client has not performed a a server-de-
     pendent default value is returned.


     [4mpattern[24m:  STRING8 [4mmax-names[24m:  CARD32

  =>+

     [4mreplies-following-hint[24m:  CARD32
     [4mnames[24m:  LISTofSTRING8

     Errors:

     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



                             [1m24[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     8859-1) the `?' character (octal 77) matches any single
     character; the `*' character (octal 52) matches any se-
     ries of zero or more characters; and alphabetic charac-
     ters  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 re-
     turned by between any two requests.   This  request  is
     not  cumulative;  repeated uses are processed in isola-
     tion 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  re-
     quired,  to  follow.  In the last reply, which may con-
     tain zero or more names, this field is set to zero.


     [4mpattern[24m:  STRING8
     [4mmax-names[24m:  CARD32

  =>+

     [4mreplies-following-hint[24m:  CARD32
     [4minfo[24m:  XFONTINFO
     [4mname[24m:  STRING8

     Errors:

     This request is similar to except that a separate reply
     containing  the name, header, and property data is gen-
     erated for each matching font  name.   Following  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



                             [1m25[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     synchronize the client with the server.


     [4mfontid[24m:  FONTID
     [4mpattern[24m:  STRING8
     [4mformat-mask[24m:  BITMAPFORMATMASK
     [4mformat-hint[24m:  BITMAPFORMAT

  =>

     [4motherid[24m:  FONTID or None
     [4motherid-valid[24m:  BOOL
     [4mcachable[24m:  BOOL

     Errors:

     This request looks for a server-dependent choice of the
     font  names  that match the specified PATTERN according
     to the rules described for If no matches are  found,  a
     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 (as  set
     by  the  most recent request or the original connection
     setup) to determine any client-specific sets of permis-
     sions.   After  the font has been opened, the client is
     allowed to specify a new with or release the using  re-
     quests  on  this FONTID are performed according to per-
     missions granted at the time of the 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 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 and 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 during the life of the



                             [1m26[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     client without violating the font's  licensing  policy.
     This  flag  is  typically  set whenever a font is unli-
     censed or is  licensed  on  a  per-display  basis.   If
     CACHABLE  is  False,  the client should reopen the font
     for each

     The server is permitted to add to or  remove  from  the
     set  of  fonts  returned  by  between any two requests,
     though mechanisms outside the protocol.  Therefore,  it
     is  possible  for this request (which is atomic) to re-
     turn a different font than would result from separate a
     followed by an 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 error  is  re-
     turned.  If no font is available that matches the spec-
     ified PATTERN, a error is returned.   If  the  font  is
     present  but the client is not permitted access, an er-
     ror is returned.  If FORMAT-MASK  has  any  unspecified
     bits  set  or if any of the fields in FORMAT-HINT indi-
     cated by FORMAT-MASK are invalid, a error is returned.


     [4mfontid[24m:  FONTID

  =>

     [4minfo[24m:  XFONTINFO

     Errors:

     This request returns the font header and  property  in-
     formation for the open font associated with FONTID.

     If  FONTID is not associated with any open fonts, a er-
     ror is returned.


     [4mfontid[24m:  FONTID
     [4mrange[24m:  BOOL
     [4mchars[24m:  STRING8

  =>

     [4mextents[24m:  LISTofXCHARINFO

     Errors:

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


     [4mfontid[24m:  FONTID
     [4mrange[24m:  BOOL



                             [1m27[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     [4mchars[24m:  LISTofCHAR2B

  =>

     [4mextents[24m:  LISTofXCHARINFO

     Errors:

     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 ex-
     tents  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  re-
     placed with the font's XFONTINFO.CHAR-RANGE.  If any of
     the resulting character ranges are invalid, a Range er-
     ror  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 ex-
     tents 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 er-
     ror is returned.  If RANGE is True and  CHARS  contains
     any invalid ranges, a error is returned.


     [4mfontid[24m:  FONTID
     [4mrange[24m:  BOOL
     [4mchars[24m:  STRING8
     [4mformat[24m:  BITMAPFORMAT

  =>+

     [4mreplies-following-hint[24m:  CARD32
     [4moffsets[24m:  LISTofOFFSET32
     [4mbitmaps[24m:  LISTofBYTE




                             [1m28[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     Errors:

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


     [4mfontid[24m:  FONTID
     [4mrange[24m:  BOOL
     [4mchars[24m:  LISTofCHAR2B
     [4mformat[24m:  BITMAPFORMAT

  =>+

     [4mreplies-following-hint[24m:  CARD32
     [4moffsets[24m:  LISTofOFFSET32
     [4mbitmaps[24m:  LISTofBYTE

     Errors:

     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 re-
     placed with the font's XFONTINFO.CHAR-RANGE.  If any of
     the resulting character ranges are invalid, a Range er-
     ror 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



                             [1m29[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     were produced yields the original set.  A reply is gen-
     erated for each subset, in the order that it  was  pro-
     duced.

     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 ar-
     ranged  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 or-
     der that the characters appear in the subset.  Each en-
     try specifies the starting location in bytes  and  size
     in  bytes  of the corresponding glyph image in the BIT-
     MAPS 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.





                             [1m30[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     [4mfontid[24m:  FONTID

     Errors:

     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  li-
     censes  allocated  for  the font.  The client may reuse
     the value of FONTID in a subsequent request.

     If FONTID is not associated with any open fonts, a  er-
     ror is returned.


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

[1m4.3.  Errors[0m

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

     [4mtype[24m:  CARD8  value of 1
     [4merror-code[24m:  CARD8
     [4msequence-number[24m:  CARD16
     [4mlength[24m:  CARD32
     [4mtimestamp[24m:  TIMESTAMP
     [4mmajor-opcode[24m:  CARD8
     [4mminor-opcode[24m:  CARD8
     [4mdata-or-unused[24m:  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:


     [4mdata-or-unused[24m:  CARD16  unused





                             [1m31[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


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


     [4mdata-or-unused[24m:  CARD16  unused
     [4mformat[24m:  BITMAPFORMAT    bad format value

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


     [4mdata-or-unused[24m:  CARD16  unused
     [4mfontid[24m:  FONTID     bad font identifier

     This error is generated by an invalid FONTID in the and
     requests.  The value that caused the error is  included
     as extra data.


     [4mdata-or-unused[24m:  CARD16  unused
     [4mrange[24m:  RANGE  bad range

     This  error is generated by an invalid RANGE in the re-
     quests.  The value that caused the error is included as
     extra data.


     [4mdata-or-unused[24m:  CARD16  unused
     [4mevent-mask[24m:  EVENTMASK   bad event mask

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


     [4mdata-or-unused[24m:  CARD16  unused
     [4mac[24m:  ACCESSCONTEXT  unaccepted

     This  error is generated by an invalid ACCESSCONTEXT in
     the or request or by an request performed without  suf-
     ficient authorization.  In the first two cases, the AC-
     CESSCONTEXT of the errant request is returned as  extra
     data.   In the third case, the current ACCESSCONTEXT is
     returned as extra data.


     [4mdata-or-unused[24m:  CARD16  unused
     [4mid[24m:  ID   bad identifier

     This error is generated by an invalid or already  asso-
     ciated  ACCESSCONTEXT identifier in a request or FONTID



                             [1m32[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     identifier in an request.  The value  that  caused  the
     error is included as extra data.


     [4mdata-or-unused[24m:  CARD16  unused

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


     [4mdata-or-unused[24m:  CARD16  X value of errant resolution
     [4my-resolution[24m:  CARD16         Y value of errant resolu-
     tion
     [4mpoint-size[24m:  CARD16      point size of  errant  resolu-
     tion

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


     [4mdata-or-unused[24m:  CARD16  unused

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


     [4mdata-or-unused[24m:  CARD16  unused
     [4mlength[24m:  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.


     [4mdata-or-unused[24m:  CARD16  unused

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

     Additional errors may be defined by extensions.

[1m4.4.  Events[0m

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




                             [1m33[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     [4mtype[24m:  CARD8   value of 2
     [4mevent-code[24m:  CARD8
     [4msequence-number[24m:  CARD16
     [4mlength[24m:  CARD32
     [4mtimestamp[24m:  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:


                     [4marg1[24m: type1
                     ...
                     [4margN[24m: typeN

                 Description

If an event  does  not  provide  any  extra  arguments,  the
[4marg1[24m...[4margN[24m lines are omitted from the description.

The  core  X  Font  Service  protocol  defines the following
events:


     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 re-
     quest by sending any request (such as


     [4madded[24m:  BOOL
     [4mdeleted[24m:  BOOL

     This event is sent to clients  that  have  included  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.






                             [1m34[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


     [4madded[24m:  BOOL
     [4mdeleted[24m:  BOOL

     This event is sent to clients  that  have  included  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 catalogues 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.

[1m5.  Protocol Encoding[0m

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
               [4mcount[24m          [4mcontents[24m  [4mname[0m
               ...
               [4mcount[24m          [4mcontents[24m  [4mname[0m

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.

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 ex-
pressions in which they are used, should be treated  as  un-
signed integers.  Multiple copies of an object are indicated
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







                             [1m35[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


[1m5.1.  Data Types[0m

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



tab (@) ; l s s l l l.  ALTERNATESERVER
1@BOOL@subset 1@n@length of name  n@STRING8@name  p@@unused,
p=pad(n+2)


tab (@) ; l s s l l l.  AUTH
2@n@length  of name 2@d@length of data n@STRING8@name p@@un-
used, p=pad(n) d@STRING8@data q@@unused, q=pad(d)



BITMAPFORMAT
4    CARD32    value, union of the following bits:

tab (@) ; n  l.   #x00000001@ByteOrderMSB  #x00000002@BitOr-
derMSB  #x00000000@ImageRectMin #x00000004@ImageRectMaxWidth
#x00000008@ImageRectMax              #x00000000@ScanlinePad8
#x00000100@ScanlinePad16            #x00000200@ScanlinePad32
#x00000300@ScanlinePad64            #x00000000@ScanlineUnit8
#x00001000@ScanlineUnit16          #x00002000@ScanlineUnit32
#x00003000@ScanlineUnit64 l s n l.
except for the following bits which must be zero:
#xffffccf0@zero l s n l.
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:

tab (@) ; n l.   #x00000001@ByteOrderMask  #x00000002@BitOr-
derMask  #x00000004@ImageRectMask #x00000008@ScanlinePadMask
#x00000010@ScanlineUnitMask l s n l.
except for the following bits which must be zero:
#xffffffe0@zero










                             [1m36[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


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
1    CARD8     byte2


EVENTMASK
4         CARD32         event mask

tab (@) ; l s n l.  for core events, this is  union  of  the
following bits:
#00000001@CatalogueListChangeMask  #00000002@FontListChange-
Mask l s n l.
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:

tab (@) ; n l.  #x1fffffff
l s n l.  but none of the following bits set:
#xe0000000@zero



INT8
1    INT8      8-bit signed integer





                             [1m37[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


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
     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





                             [1m38[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


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:

n l.  #x00000001     AllCharactersExist  #x00000002     Ink-
Inside #x00000004     HorizontalOverlap l s n l.
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
12        XCHARINFO maximum bounds
2         INT16          font ascent
2         INT16          font descent
n         PROPINFO       property data

[1m5.2.  Requests[0m


tab (@) ; lfB s s lw(.25i) lw(2i) l.  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@au-
thorization-index  2@a/4@length  of   alternate-servers-hint
2@(d+q)/4@length  of  authorization-data  a@LISTofALTERNATE-
SERVER@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 ex-
pected  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  connec-
tion:




                             [1m39[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


tab   (@)   ;  lw(.25i)  lw(2i)  l.   ->  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 @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:


tab (@) ; lw(.25i) lw(2i) l.  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:

tab (@) ; lfB s s lw(.25i) lw(2i) l.  NoOp
1@0@major-opcode 1@@unused 2@1@length



tab (@) ; lfB s s lw(.25i) lw(2i) l.  ListExtensions 1@1@ma-
jor-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)



tab (@) ; lfB s s lw(.25i) lw(2i) l.  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
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



tab (@) ; lfB s s lw(.25i) lw(2i) l.  ListCatalogues 1@3@ma-
jor-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-num-
ber    4@4+(n+p)/4@length    4@CARD32@replies-following-hint
4@CARD32@number   of  catalogue-names  n@LISTofSTRNAME@cata-
logue-names p@@unused, p=pad(n)



tab (@) ; lfB s s lw(.25i) lw(2i) l.  SetCatalogues  1@4@ma-
jor-opcode       1@CARD8@number      of      catalogue-names



                             [1m40[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


2@1+(n+p)/4@length  n@LISTofSTRNAME@catalogue-names   p@@un-
used, p=pad(n)



tab (@) ; lfB s s lw(.25i) lw(2i) l.  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@@un-
used, p=pad(n)



tab (@) ; lfB s s lw(.25i) lw(2i) l.  SetEventMask
1@6@major-opcode     1@CARD8@extension-opcode     2@2@length
4@EVENTMASK@event-mask



tab (@) ; lfB s s lw(.25i) lw(2i) l.  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



tab (@) ; lfB s s lw(.25i) lw(2i) l.  CreateAC
1@8@major-opcode  1@CARD8@number  of authorization-protocols
2@2+a/4@length  4@ACCESSCONTEXT@ac   a@LISTofAUTH@authoriza-
tion-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@LISTof-
BYTE@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.


tab  (@)  ;  lw(.25i)  lw(2i)  l.    ->   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  @3@Denied 2@@unused d@LISTofBYTE@authorization-data
q@@unused, q=pad(d)



tab (@) ; lfB s s lw(.25i) lw(2i) l.  FreeAC
1@9@major-opcode 1@@unused 2@2@length 4@ACCESSCONTEXT@ac





                             [1m41[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


tab (@) ; lfB s s lw(.25i) lw(2i) l.  SetAuthorization
1@10@major-opcode 1@@unused 2@2@length 4@ACCESSCONTEXT@ac



tab (@) ; lfB s s lw(.25i) lw(2i) l.  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)



tab (@) ; lfB s s lw(.25i) lw(2i) l.  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)



tab (@) ; lfB s s lw(.25i) lw(2i) l.  ListFonts
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)



tab (@) ; lfB s s lw(.25i) lw(2i) l.  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) l s s lw(.25i) lw(2i) l.  =>+(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) @@@ l s s lw(.25i) lw(2i) l.  =>(last in
series) 1@0@type reply 1@0@last-reply indicator 2@CARD16@se-
quence-number 4@2@reply length



tab (@) ; lfB s s lw(.25i) lw(2i) l.  OpenBitmapFont
1@15@major-opcode        1@@unused        2@4+(n+p)/4@length
4@FONTID@fontid  4@BITMAPFORMATMASK@format-mask 4@BITMAPFOR-
MAT@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



tab (@) ; lfB s s lw(.25i) lw(2i) l.  QueryXInfo
1@16@major-opcode 1@@unused  2@2@length  4@FONTID@fontid  =>



                             [1m42[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


1@0@type     reply     1@@unused    2@CARD16@sequence-number
4@2+f/4@length f@XFONTINFO@font info p@@unused, p=pad(f)



tab (@) ; lfB s s lw(.25i) lw(2i) l.  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@se-
quence-number    4@3+3*n@length    4@n@number   of   extents
12*n@LISTofXCHARINFO@extents



tab (@) ; lfB s s lw(.25i) lw(2i) l.  QueryXExtents16
1@18@major-opcode     1@BOOL@range      2@3+(2*n+p)/4@length
4@FONTID@fontid        4@n@number        chars       entries
2*n@LISTofCHAR2B@chars p@@unused, p=pad(2*n) => 1@0@type re-
ply    1@@unused   2@CARD16@sequence-number   4@3+3*n@length
4@n@number of extents 12*n@LISTofXCHARINFO@extents



tab (@) ; lfB s s lw(.25i) lw(2i) l.  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 re-
ply            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@@un-
used, p=pad(m)



tab (@) ; lfB s s lw(.25i) lw(2i) l.  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  m@LISTofBYTE@glyph images p@@un-
used, p=pad(m)



tab (@) ; lfB s s lw(.25i) lw(2i) l.  CloseFont
1@21@major-opcode 1@@unused 2@2@length 4@FONTID@fontid








                             [1m43[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


[1m5.3.  Errors[0m


tab (@) ; lfB s s n lw(2i) l.  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



tab (@) ; lfB s s n lw(2i) l.  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



tab (@) ; lfB s s n lw(2i) l.  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-op-
code 2@@unused 4@FONTID@bad-fontid



tab (@) ; lfB s s n lw(2i) l.  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-op-
code 2@@unused 4@RANGE@bad-range



tab (@) ; lfB s s n lw(2i) l.  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



tab (@) ; lfB s s n lw(2i) l.  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  con-
text



tab (@) ; lfB s s n lw(2i) l.  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



tab (@) ; lfB s s n lw(2i) l.  Name



                             [1m44[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


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



tab (@) ; lfB s s n lw(2i) l.  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



tab (@) ; lfB s s n lw(2i) l.  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-op-
code 2@@unused



tab (@) ; lfB s s n lw(2i) l.  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



tab (@) ; lfB s s n lw(2i) l.  Implementation
1@1@type  error 1@11@Implementation 2@CARD16@sequence-number
4@4@length    4@TIMESTAMP@timestamp     1@CARD8@major-opcode
1@CARD8@minor-opcode 2@@unused


[1m5.4.  Events[0m


tab (@) ; lfB s s n lw(2i) l.  KeepAlive
1@2@type  event 1@0@event KeepAlive 2@CARD16@sequence-number
4@3@length 4@TIMESTAMP@timestamp



tab (@) ; lfB s s n lw(2i) l.  CatalogueListNotify
1@2@type event  1@1@event  CatalogueListNotify  2@CARD16@se-
quence-number  4@4@length 4@TIMESTAMP@timestamp 1@BOOL@added
1@BOOL@deleted 2@@unused



tab (@) ; lfB s s n lw(2i) l.  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




                             [1m45[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


[1m6.  Acknowledgements[0m

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  de-
signed  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 implementa-
tion.

[1m7.  References[0m

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''






























                             [1m46[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


                         [1mAppendix A[0m

                [1mSuggested Licensing Policies[0m


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  in-
clude,  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.






                             [1m47[0m





[1mX Font Service Protocol                     X11, Release 6.4[0m


                         [1mAppendix B[0m

                 [1mImplementation Suggestions[0m


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).

























                             [1m48[0m









                        [1mTable of Contents[0m


     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 . . . . . . . . . . . . . . . . . . . .  31
     4.4. Events . . . . . . . . . . . . . . . . . . . .  33
     5. Protocol Encoding  . . . . . . . . . . . . . . .  35
     5.1. Data Types . . . . . . . . . . . . . . . . . .  36
     5.2. Requests . . . . . . . . . . . . . . . . . . .  39
     5.3. Errors . . . . . . . . . . . . . . . . . . . .  44
     5.4. Events . . . . . . . . . . . . . . . . . . . .  45
     6. Acknowledgements . . . . . . . . . . . . . . . .  46
     7. References . . . . . . . . . . . . . . . . . . .  46
     Appendix A - Suggested Licensing Policies . . . . .  47
     Appendix B - Implementation Suggestions . . . . . .  48


































                              [1mi[0m


