Part 2 -
How X Works, in Detail, and How the User Sees It
So far we have seen an outline of the architecture of X, and the benefits that X can provide for your organization.
In this second Part of the book we look at the internal mechanisms of the system in some detail - how to use the system is covered later in Part 3. You need to understand some of the mechanisms so you can fully appreciate how the system is used, but if you are very keen to look at how the system is used, then jump ahead now, and come back to Part 2 later.
In Part 2 we are building on the quick overview of the system presented in Part I, where you saw that X consists of servers, clients, and communications between them. We are now going to look at the system components in much more depth and will cover:
- The server's role, and how it handles input, and output in particular
- Communication between clients and server including networkfactors and loudings, and how input is passed from server to client.
- Clients and how they are built up.
- Defining a 'look and feel', and how you use toolkits to provide a consistent user interface.
- Window mnnagement, and its contribution to the user interface.
- Mechanisms to support interworking of multiple applications.
Chapter 3-
The Server - the Display Control Software
Introduction
This chapter looks in detail at the facilities the server provides, how it is implemented, what it contains, and also what it does not contain but leaves to the clients to handle instead. Most of this chapter deals with output - drawing text and graphics. Input is covered in the next chapter; as we shall see, most of the input processing is handled not by the server itself but by the clients.
3.1 The role of the server
The X server receives requests from client applications and actions them, usually producing output on the display screen. It controls the display's input devices, and sends user input to client applications. It also manages internal resources such as fonts and cursors, manages colour tables, etc. The design goals of X have meant that the server contains as little as possible.
The server is the base system; everything else is in the client and can be relatively easily changed, but whatever is in the server is fixed. (Remember, the server is very analogous to a terminal: you can't change the server, just as you can't change the internal operation of a VT220 terminal after it has been manufactured.)
The main functions of the server (Figure A) are:
- Processing output. Requests arrive from many clients, and have to be actioned: by manipulating windows, drawing text and graphics, or sending information back to the client. This aspect of the server involves:
- Creating, configuring and destroying windows.
- Handling fonts and drawing text.
- Drawing lines, arcs, areas, etc.
- Drawing bitmapped (pictorial) images
Related to output, the server must manage resources at the request of clients. It has windows, fonts, cursors, off-screen images called pixmaps, colour lookup tables called colormaps, and tables called graphics contexts to control how graphics are drawn. These management and output functions are described in detail in the remainder of this chapter.
- Processing input. When you type on the keyboard or use the mouse the server has to detect this and send corresponding X events to the appropriate clients, to inform them of the input. However, as most of this work relaung to input processing is handled by the client, we'll cover it in the next chapter.
- Managing client-defined data such as properties, which clients use to communicate with each other. Communication between clients is a topic in itself, covered in Chapter 9.
- Handling network connections to multiple simultaneous remote and local applications.
Of course, many of these functions require the server to handle the hardware it is running on, or at least interact with the operating system on the server's machine.
Server design considerations
As little as possible of the overall functionality of the system is contained in the server. The advantages of this approach are:
- The server remains small, allowing it to be implemented on a wide range of machines, not all of which will have large memory. It also makes it easier to implement the server in read-only memory (ROM), which is often necessary for X-terminals.
- The less there is in the server, the more stable and reliable it will be.
- Functionality in a client program is easier to change or enhance, whereas the server is difficult to change: it is complex system software, it has usually been supplied in binary form by a third-party vendor, and may even be in ROM. New user interfaces and sophisticated input handling can be provided within the application. For example, audio input, or special keyboard processing for physically disabled users can be handled by a client; these can then work with any standard server, whereas server-based implementations would be tied to a particular manufacturer's equipment. (See Modules 4.2.3 and 4.3.)
- The speed of any code in the server is fixed - it is determined by the CPU the server is running on. On the other hand, you can always speed up anything in a client by running it on a different, faster CPU.
The next module describes the functions you might expect the server to handle but which are in faet left to the client for the reasons above.

