	Fonts in WinCenter Pro

	Creating an Application Specific Font Server

	Keith Packard

+++ Text Rendering in WinCenter Pro

WinCenter Pro draws NT text using dynamically generated NT fonts. it
could render them using the core X protocol in several ways:

+	Strike format bitmaps. A set of glyphs text are drawn into a
client-side bitmap and displayed using PutImage.

+	Client side scan conversion. Each glyph is converted into a
collection of rectangles and rendered using PolyFillRectangle.

+	Match existing X fonts. The closest available X font is
substituted for the application font and then drawn with PolyText or
ImageText requests.

Rasterizing text on the client side consumes client CPU cycles, generates a
large amount of X protocol and takes more server time than using X text
requests.  Using existing X fonts to attempt to match the application fonts
produces inexact results.  These mechanisms were not acceptable for
WinCenter Pro.

X servers can load fonts from files; either over the network using NFS or
TFTP, or directly from a local disk.  An application can generate font
files+ 
to disk and make them available to the X server.  Most X servers load a
static mapping between font names and font files each time the font path is
reset.  This operation is too time consuming to dynamically update a font
path's contents The X Font Service Protocol (XFS) [Fulton92] provides
another mechanism for suppling fonts to the X server. X servers access fonts
using a network protocol which mirrors the X protocol font requests.  XFS
permits font servers to change which fonts are available without notifying
the X server, adding or removing fonts at will.

WinCenter Pro converts NT fonts into X fonts and provide them to the X
server using the X Font Service Protocol.  Because XFS allows the list
of fonts provided by the font server to change, the application can
actually dynamically generate fonts and serve only those that it needs
at any point.  This allows WinCenter Pro to use real NT fonts and yet
render them using efficient X protocol requests.

X Font Service Protocol Overview

The X Font Service Protocol is designed to completely replace the file
based font mechanism for providing fonts to an X server. The protocol
focuses on providing precisely what the X server needs; support for
outline fonts or rotated baseline fonts is not included in the core
XFS protocol. The XFS protocol mirrors each X protocol request into
one or more X font service protocol requests:

+	X OpenFont generates XFS OpenBitmapFont, QueryBitmapFont,
LoadBitmaps. This is broken into pieces to allow the X server to cache
pieces of each font and load them only when needed.

+	X ListFonts generates XFS ListFonts.

+	X ListFontsWithInfo generates XFS ListFontsWithXInfo.

Each X client is identified to the font server to allow per-client
access control to fonts; the X server creates an "access context"
for each client. The X server selects this access context each time it
uses the font server on behalf of the client.

A font server is allowed to subset its collection of fonts into
"catalogues". Part of the standard X font path entry identifying
the font server is a list of catalogues to use.  The "all"
catalogue is required to exist.

Fonts in WinCenter Pro

WinCenter Pro supplies an NT display driver which generates X protocol
for all NT rendering functions. For text rendering, NT provides the
display driver with the entire font. NT fonts aren't provided with
any particular encoding, text in many encodings may be drawn with the
same font. WinCenter Pro creates X fonts which contain all of the
glyphs in the font in no particular order.  As the font doesn't
follow any standard X encoding, it is important that other X
applications not accidentally use WinCenter Pro fonts.

WinCenter Pro Font Names

The X protocol doesn't allow for client-specific font path entries;
fonts available to one client are available to all.  WinCenter Pro
avoids potential problems by choosing unique font names:

	NCD-<IP address>-<Session ID>-<Font ID>

Each session on a host gets a unique session ID, each font in that
session gets a unique font ID.  This naming scheme prevents other X
applications, and other WinCenter Pro sessions from accidentally using
the wrong font.

X Font Service Protocol for WinCenter Pro

WinCenter Pro provides a very different font server from the usual X
font server, while it complies with the requirments in the standard,
it reduces the implementation to the bare bones.

Unneeded X Font Service Protocol Functionality

There is no way for applications to request fonts which aren't
being used by a licensed NT application so WinCenter Pro does not need
to restrict access to the generated fonts.

To more effectively hide its fonts from other applications, WinCenter
Pro always returns an empty list from ListFonts and
ListFontsWithXInfo. This is allowed as the list of fonts visible to
any font client is permitted to change at any time. As an X client,
WinCenter Pro already knows the names of all fonts provided by its
font server.

WinCenter Pro always provides complete font names to the X server,
which echos them into the font server.  This eliminates the need to
provide wild card matching.  WinCenter Pro font names are not XLFD
compliant. Matching font names is done by considering only names
appearing in the correct format, with the correct IP address,
extracting the session and font ID values and doing numerical
comparisons with the available fonts.

These simplications reduce the complexity of the WinCenter Pro font
server.

Serving NT Fonts From WinCenter Pro

The display driver is presented fonts at the time a new string is
rendered. When a new font is presented, WinCenter Pro converts the
entire font into an X compatible format.  The X compatible font is
placed in a shared memory segment and passed from the display driver
into a separate font server process.

Why create application specific font server

	Text rendering fastest using X text requests

	Existing X fonts don't match NT fonts

	NT fonts dynamically scaled, can't create X font files

	XFS only standard way to dynamically download new fonts

What needs to be done

	Create application specific font names

	Analyse XFS

		Limited functionality required

			No ListFonts/ListFontsWithXInfo

			A single catalogue

			No access control

			Single format for names

	Move fonts from application to font server

	Attempt to add/remove FP entry at the right time



How it was done

	Separate font server process

	One thread per font client

	Shared memory segment per font

	RPC commication with application 

	One thread as RPC server

	Count client connections



Problems encountered

	X Server caching of fonts/font server connections

		Solved by creating separate font server process

	Nagel algorithm and current X server code

		OpenBitmapFont code does multiple sends

		Nagel algorithm causes delay

		Solved by generating KeepAlive events

		Shound be fixed in X server

	Attempting to track connections from X servers

		Tried to track by IP address

		Proxies foiled that (xscope, LBX, Xremote)



How it worked
