The X Font Service Protocol

X Consortium Standard

Jim Fulton

Network Computing Devices, Inc.

X Version 11, Release 7.6

Version 2.0

Copyright © 1991 Network Computing Devices, Inc.

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

Copyright © 1994 X Consortium

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

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

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

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Table of Contents

Introduction
Architectural Model
Font Server Naming

    TCP/IP Names
    DECnet Names

Protocol

    Data Types
    Requests
    Errors
    Events

Protocol Encoding

    Data Types
    Requests
    Errors
    Events

Acknowledgements
References
A. Suggested Licensing Policies
B. Implementation Suggestions

Introduction

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

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

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

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

From the user's point of view, font servers are simply a new type of name in
the X font path. Network name services allow descriptive names (such as
DEPARTMENT-FONTS or APPLICATION-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 variety of strategies for fine-grained demand-loading of glyphs.

Architectural Model

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

The X Font Service protocol does not require any changes to the core X protocol
or to any applications. To the user, font servers are simply additional types
of font path elements. As such, X servers may connect to multiple font servers,
as shown in Figure 2.1. Although the font protocol is geared towards the X
Window System, it may be also used by other consumers of font data (such as
printer drivers).

 ┌────────┐              ┌───────────────┐
 │   X1   ├──────────────┤               │
 │ Server │              │  Font Server  │
 └────────┘      ┌───────┤      1        │
                 │       └───────────────┘
 ┌────────┐      │
 │   X2   ├──────┘       ┌───────────────┐
 │ Server ├──────────────┤               │
 └────────┘              │  Font Server  │
                 ┌───────┤      2        │
┌─────────┐      │       └───────────────┘
│  other  │      │
│ clients ├──────┘
└─────────┘

Figure 2.1: Connecting to a Font Server

Clients communicate with the font server using the request/reply/event model
over any mutually-understood virtual stream connection (such as TCP/IP, DECnet,
^[2] etc.). Font servers are responsible for providing data in the bit and byte
orders requested by the client. The set of requests and events provided in the
first version of the X Font Service protocol is limited to supporting the needs
of the bitmap-oriented core X Window System protocol. 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
handled by adding new converters to a font server, as shown in Figure 2.2.

                ┌────────────┐
                │   client   │
                │ (X server) │
                └─────┬──────┘
                      │
                   network
                      │
┌─────────────────────┴──────────────────────┐
│                                            │
│                font server 1               │
│                                            │
├─────┬─────┬─────┬─────┬────┬─────┬───┬─────┤
│ bdf │ snf │ pcf │ atm │ f3 │ dwf │ │ │ ... │
└─────┴─────┴─────┴─────┴────┴─────┴─│─┴─────┘
                                     │
                                  network
                                     │
                               ┌─────┴────┐
                               │   font   │
                               │ server 2 │
                               └──────────┘

Figure 2.2: Where Font Data Comes 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 particular 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
Consortium.

Font Server Naming

Font clients that expose font server names to the user are encouraged to
provide ways of naming font servers symbolically (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 may be registered with the X
Consortium.

TCP/IP Names

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

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

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

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

DECnet Names

The following syntax should be used for DECnet names:

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

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

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

Protocol

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

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

  ● Alternate values are capitalized with no word separators, as in: MaxWidth

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

    Note

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

  ● Type declarations have the form "name: type", as in: CARD8: 8-bit byte

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

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

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

Data Types

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

ACCESSCONTEXT:     ID

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

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

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

ALTERNATESERVER:  [ name:  STRING8,
                    subset:  BOOL ]

    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 information is returned during the initial connection
    setup and may be used by the client to find a backup server in case of
    failure.

AUTH:  [ name:  STRING8,
         data:  LISTofBYTE ]

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

BITMAPFORMAT:

   CARD32 containing the following fields defined by the
   sets of values given further below
   [
     byte-order-msb:      1 bit,
     bit-order-msb:       1 bit,
     image-rect:          2 bits { Min,
                          MaxWidth,
                          Max },
     zero-pad:            4 bits,
     scanline-pad:        2 bits { ScanlinePad8,
                          ScanlinePad16,
                          ScanlinePad32,
                          ScanlinePad64 },
     zero-pad:            2 bits,
     scanline-unit:       2 bits { ScanlineUnit8,
                          ScanlineUnit16,
                          ScanlineUnit32,
                          ScanlineUnit64 },
     zero-pad:            2 bits,
     zero-pad:            16 bits,
   ]

    This structure specifies how glyph images are transmitted in response to
    QueryXBitmaps8 and QueryXBitmaps16 requests.

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

    If the BIT-ORDER-MSB bit (1 << 1) is set, the left-most bit in each glyph
    scanline unit is stored in the Most 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 following alternate values:

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

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

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

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

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

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

    ImageRectMax - This refers to all scanlines, from the maximum ascent (or
    the font ascent, whichever is greater) to the maximum descent (or the font
    descent, whichever is greater), padded to the same horizontal extents as
    MaxWidth. All glyph images have the same sized bitmap and share a common
    origin. This is the least compact representation, but may be the easiest or
    most efficient (particularly for character cell fonts) for some clients to
    use. The edges of the rectangle are:

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

    The SCANLINE-PAD field specifies the number of bits (8, 16, 32, or 64) to
    which each glyph scanline is padded before transmitting. It contains one of
    the following alternate values:

         ScanlinePad8          (0 << 8)
         ScanlinePad16         (1 << 8)
         ScanlinePad32         (2 << 8)
         ScanlinePad64         (3 << 8)

    The SCANLINE-UNIT field specifies the number of bits (8, 16, 32, or 64)
    that should be treated as a unit for swapping. This value must be less than
    or equal to the number of bits specified by the SCANLINE-PAD. It contains
    one of the following alternate values:

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

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

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

BITMAPFORMATMASK: CARD32 mask

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

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

Unspecified bits are required to be zero or else a Format error is returned.

BOOL: CARD8

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

         False              0
         True               1

BYTE: 8-bit value

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

CARD8: 8-bit unsigned integer

CARD16: 16-bit unsigned integer

CARD32: 32-bit unsigned integer

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

CHAR2B: [ byte1, byte2: CARD8 ]

    This structure specifies an individual character code within either a
    2-dimensional matrix (using BYTE1 and BYTE2 as the row and column indices,
    respectively) or a vector (using BYTE1 and BYTE2 as most- and
    least-significant 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 extension's (or the core's)
    maskable events the client would like to receive. Each bit indicates one or
    more events, and a bit value of one indicates interest in a corresponding
    set of events. The following bits are defined for event masks specified for
    the core protocol (i.e. an EXTENSION-OPCODE of zero in SetEventMask and
    GetEventMask requests):

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

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

    Extensions that provide additional events may define their own event masks.
    These event masks have their own scope and may use the same bit values as
    the core or other extensions. All unused bits must be set to zero. In
    SetEventMask requests, if any bits are set that are not defined for the
    extension (or core) for which this EVENTMASK is intended (according to the
    EXTENSION- OPCODE given in the SetEventMask request), an EventMask error is
    generated. This value is swapped as a CARD32.

FONTID: ID

    This is specified by the client in the request OpenBitmapFont 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 provided by a font. Strings
    for all of the properties names and values are stored within the data block
    and are located using a table of offsets and lengths.

    This structure is padded to 32-bit alignment.

PROPOFFSET:     [ name:          OFFSET32,
                 value:          OFFSET32,
                 type:           CARD8,
                 zero-pad3:      BYTE, BYTE, BYTE ]

    This structure specifies the position, length, and type of of data for a
    property.

    The NAME field specifies the position and length (which must be greater
    than zero) of the property name relative 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:

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

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

        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.

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, typically 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 represent 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 measured 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 (measured to the right)
    from the origin to the position where the next character should appear
    (called the "escapement point"). This distance includes any whitespace used
    for intercharacter padding and is also referred to as the "logical width"
    or "horizontal escapement."

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

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

    The ATTRIBUTES field specifies glyph-specific information 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 pixels. This box has a width of RBEARING -
    LBEARING pixels 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 characters 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 escapement point. If this bit is clear, there may be glyphs
        whose ink extends outside this rectangle.

    HorizontalOverlap

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

    The DRAWING-DIRECTION field contains a hint indicating whether most of the
    character metrics have a positive (or "LeftToRight") logical width or a
    negative ("RightToLeft") logical width. It contains the following 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 unencoded 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 minimum 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 ascents and descents that are
    greater than these values.

    The PROPERTIES field contains the property data associated with this font.

    This structure is padded to 32-bit alignment.

Requests

This section describes the requests that may be sent by the client and the
replies or errors that are generated in response. Versions of the protocol with
the same major version 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 corresponds to a core request, the MINOR-OPCODE
contains 8 bits of request-specific data. Otherwise, the MINOR-OPCODE specifies
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 deficient
(and therefore non-compliant) and is unable to process a request, it may return
an Implementation error. If a client uses an extension request without
previously having issued a QueryExtension request for that extension, the
server responds with a Request error. If the server encounters a request with
an unknown MAJOR-OPCODE or MINOR-OPCODE, it responds with a Request error. At
most one error is generated per request. If more than one error condition is
encountered in processing a requests, the choice of which error is returned is
server-dependent.

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

Each reply is at least 8 bytes long and contains the following 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-significant 16 bits of the sequence number of the request that
generated the reply are stored in the SEQUENCE-NUMBER field. The LENGTH field
specifies the number of 4-byte units in this reply packet, including the fields
described above, and must be at least two. If LENGTH is greater than two, the
fields described above are followed by (LENGTH - 2) * 4 bytes of additional
data.

Requests that have replies are described using the following syntax:

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

     Errors:  kind1, kind2 ..., kindK

     Description

If a request does not generate a reply, the"=>" and result lines are omitted.
If a request may generate multiple replies, the "=>" is replaced by a "=>+". In
the authorization 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:


  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
transmitted first; the octal value 154 (ASCII lowercase `l') indicates 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-PROTOCOL-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 initial
    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-PROTOCOL-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 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 connection. It has one of the following
    alternate values:


              Success          0
              Continue         1
              Busy             2
              Denied           3

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

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

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

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

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

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

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

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

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

    NoOp

    Errors: Alloc

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

ListExtensions

=>

    names: LISTofSTRING8

    Errors: Alloc

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

QueryExtension

    name: STRING8

=>

    present: BOOL

    major-version: CARD16

    minor-version: CARD16

    major-opcode: CARD8

    first-event: CARD8

    number-events: CARD8

    first-error: CARD8

    number-errors: CARD8

    Errors: Alloc

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

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

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

ListCatalogues

    pattern: STRING8

    max-names: CARD32

=>+

    replies-following-hint: CARD32

    names: LISTofSTRING8

    Errors: Alloc

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

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

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

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

SetCatalogues

    names: LISTofSTRING8

    Errors: Alloc , Name

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

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

GetCatalogues

=>

    names: LISTofSTRING8

    Errors: Alloc

    This request returns the current list of catalogue names (encoded in ISO
    8859-1) associated with the client. These catalogues determine the set of
    fonts that are visible to ListFonts, ListFontsWithXInfo, and
    OpenBitmapFont. A zero-length list indicates the server's default set of
    fonts. Catalogue names are case-insensitive and may be returned in mixed
    case.

SetEventMask

    extension-opcode: CARD8

    event-mask: EVENTMASK

    Errors: EventMask , Request

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

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

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

GetEventMask

    extension-opcode: CARD8

=>

    event-mask: EVENTMASK

    Errors: Request

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

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

CreateAC

    ac: ACCESSCONTEXT

    authorization-protocols: LISTofAUTH

=>

    status: { Success, Continue, Denied }

    authorization-index: CARD8

    authorization-data: LISTofBYTE

    Errors: IDChoice

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

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

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

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

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

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

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

FreeAC

    ac: ACCESSCONTEXT

    Errors: AccessContext , Alloc

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

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

SetAuthorization

    ac: ACCESSCONTEXT

    Errors: AccessContext

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

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

SetResolution

    resolutions: LISTofRESOLUTION

    Errors: Resolution, Alloc

    This request provides a hint as to the resolution and preferred point size
    of the drawing surfaces for which the client will be requesting fonts. The
    server may use this information to set the RESOLUTION_X and RESOLUTION_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 partially-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 error is returned and
    the default resolutions are not changed.

GetResolution

=>

    resolutions: LISTofRESOLUTION

    Errors: Alloc

    This request returns the current list of default resolutions. If a client
    has not performed a SetResolution, a server-dependent default value is
    returned.

ListFonts

    pattern: STRING8

    max-names: CARD32

=>+

    replies-following-hint: CARD32

    names: LISTofSTRING8

    Errors: Alloc

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

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

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

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

ListFontsWithXInfo

    pattern: STRING8

    pattern: STRING8

    pattern: STRING8

    max-names: CARD32

=>+

    replies-following-hint: CARD32

    info: XFONTINFO

    name: STRING8

    Errors: Alloc

    This request is similar to ListFonts except that a separate reply
    containing the name, header, and property data is generated 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 number 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 synchronize the client with the server.

OpenBitmapFont

    fontid: FONTID

    pattern: STRING8

    format-mask: BITMAPFORMATMASK

    format-hint: BITMAPFORMAT

=>

    otherid: FONTID or None

    otherid-valid: BOOL

    cachable: BOOL

    Errors: IDChoice, Name, Format, AccessContext, Alloc

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

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

    If the server is willing and able to detect that the client has already
    opened the font successfully (possibly 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 alternative to FONTID. Otherwise, if OTHERID-VALID is False, OTHERID is
    no longer open but has not been reused by a subsequent OpenBitmapFont
    request.

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

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

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

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

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

QueryXInfo

    fontid: FONTID

=>

    info: XFONTINFO

    Errors: Font, Alloc

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

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

QueryXExtents8

    fontid: FONTID

    range: BOOL

    chars: STRING8

=>

    extents: LISTofXCHARINFO

    Errors: Font, Range, Alloc

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

QueryXExtents16

    fontid: FONTID

    range: BOOL

    chars: LISTofCHAR2B

=>

    extents: LISTofXCHARINFO

    Errors: Font, Range, Alloc

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

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

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

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

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

QueryXBitmaps8

    fontid: FONTID

    range: BOOL

    chars: STRING8

    format: BITMAPFORMAT

=>+

    replies-following-hint: CARD32

    offsets: LISTofOFFSET32

    bitmaps: LISTofBYTE

    Errors: Font, Range, Format, Alloc

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

QueryXBitmaps16

    fontid: FONTID

    range: BOOL

    chars: LISTofCHAR2B

    format: BITMAPFORMAT

=>+

    replies-following-hint: CARD32

    offsets: LISTofOFFSET32

    bitmaps: LISTofBYTE

    Errors: Font, Range, Format, Alloc

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

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

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

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

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

    For each character in a subset, an image of that character's glyph is
    described by a rectangle of bits corresponding 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
    FORMAT.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 FORMAT.BIT-ORDER-MSB. The bytes of each unit are then arranged
    such that the most- or least-significant byte, according to
    FORMAT.BYTE-ORDER-MSB, is transmitted first. Finally, the units are
    arranged such that the left-most is transmitted first and the right-most is
    transmitted last.

    The individual images within a subset are then concatenated 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
    FORMAT.SCANLINE-UNIT.

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

    The REPLIES-FOLLOWING-HINT field in all but the last reply contains a
    positive value that specifies the number 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 FORMAT is invalid, a Format error is returned.

CloseFont

    fontid: FONTID

    Errors: Font, Alloc

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

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

"close connection"

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

Errors

All errors are at least 16 bytes long and contain the following fields:

    type: CARD8 value of 1

    error-code: CARD8

    sequence-number: CARD16

    length: CARD32

    timestamp: TIMESTAMP

    major-opcode: CARD8

    minor-opcode: CARD8

    data-or-unused: CARD16

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

The following errors are defined for the core protocol:

Request

    data-or-unused: CARD16 unused

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

Format

    data-or-unused: CARD16 unused

    format: BITMAPFORMAT bad format value

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

Font

    data-or-unused: CARD16 unused

    fontid: FONTID bad font identifier

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

Range

    data-or-unused: CARD16 unused

    range: RANGE bad range

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

EventMask

    data-or-unused: CARD16 unused

    event-mask: EVENTMASK bad event mask

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

AccessContext

    data-or-unused: CARD16 unused

    ac: ACCESSCONTEXT unaccepted AccessContext

    This error is generated by an invalid ACCESSCONTEXT in the FreeAC or
    SetAuthorization request or by an OpenBitmapFont request performed without
    sufficient authorization. In the first two cases, the ACCESSCONTEXT of the
    errant request is returned as extra data. In the third case, the current
    ACCESSCONTEXT is returned as extra data.

IDChoice

    data-or-unused: CARD16 unused

    id: ID bad identifier

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

Name

    data-or-unused: CARD16 unused

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

Resolution

    data-or-unused: CARD16 X value of errant resolution

    y-resolution: CARD16 Y value of errant resolution

    point-size: CARD16 point size of errant resolution

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

Alloc

    data-or-unused: CARD16 unused

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

Length

    data-or-unused: CARD16 unused

    length: CARD32 bad length value

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

Implementation

    data-or-unused: CARD16 unused

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

Events

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

    type: CARD8 value of 2

    event-code: CARD8

    sequence-number: CARD16

    length: CARD32

    timestamp: TIMESTAMP

The TYPE field contains the value 2. The EVENT-CODE field specifies the number
of the event and is in the range 0-127 for core events or the range 128-255 for
extensions. The SEQUENCE-NUMBER field specifies the least significant 16 bits
of the sequence number of the last request to have been processed by the
server. The LENGTH field specifies the number of 4-byte units in this event
packet and must always have a value of at least 3. The TIMESTAMP field
specifies the server time when the event occurred. If LENGTH is greater than
three, these fields are followed by (LENGTH - 3) * 4 bytes of additional data.

Events are described using the following syntax:

EventName
         arg1: type1
         ...
         argN: typeN

          Description

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

The core X Font Service protocol defines the following events:

KeepAlive

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

CatalogueListNotify

    added: BOOL

    deleted: BOOL

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

FontListNotify

    added: BOOL

    deleted: BOOL

    This event is sent to clients that have included FontListChangeMask in
    their event mask whenever the list of fonts that are provided by the
    currently selected catalogues has changed. The ADDED field is True if new
    fonts have been added to any of the 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.

Protocol Encoding

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


    Name
     count          contents     name
     ...
     count          contents     name

where COUNT is the number of bytes in the data stream occupied 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-letter variable (whose
scope is limited to the request, reply, event, or error in which it is found)
to represent the number of objects in the list. These variables, and any
expressions in which they are used, should be treated as unsigned integers.
Multiple copies of an object are 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

Data Types

ACCESSCONTEXT

4 CARD32 access context with at least one of the following bits set:

#x1fffffff

but none of the following bits set:

#xe0000000               zero


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

AUTH

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


BITMAPFORMAT

4 CARD32 value, union of the following bits:
     #x00000001           ByteOrderMSB
     #x00000002           BitOrderMSB
     #x00000000           ImageRectMin
     #x00000004           ImageRectMaxWidth
     #x00000008           ImageRectMax
     #x00000000           ScanlinePad8
     #x00000100           ScanlinePad16
     #x00000200           ScanlinePad32
     #x00000300           ScanlinePad64
     #x00000000           ScanlineUnit8
     #x00001000           ScanlineUnit16
     #x00002000           ScanlineUnit32
     #x00003000           ScanlineUnit64

except for the following bits which must be zero:

     #xffffccf0           zero

and the following of which at most one bit may be set:

     #x0000000c at most one bit can be set


BITMAPFORMATMASK

4 CARD32 value, mask of the following bits:

     #x00000001           ByteOrderMask
     #x00000002           BitOrderMask
     #x00000004           ImageRectMask
     #x00000008           ScanlinePadMask
     #x00000010           ScanlineUnitMask

except for the following bits which must be zero:

     #xffffffe0           zero

BOOL

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

BYTE
1    BYTE       unsigned byte of data

CARD8
1    CARD8       8-bit unsigned integer

CARD16
2    CARD16      16-bit unsigned integer

CARD32
4    CARD32      32-bit unsigned integer

CHAR2B
1    CARD8       byte1
1    CARD8       byte2

EVENTMASK
4    CARD32 event mask
     for core events, this is union of the following bits:

     #00000001   CatalogueListChangeMask
     #00000002   FontListChangeMask

but none of the following bits set:

     #fffffffc

extensions define their own sets of bits

FONTID

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

     #x1fffffff

but none of the following bits set:

     #xe0000000   zero

INT8
1    INT8         8-bit signed integer

INT16
2    INT16         16-bit signed integer

INT32
4    INT32         32-bit signed integer

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

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

PROPOFFSET
8    OFFSET32         name in data block
8    OFFSET32         value in data block

1 CARD8 type, one of the following values:
0    String
1    Unsigned
2    Signed
3    zero

RANGE
2    CHAR2B                 minimum character code
2    CHAR2B         maximum character code

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

STRNAME
1    n length of name
n    STRING8 name

STRING8
n    LISTofBYTE         array of 8-bit character values

TIMESTAMP
4    CARD32         milliseconds since server time origin

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

XFONTINFO
4 CARD32 flags, union of the following bits:
     #x00000001         AllCharactersExist
     #x00000002         InkInside
     #x00000004         HorizontalOverlap

but none of the following bits set:

     #xfffffff8         zero
4    RANGE              range of characters in font
1    CARD8              drawing direction
     0             LeftToRight
     1             RightToLeft
1                       unused
2    CHAR2B             default character
12   XCHARINFO          minimum bounds
12   XCHARINFO          maximum bounds
2    INT16              font ascent
2    INT16              font descent
n    PROPINFO           property data

Requests

open connection

1     BYTE                   byteorder, one of the values:
      #x42                   MostSignificant Byte first
      #x6c                   LeastSignificant Byte first
1     CARD8                  numberof auth in auth-data
2     2                      client-major-protocol-version
2     0                      client-minor-protocol-version
2     a/4 lengthof           auth-data
a     LISTofAUTH             auth-data
=>
2     CARD16                 status
0                            Success
1                            Continue
2                            Busy
3                            Denied
2     2                      major version
2     0                      version
1     CARD8                  numberof alternate-servers-hint
1     CARD8                  authorization-index
2     a/4                    lengthof alternate-servers-hint
2     (d+q)/4                lengthof authorization-data
a     LISTofALTERNATESERVER  alternate-servers-hint
d     LISTofBYTE             authorization-data
q                            unused, q=pad(d)

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

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

When STATUS is Success, the protocol resumes with the following sent by the
server:

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

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

NoOp
1   0                        major-opcode
1                            unused
2   1                        length

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

QueryExtension
1   2                        major-opcode
1   n                        length of name
2   1+(n+p)/4                length
n   STRING8                  name
p                            unused, p=pad(n)
=>
1   0                        type reply
1   BOOL                     present
2   CARD16                   sequence-number
4   5                        length
2   CARD16                   major-version
2   CARD16                   minor-version
1   CARD8                    major-opcode
1   CARD8                    first-event
1   CARD8                    number-events
1   CARD8                    first-error
1   CARD8                    number-errors
3                            unused

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

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

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

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

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

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

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

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

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

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

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

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

ListFonts
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                   numberof font-names
n   LISTofSTRNAME            font-names
p                            unused, p=pad(n)

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

OpenBitmapFont
1   15                       major-opcode
1                            unused
2   4+(n+p)/4                length
4   FONTID                   fontid
4   BITMAPFORMATMASK         format-mask
4   BITMAPFORMAT             format
n   STRNAME                  pattern
p                            unused, p=pad(n)
=>
1   0                        type reply
1   BOOL                     otherid-valid
2   CARD16                   sequence-number
4   4                        length
4   FONTID                   otherid
1   BOOL                     cachable
3                            unused

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

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

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

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

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

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

Errors


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

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

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

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

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

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

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

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

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

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

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

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


Events

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

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

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


Acknowledgements

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

References

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

X Window System Protocol Version 11. Robert W. Scheifler.

Adobe System - Bitmap Distribution Format 2.1.

X Consortium. X Logical Font Description Conventions, Version 1.5.

A. Suggested Licensing Policies

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

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

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

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

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

  ● 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 transmitted and is being cached).

  ● 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 AccessContext error.

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

B. Implementation Suggestions

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

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

  ● 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 implementations
    are encouraged to use shared memory so that in-memory font databases can be
    shared.

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

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


━━━━━━━━━━━━

^[1] X Window System is a trademark of The Open Group.

^[2] DECnet is a trademark of Digital Equipment Corporation.