Figure A. The functions of the server.
3.1.1 What the server does not include
Many functions such as window management, the user interface, and interpreting keyboard input are not performed by the server but are left to the client. This makes it possible to implement the server on a wide range of machines, and makes the system much more flexible.
In X many system functions are left to the X client program, which in other window systems would usually be handled by the base window system:
- The X client has to redraw the contents of any of its windows which were eovered up but which have become exposed again. Instead of remembering the contents of the obscured parts of the windows, the server just notices when they are re-exposed and sends a notifications to the client, effectively telling it to repaint the missing parts. It does this by sending an expose event, which specifies which area of the window has been freshly exposed (Figure A).
- There are no special facilities for resizing the image in an X windowzooming in or out, for example. This has to be done by the client, which recomputes at the new size whatever is to be drawn, and then sends requests to the server to clear the old image and draw the new one.
- All the application user interface code - for menus, scrollbars, pushbuttons, etc. - is in the client, so you can create any interface style you want by altering your own program, and without affecting the server. (Chapter 6 deals with the application user interface.)
- Window manager functions are performed by the separate window manager program, not by the server. As an example, when you are resizing a window by dragging the window border with the mouse, you get a `rubber-band' outline to indicate the new window size; it is the window manager that is watching how the mouse moves and that is sending requests to the server to successively draw and erase the rectangles to give the rubber-band effect. All the server is doing is sending mouse-motion events to the window manager, and actioning any drawing requests it receives (Figure B). When the window size is finally determined, the window manager resizes the window (by sending the appropriate request to the server). The server sends an event to the application telling it that its window's size has changed, and only at this late stage does the application take any action - typically redrawing the window, and perhaps zooming the image to fit the new window size. (Chapter 8 covers window managers in detail.)
- Interpreting keyboard (`character') input. The server doesn't know whether the client wants key presses to be interpreted as ASCII characters, or EBCDIC, or as a representation of some non-English language; so it leaves this to the client. (We discuss this is depth in Module 4.2.2.)
- Interpreting mouse input. The server passes straight to the client information about where the mouse button-clicks, motion, etc., occur.
In the next module we go back and concentrate on the server and how it is imple- mented.

Figure A. The client redraws freshly-exposed areas of windows as they are uncovered.

Figure B. The window manager client controls size and position of application windows in response to user actions.
3.2 Implementations of the X server
There are many different implementations of the X server for platforms ranging from standard multitasking workstations to simple PCs. Servers can contain extra system administration and usability features to make them easier to use and manage, as well as `extensions' which provide graphics and other capabilities not offered by the basic X system.
The MIT X Consortium produces sample implementations of server and clients. Sample servers are provided for a wide range of systems. (By `sample' we mean they are not `reference implementations' - just because an MIT X program does something, it doesn't mean it is correct. The official standard is the document from MIT that defines the `X Protocol'; if a program disagrees with the Protocol, the program is wrong.)
All the machines supported by the MIT sample implementation are UNIX workstations, but that is only because MIT does not have the resources to port to non-UNIX systems. Hardware manufacturers and third-party vendors have developed servers for other workstations and operating systems, and other systems including X-terminals, DOS PCs and other personal computers such as Atari and Amiga. There are even plugin cards containing server code, graphics controller and display memory, for a variety of systems.
Conceptually an X server is simple, and a schematic is shown in Figure A for the simplest case - a server running on a workstation. However, many implementations are more complex because of special requirements imposed by the target machine, or because of extra facilities added to the basic system. For example, Figune B shows schematically that an X-terminal is complicated by having to provide many of the basic facilities such as network handling which would be provided by the operating system in a workstation or PC.
Extra features in servers
While the X standards do not require it, almost all servers provide some convenient way of st.arting the first client application, so that you can initiate your X session. If the server didn't have this facility, you would have to st.art the application by entering commands on the keyboard of the remote host on which you'll be executing the application. So, effectively these startup mechanisms save you having to walk around your office to the remote machine. (System startup is described in Module 11.1.)
Another common extra is the facility of a virtual screen larger than your physical screen, which is particularly useful on PC X servers with low-resolution screens with relatively few pixels, for example, 600 x 480. The virtual screen may be much larger, say 1600 x 1000 pixels, and your physical window acts as a viewing port onto part of this larger area. This lets you start all the applications you need, but keep some of them off-screen out of the way, so that your limited screen space is kept uncluttered for the applications you are currentIy using. Some window managers provide a similar facility, illustrated in Module 8.1.1. (This facility is also sometimes called a virtual desktop or a virtual root window.)
Extensions to servers
When X was initially developed, its designers realized that certain functionality would have to be added to the system later, either because the technology had not yet matured enough, or because the functionality was not crucially important, or just because as any system develops people want it to do more and more. To handle add-ons like this cleanly, X has a well-defined mechanism for adding extended functionality to the server.
Specialised servers with extensions for live video windows, or PostScript or other special facilities are available. The ext.ension mechanism is also used to incorporate new functionality into new releases of standard servers, for example the support for non-rectangular windows which was added in Release 4. By using extensions rather than adding in new functions directly, compatibility is maintained with earlier releases and consistent operation on servers from different vendors is possible. (See Module 3.8 for more detail.)
Now we look at X-terminals in detail, as they illustrate some important features of the X system as a whole.

Figure A. Schematic structure of an X server

