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.