Figure B. An X-terminal has to provide many non-X functions as well as the server code.
3.2.1 Specific server implementations - X-terminals
Special-purpose X-terminals are becoming increasingly popular. An X-terminal is just a package consisting of an X server, the CPU and memory to run it on, mouse, keyboard, and network interface.
X-terminals illustrate some important features of X. In fact, a good way to understand X is to think of the server very much as a terminal. Most of the points mentioned below are also true for many of the X servers that run on PCs: these servers effectively transform the PC into an X-terminal. First we look at how X-terminals resemble ordinary terminals, and then at the important differences.
Similarity of X- and character-based terminals
Figure A illustrates many of the ways in which an X-terminal is like a character-based terminal:
- The terminal reads characters from the keyboard (or reads keyboard events in the case of X) and passes them `over the wire' to the application.
- The application doesn't run in the terminal itself, but on a host at the other end of the wire.
- The application sends `commands' (escape sequences) to the terminal, to affect the display, and the commands are fairly similar in the two cases. For example, the escape sequence to write characters `ABC' at cursor position X,Y is similar to the X request to draw font characters `ABC' at pixel coordinates X,Y. And the `clear screen' sequence is analogous to the X `delete window' request.
- X-terminals, just like other ones, `are faster at night'. Because all the applications are running on central hosts which are shared among many users, you may have patches of poor performance during the day when many people are using the system heavily. But at night you probably have the machines to yourself, so they seem faster!
- Terminals don't have any disks or files that can be damaged by a sudden failure of the electricity supply. After a power failure, you just switch on again.
Differences between X- and character terminals
Of course, X-terminals have many advantages over ordinary terminals:
- You can run many simultaneous applications instead of having only one at a time on your screen.
- You can be connected to many hosts simultaneously instead of to just one. . You can dynamically select the host you want for each X application, whereas character terminals have a hardwired connection to a single host
(or to a terminal server, which is really just a special intermediate type of host).
- You have a full GUI instead of a simple character interface.
- You have the full functionality of the mouse.
One disadvantage of X-terminals is that they have a dynamic requirement for memory, which is not easily predictable: the more applications you run, and the more fonts and other resources you use, the more memory you need. Well-engineered X-terminals warn you if you are running out of memory, so you can avoid any serious effects. And, some recent X-terminals have virtual memory systems, paging memory over the network using NFS (the network file system), giving you practically limitless memory.
In the next module we look at how many X-terminals provide a lot of extra useful features.

Figure A. Similarity of X-and character-based terminals.
3.2.2 Extra features for X-terminals
Many X-terminals provide a lot of extra functionality, both to make the terminals easier to use and administer, and to improve their performance.
Many innovations in X have been led by X-terminal manufacturers, not least because to survive commercially they must make their product.s as attractive as possible, and by adding features they have been able to differentiate X-terminals from competitive workstations, for example.
X-terminals provide many facilities that make it easy for the system manager to handle large numbers of X-terminals on a network:
- Facilities to start up a user session simply. (See xdm and XDMCP in Module 11.1 for much more detail.)
- Facilities for managing fonts for the network as a whole rather than on a per-machine basis. (See Module 3.5.1 for details of the X font server.)
- The option of storing the X server in ROM within the X-terminal (which makes getting the terminal up-and-running very easy) or of downloading the X server code from a file-server on the network (which makes it easy to upgrade the terminals' servers and ensure they are all using the same version or revision level).
Performance extras
Increasingly, X-terminals and PC X servers are allowing local clients. For terminals this is almost a contradiction in terms (if applications run inside it, it's not a terminal) but the clients provided are very restricted. The two most common options are a local window manager and a local telnet or local terminal emulator. These facilities simplify setup and reduce the amount of network traffic, which is especially useful when working over very slow network links such as serial lines.
The local window manager comes into its own where there is a high network latency, that is, the round-trip time from server to client and back again is long, which is often the case with satellite links or long-haul networks. If the window manager is tracking the mouse interactively, as when dragging a rubber-band outline, you get very bad response with high-latency connections; running a local window manager gets over this problem. However, for such networks you would probably be better off using a workstation and running as few applications as possible remotely. (For more about latency, see Modules 4.5 and 13.2.) The terminal manufacturers are also working (in conjunction with the MIT X Consortium) on standards to improve the performance of X over very slow networks (Module 13.2.1). As part of this, vendors are looking at running more applications locally in the terminal, to avoid the bottleneck of the slow network.
As these features develop and become more widespread, they are often adopted by other server vendors as well. This is especially true for PC X servers, because with these a PC is very little different from a true X-terminal.[Footnote: An interesting market prediction is that sales for X servers for PCs will overtake sales of purpose-built X-terminals in the next few years.] In fact, most extras that are generally applicable are implemented on almost every commercial server in time, and many have been adopted as formal standards by the MIT X Consortium, or are included in their release so they become de facto standards.
3.3 How the server handles output to the screen
X outputs graphics and text to windows on the screen. Windows are organized hierarchically in a tree structure.
Windows are the building blocks of X, and all output (drawing text and graphies) is performed in windows. In X, windows are cheap: they are not limited resources, so you can easily have hundreds of windows within an application. (Contrast this with other systems where each window in an application is equivalent to an open file: then you can only have a few tens of windows.)
Windows are arranged hierarchically in a tree structure, as shown in Figure A. The top of this tree is the root window, which covers the whole screen. Each application has its own window which is a child of the root window, and these are called top-level windows as they are at the top of the hierarchy. Application windows appear on top of the root window, and obscure the portions of the root window which are underneath. Within each application window there can be many sub-windows, each of which in turn can have its own sub-windows, and so on. Sub-windows are used to create separate objects or areas within the application. For example, a menu can be created out of one window for the menu background, with several child windows, one for each button on the menu, as shown in Figure B and Figure C. Or, in a simulation package you might use a separate sub-window for each component (valve, gauge, pipe, reactor vessel, etc.) in the model you are building.
You can change the size of windows, and their position relative to their parent. You can explicitly make a window invisible (remove it from the screen) by unmapping it, and bring it back later by re-mapping.
Windows are drawn on the display screen; X allows each display to have up to three screens (assuming the hardware can support this) as shown in Figure D. You still have only one keyboard and mouse; the three screens are controlled by the same server and it is the server, not the screen, that receives input. Multiple screens are very useful where large amounts of information must be displayed simultaneously, such as in mapping or geographical information systems, or in financial dealing rooms. They are also useful when debugging graphical systems; for instance, if you are developing your CAD package on one screen, it is helpful to be able to debug it from a different screen so that the debug windows themselves don't interfere with the application. Some X systems let you have multiple virtual screens: you switch between them by moving the mouse off the side of the screen, causing another virtual screen to be displayed on the physical monitor. (Note that the term `virtual screen' here has a different meaning than in Module 3.2, where it meant a large virtual root window.)
In the next module we look in more detail at how the visibility of windows is controlled, and in the module after next at how the application requests output to the screen.

Figure A. X windows are arranged in a tree hierarchy

Figure B. A sample menu, using sub-windows

Figure C. The window tree for the sample menu.

Figure D. X allows three screens on a display.
3.3.1 Visibility of windows, and clipping
The hierarchy of windows controls the visibility of windows. Child windows can be bigger than their parent, but those parts of them that are outside the parent's boundary are invisible - they are `clipped'.
A child window is clipped by its parent: only the part of the child that is within the parent window is visible (Figure A). A child window can be bigger than its parent, but clipping implies that part of the child will be invisible. You can draw into windows even when they are invisible, or partly so (but what you `drew' is effectively thrown away: if the invisible part is exposed again, the application will have to redraw that area).
This is a convenient feature in several ways. First, it lets the applications programmer create the window of a size best suited to the task at hand, to simplify the programming. For example, it is much easier to write `ABCD' into an oversized window and let the window system itself clip off all of the `D' and part of the `C' as shown in Figure B, rather than having to calculate the size the string would be in the window, omit the `D' and explicitly manipulate the image of a `C' character and then draw the result. Secondly, being able to draw into a window without having to worry if it fully visible or not is essential if applications are to work with different styles of window management. When you are writing your program you have no idea what constraints a window manager will impose - for example, whether windows will be overlapping on the screen, or `tiled' to lie side by side - so the more insulated you are from potential changes in visibility and size of your windows the better. Finally, the facilities of both types of virtual screens (Modules 3.2 and 3.3) rely on applications continuing to work when they are fully or partially off-screen (that is, outside their parent, the root window) and therefore fully or partially invisible.

Figure A. Child windows are clipped by their parent.

Figure B. Drawing into a clipped window
3.3.2 Graphics requests - requests for output
X outputs to the screen only in response to requests from clients. The requests specify what is to be drawn, or how windows are to altered. Graphics requests are usually object-based; for example, a line is specified by its start and end points - not as a set of pixels to be drawn. You can draw graphics to off-screen images in memory (`pixmaps') as well as to windows.
(If technical details aren't so relevant to you, you can skip over this module.)
All X output is the result of requests from clients. There are many different types of request, covering all the operations required for manipulation of screens, windows, text, graphics, and input control. Requests are to X what system calls are to an operating system - the fundamental operations on which everything else is based. This module describes the types of requests X provides, and the context in which they work, and we point you to other modules dealing with the more important points in greater detail.
- X provides two-dimensional graphics. (3-D support is provided by PEX, the PhigS extension to X; see Module 3.8.)
- Operations provided include: drawing lines and polylines, arcs and polyarcs, points, filled rectangles, filled polygons and polyarcs, and copy-area functions. We won't cover these in any detail, because they are straightforward functions, and are typical of any graphics system.
- There are functions for manipulating fonts, and drawing and handling text (Module 3.5), and managing colour (Module 3.6).
- There are functions for drawing and manipulating bit-mapped images (Module 3.7).
- You draw into either a window, or an off-screen image called a pixmap. (X defines the term drawable to mean either a window or a pixmap.) You can transfer images between pixmaps and windows; this is often used to ensure satisfactory performance in handling expose events (see Module 3.7.1 ). You can also read back images from the screen into memory, where you can process them, for redrawing or any other processing you want.
- Drawing is a two-stage process:
- First you set up one or more tables which describe how you will want to draw. You specify how wide lines are to be, how multiple line segments are to be joined (rounded or angled joins), what colour you'll be drawing in, which font to use if you are drawing text, etc. These tables are called graphics contexts or GCs.
- Then you issue the actual drawing request, specifying which graphics context is to be used for this particular operation, which drawable you are drawing into, and what you are drawing into it. As an example, details of a request to draw a line are shown in Figure A.
Doing things this way simplifies programming because a lot of workspecifying precise details of drawing - is done only once, when setting up the GC, rather than every time you draw. It also makes better use of the network: the large amount of information in the GC is sent to the server only once, when the GC is defined, and not in every single drawing request.
- X is a pixel-based system: all dimensions are in terms of pixels. Unlike systems such as PostScript, you cannot express dimensions in real-world units such as centimetres or inches (although some toolkits address this at the application level).
- The X coordinate system is rectangular and, again unlike PostScript, the server provides no facilities for scaling or transforming coordinates or dimensions

Figure A. Detailed contents of a request to draw two line segments.
3.4 The server contains the only display hardware
dependence in the system
Clients cannot access the display hardware directly - they can only send requests to the server, which in turn controls the hardware. So clients are independent of the type of hardware of the server, and the server's operating system.
One of the design goals of X was to make clients hardware independent. This is achieved by not giving them direct access to the display hardware, but insisting that they can only send requests to the server, which itself controls the display.
So, only the server knows what hardware is being used. For instance, if the server is running on a DOS PC, is the display EGA, or VGA, or some special graphics board? If the server is on a workstation, does it have a simple frame-buffer, or is there sophisticated graphies aceelerator hardware as well? The server has to receive standard requests from clients and then translate them into the appropriate hardware commands (or deposit appropriate instructions in the hardware registers) to make the particular hardware do what was requested (Figure A).
The server has to know what hardware is present, and support it. As shown in Figure B, the server (or the operating system it is built on) contains device drivers for the display hardware, as well as the keyboard, mouse and any other input devices. Therefore, while the server has probably been designed to be as portable as possible with a modular internal structure, when it is finally implemented it is very hardware dependent, and of course will only run on the CPU-type it was compiled for.
Clients are mostly hardware independent
Clients are completely hardware independent in the sense that any client can operate with any server, no matter what the architecture or operating system the two of them have. But there are a few hardware features that clients have to take account of:
- Is the display colour or monochrome? If monochrome, then requests to draw text in a blue foreground on a yellow background may succeed, that is, not cause an X error, but the result may be white text on a white background, which isn't very readable.
- How big is the screen? If I develop my client on a workstation with a 1200 x 900 pixel screen, and assume that the client will always be operating on a screen at least this big, if you then try to use it on a PC with a 600 x 400 pixel display, you will have real difficulty.
- What is the screen resolution, how many dots per inch? If I write an application assuming a resolution similar to the PC I am using (40 d.p.i.) and base my font sizes on this, when you run the application on a highresolution screen (120 d.p.i.), the text will be almost unreadable, because it will be only one third as high. This is because (as we'll see in the next module) fonts in X are handled in terms of pixels, and are resolution dependent; at 40 d.p.i. a 20-pixel character is 2in high, but only 6in at 120 d.p.i.
There are fairly easy solutions to these problems. By writing your application correctly you can make it very easy fur the user to customize (access to the source code isn't required) so that they can specify colours, sizes, layouts, etc. which are suited to their configuration, as described in Module 12.1. It is also possible to specify fonts in a resolution-independent way, and to query the server for details of the display so that layouts can take account of the available screen space, etc.
Mouse support - how many buttons?
Mice have different numbers of buttons: the Macintosh has one button, most PC mice have two, and most workstation mice have three. The server has no problem - it handles up to five buttons - but what if the application requires you to press the third button, and you have only one?
Server developers have tried to get over this by simulating the extra buttons: pressing, say, both buttons simultaneously on a two-button mouse simulates pressing a middle button. This is a nasty solution, as the user interface of the application is distorted, making it hard to use. As above, the correct approach is to make the application customizable, so the users can choose how the functions normally invoked with the missing mouse buttons are to be invoked on their systems. (But until all applications are written correctly, the server developers have to continue with their inelegant simulations.)

Figure A. The server translates X requests into commands to the hardware.

Figure B. The server, alone, knows hardware is present.
3.5 Handling text and fonts
X supports multiple fonts and character sets simultaneously on the screen. Text can only be horizontal; fonts are stored as bitmaps, text cannot be rotated, but from Release 5 onwards it can be scaled.
X supports multiple fonts, and allows sophisticated use of English and non-English character sets. Characters in a font may be of fixed width (as you need for terminal emulators, and some spreadsheet applications) or of variable width (which you need for proper typesetting and DTP).
Server vendors usually provide a large set of fonts for use with their server (but there are no standard fonts, so you can't assume a particular font exists). Fonts are normally provided ready for use with your server. They may also be distributed in a portable, plain-text, format called BDF (Bitmap Distribution Format) which you then have to convert into the format your server needs using a font-compiler provided with your server. In Release 5, the format is PCF (Portable Compiled Format): this stores the font information in an efficient internal form, but it is portable across all servers from Release 5 onwards. In Release 4 and earlier, the internal format was SNF (Server Natural Format); in practice this often was portable across platforms, but the specification did allow it to be platform-specific, and BDF was the only guaranteed portable form.
X has a standard naming scheme for fonts, called XLFD (X Logical Font Description). The XLFD name contains information about the type of font this is - the typeface, character size, whether bold or italic, etc. - so a lot of information about the font can be obtained just from the name, without having to load the whole font into the server first. We don't want to load unnecessary fonts, because they consume a lot of memory in the server. The server also accepts font specifications that contain `wildcards', so when you are naming a font, you only have to give specific characteristics you are interested in, instead of having to name a font exactly. This lets you specify font names more or less generically, which makes you less dependent on specific fonts being available on every server (see Module 11.3).
Characters in a font are encoded as one or two bytes, that is characters in some X fonts are represented by 8 bits, and in other fonts by 16 bits. An 8-bit font can contain 2ş = 256 characters, which is adequate for English and European languages, and many sets of symbols. A 16-bit font can contain 2'6 = 65536 characters, and is required to accommodate the very large oriental character sets. The eneoding of a character within a font just means its number or position in the font; for example the ASCll encoding of upper-case B is 66, that is, when a byte containing 66 is interpreted as an ASCII character, it is taken to mean B. Where possible X uses the encodings specified by ISO, the international standards body. In fact the final parts of the XLFD name specify the encoding. `ISO8859-1' specifies `ISO Latin alphabet number 1', which is more or less ASCII with extras covering some symbols and letters with diacritical marks (aceents, etc.) for European (`Latin') languages. Other ISO8859 encodings cover Cyrillic, Hebrew, Greek and Arabic languages, and there are also standard encodings for the oriental languages.
Up to and including Release 4, X fonts were stored exclusively as bitmaps on the server (as `files', usually in ROM on an X-terminal or on disk on a workstation), and in Release 5 most files are still in this form. There are several consequences of this:
- Even though characters are stored as bitmaps, they are actually in the server, so drawing characters does not involve transmitting bitmaps over the network.
- If you want the same font at a different size, you have to have a separate font file for it. This takes extra storage space, and also uses memory in the server when the font is loaded for use.
- Text must be horizontal. It can run from left-to-right or right-to-left, but it cannot be rotated. Even if you want text rotated 90 deg. to label the axis of a graph, X gives you no help. (You have to pull the character bitmaps from the font into your applications, rotate the bitmap using graphics manipulation techniques, and then paint the rotated bitmap.) Most applications only need horizontal text, so these limitations are not as serious as they initially appear, and some of them are likely to be removed in future releases (see Module 15.1).
With Release 5, a mechanism has been provided for scaling fonts, in three ways:
- A scaler for bitmap fonts has been included, which lets you use any bitmap font at any size. But it is a simple mechanism and the results can be slightly ugly unless you are increasing the size to an exaet multiple of the original (Figure A).
- The Bitstream Speedo system for scalable outline fonts has been incorporated. Instead of representing each character in the font as a bitmap, it is stored as a set of curves representing the shape of the character, which can be scaled to whatever size is necessary and then converted to a bitmap for drawing the character on the screen.
- The user-contributed software release contains a PostScript Type 1 font scaler, plus some Type 1 scalable outline fonts.
In the next two modules we look at the X font server which allows fonts to be managed centrally, and at the requests used to draw text.

Figure A. Scaling a bitmap font can produce ugly results
3.5.1 The X Font Server
Storing fonts on individual X servers makes system administration difficult, especially on a large network. This is overcome by storing the fonts on a `font server'; the X server retrieves fonts from the font server rather than reading them directly itself.
Storing fonts on the X server, especially in a server-specific format, causes many problems:
- Even when fonts are not loaded they take up a lot of storage space, on disk or in ROM. For example, on our MIT server, a typical bitmap font for Romanlanguage text takes between 10 and 20 kbytes on disk, an outline font takes about 65 kbytes, and a bitmap Chinese-language font takes between 0.5 and 1.0 Mbytes! So on a network of X stations, you may be using a vast amount of disk space, storing multiple copies of the same fonts for different servers.
- Server and application vendors supply different fonts; you may find that when you get a new application which requires a specific font, you have to install this font individually on all your X stations.
- Introducing new font formats becomes very difficult, not just because of the difficulty of upgrading all X servers everywhere, but also because the new font format may depend on a proprietary technology not available to all X server developers.
- Formats such as outline fonts consume a lot of CPU power and memory: this may make them unsuitable for low end servers such as PCs and small X-terminals.
To get over these problems, the X font server was developed. The basic idea is that the X server, instead of reading font files directly itself, requests them from the font server, which provides them in the bitmap format required by that X server.
Figure A illustrates three important points about the font server design. First, a single font server can provide fonts for many X servers. Secondly, an X server can be connected to more than one font server. And finally, font servers can be chained together: if the first font server has been asked for a font which it does not have, it can request this font from another font server it is connected to. Let's see how these features overcome the problems we listed above.
- Fonts no longer need to be duplicated across every X server - the font server can hold a single copy and make it accessible to all the X servers on the network.
- Adding a font to the network is easy - you only have to load it onto one font server and it is available to all X servers and therefore to all applications.
- A new font format can easily be accommodated - only the font server needs to be enhanced to handle it. If the technology for the new format is proprietary, the vendor can supply a complete font server for the new format; this font server can then be chained to existing font servers without any modification at all (Figure B).
- The font server can be run on a powerful compute server, which is able to handle the demands of complex font formats.
These factors are especially attractive for networks of X-terminals, because they reduce still further the amount of (X) terminal-specific information that has to be stored anywhere.
The font server also provides other facilities for administration. It provides licensing and access control, because many fonts cany a licence or usage fee. It supports grouping fonts into subsets called catalogues to help you control who can access which fonts. For example, you might group chargeable fonts into a catalogue and make it available only to specialized DTP users who really need those facilities. The sample implementation of the font server in Release 5 doesn't support these facilities.

Figure A. Relationship of X servers with font servers.

Figure B. Adding a new font format by adding a proprietary font server
3.5.2 Graphics requests for text
X provides requests for inquiring about which fonts are available, for loading specified fonts, for drawing text, and for calculating dimensions of text prior to drawing.
(If technical details aren 't so relevant to you, you can skip over this module. )
There are relatively few graphics requests for handling text and fonts, because X's text handling is straightforward. This module describes the requests and some more detailed aspects of X's text handling.
3.6 Handling colour
X provides support for a very wide range of colour capabilities, from simple mono bitmap frame buffers to elaborate 24-bit colour systems. Colours can be specified by name, in terms of RGB components or device-independent specifications, or as internal values within the server.
In keeping with its design goal of being suited to a wide range of display types, X works across the whole spectrum of hardware, from monochrome to 24-bit colour, as well as grayscale.
Internally - that is,within the server - X colour specifications consist of three 16-bit values, one each for the red, green and blue components (RGB) of the colour to
be displayed. These values are normally written in hexadecimal notation:
pure red ffff / 0000/ 0000 full red,no green or blue
pure green 0000 / ffff / 0000 full green,only
white ffff / ffff / ffff as much of everything as possible
black 0000 / 0000 / 0000 nothing at all
yellow ffff / ffff / 0000 mixture of red and green
Externally,for example when you specify in a text file a default colour for some item, you can use ordinaty colour names like `pink',`orange',etc. And most X programs let you specify foreground and background colours on the command-line when you run them,as in:
xclock -foreground red -background blue
You can also use RGB specifications externally in place of colour names, by adding a prefix of `rgb:'.[Footnote:Release 5 only. Earlier releases had a similar facility, but the rgb: prefix wasn't necessary, because the other types of colour specifications introduced with Release 5 were not supported. In Release 4 and earlier, an explicit RGB colour was prefixed with a hash (#) to distinguish it from a colour name.] The command:
xclock -foreground rgb:ffff/0/0 -background rgb:0/0/ffff
is exactly equivalent to the one above.
The server maintains a simple database of colour names and the corresponding RGB values; internally, using standard X functions, the client can request the server to lookup a colour name, and use the value returned, or it can specify a colour directly by name. The MIT program showrgb lists the colour names your server knows about, with their RGB components; for example, Figure A shows a selection of lines in our colour database.
A given RGB specification can result in markedly different colours depending on the monitor and graphics hardware used. As well as being more natural, colour names allow a degree of device independence, by letting you tune the RGB-values allocated to a colour name for the particular hardware you are using. For example, you (or your system vendor) would ensure that the RGB specification corresponding to `pink' really does give a pink colour on screen! In Release 5, a much more powerful system for specifying colours in a device-independent way was included, and we describe that in the next module. After that we describe some of the detailed mechanisms available for handling multiple applications which together require more colours than the hardware can display at one time.

Figure A. Some of the entries in our RGB colour database.
3.6.1 Device-independent colour specifications
Release 5 introduced Xcms, the X Colour Management System. This lets you specify colours in a device-independent way, so you can be sure the visible colour will be the same whatever hardware it is displayed on.
(If technical details aren 't so relevant to you, you can skip over this module.)
The RGB scheme for specifying colour that we outlined in the previous module relates very elosely to colour display hardware. The individual RGB values specify more or less directly the intensity with which the electron guns in the hardware are to fire at the red, green and blue phosphors on the sereen. While this scheme may be a convenient way of driving the hardware, it has several deficiencies from the point of view of people:
- As we already mentioned, the visible result produced by RGB specifications varies widely across different systems.
- It isn't easy for the user to specify colours:
- If you have a colour and its RGB value, and want to get a related colour - for example, a brighter version - it isn't obvious how to change the RGB values. You will often have to change the three RGB components by unequal proportions to get the effect you require.
- The size of increment needed to get a visible difference in the colour displayed depends upon where you are in the possible range of RGB values. For low intensities you may have to increase a component value by 10 or 20 steps before you can see any difference; elsewhere, one step may be enough.
- There is no unique representation for a colour as perceived by the user: one colour can have many corresponding RGB representations, which ean result in you using more colours in the server than necessary. (We'll see the significance of this in Module 3.6.3.)
To overcome these problems, Xcms, the X Colour Management System, was introduced with Release 5. This makes use of the international colour standards of the CIE (Commission Internationale de l'Eclairage - International Commission on Illumination). With Xcms, colours can now be specified using the CIE XYZ, CIE uvY, CIE xyY, CIE L*a*b*, CIE L*u*v*, and TekHVC schemes, as well as the RGB values and colour names we have already seen. These schemes were developed to allow colours to be specified in an absolute and reproducible way, and with the exception of TekHVC were not specifically for addressing colour in computer systems (in fact, most of these systems were developed quite a long time ago). By using one of these representations, you can specify a colour irrespective of the hardware you are using, and with Xcms you can reliably reproduce this colour on any hardware. We won't go into the details of all these specification schemes, but will just outline the principles of Xcms.
With Xcms there are no changes in the serşer - it still handles colours internally in terms of RGB specifications. All the changes are on the client side, and consist of enhancements to the standard client library, Xlib, and to the applications that want to use it.
Figure A shows schematically how colour specifications are processed with Xcms. Xcms effectively acts as a translator, changing device-independent colour specifications to RGB values to send to the server, and converting RGB values received from the server into the format required by the application.
In the next module we look at how Xcms takes account of the colour characteristics of the particular graphics hardware that your server is using.

Figure A. Xcms translates device-independent colour specifications on the client side.
3.6.2 Calibrating hardware for device-independent colour
The colour and illumination characteristics of the graphics hardware used by the server must be measured, and then stored so that Xcms can access them and take account of the way that your hardware renders colours.
To convert between device-independent and RGB specifications, we must first perform some measurements on the hardware, to find out what its colour and illumination characteristies are. For instance, the illumination from a screen does not increase linearly with RGB value; at low intensities, you need quite a large increase in RGB value to give a small increase in illumination, whereas at higher intensities this isn't so. Separate measurements have to be camed out for each of the red, green and blue components of the screen. All these characteristics are specific to each type of screen and graphics hardware. Figure A shows the characteristic curve of illumination versus RGB value for the red component of a screen similar to our own.
This process of measurement is called device calibration. The contrib release includes the program xCrtCa, to drive a CRT colour analyser so you can perform this function for yourself. (Very few organizations need to do this - tables of characteristics for particular combinations of graphics hardware and monitors are being made available. The contrib release already contains some of these in a form suitable for use by Xcms, and as Xcms is more widely adopted, hardware manufacturers will provide the necessary calibration information. )
Having got the device characteristics, we must make this information available to Xcms in a form it can understand; this is called device characterization. The colour profile of the screen is stored in two properties on the root window, XDCCC_LINEAR_RGB_CORRECTION and XDCCC_LINEAR_RGB_MATRICES. You load these properties from a file containing the characterization information using the MIT program xcmsdb. Applications using Xcms can now retrieve the characterization information from the properties when they require it, as shown in Figure B.

Figure A. How illumination intensity varies with RGB value on our screen

Figure B. How Xcms uses properties for device characterization.
3.6.3 Colour capabilities and colormaps
The number of colours you can display simultaneously on your screen is determined by your hardware, and is usually quite limited. If you have several applications running, they may require different sets of colours, which would exceed the hardware limit. To get over this, X provides `colormaps' - tables of the colours which are currently to be displayed by the hardware.
(If technical details aren 't so relevant to you, you can skip over this module.)
The most common colour systems are 8-bit. That is, each pixel is represented by an 8-bit value, which means that