Xorg and Fonts

[Keith Packard]

On Tue, 2005-08-30 at 12:52 +1000, Russell Shaw wrote:

> The proponents of client-side fonts gave no valid reason for disregarding
> server-side fonts (they gave valid reasons why stsf might be a problem, and
> that the current X fonts protocol doesn't deliver enough information).
> They simply stick to exclusive client-side fonts because "most" users have
> an account on the client machine, and so their fonts are accessible to the
> client.

Actually, I wrote several papers on this topic and presented them at
numerous Unix and Linux conferences. I think we're trodding well covered
ground here. Check out most of the papers at
http://keithp.com/~keithp/talks 

The key motivators are:

 1)	Client side fonts must be supported for application-provided fonts,
such as those embedded in PDF files

 2)	Server side fonts require numerous round trips to discover, select
and use them

 3)	Applications need complete access to font files, and the bulk
of the information is not relevant to drawing.

 4)	We're currently on the cusp of transition to "real" layout
systems where even more font information is required, and the exact
format and content are highly fluid.

 5)	The existing server-side font mechanism is completely inadequate

 6)	Mistakes in client-side code can be fixed by shipping new code with
applications (if necessary), while mistakes in server-side code require
upgraded server and permanent kludges to deal with older code.

Early estimates showed that total network traffic was a wash for Latin-1
fonts; server-side fonts must transmit all glyph metrics to the client
before any text drawing is done while client-side fonts must transmit
all used glyph images before drawing is done. Because client-side fonts
need only transmit the images actually used, this becomes even more
relevant when you start talking about larger fonts with significant
Unicode coverage. The current X.org distribution makes this case for us
as it automatically sub-sets all Unicode encoded fonts to limit the
impact of those on wire traffic.

> This doesn't solve the problem of not being able to use your own fonts when
> the client is running on a remote machine you have no unix shell account on.

True enough. Conversely, server-side fonts eliminate the ability to use
application-specific fonts automatically, which was a far worse problem
in times past. In this case, you have applications failing to work,
while in the server-side case, you have limited user configurability
with working applications. I know which I'd rather support...

In both cases, you need suitable configuration changes to make things
work. Providing a virtual file system mechanism for applications to load
fonts via a network protocol (like, say, http) is something we can add
to the existing environment without requiring any new protocol additions
or in fact any significant changes in applications.

If you find this a significant limitation, please feel free to
contribute code in this area.

> If the client is internationalized, the client machine might need a few
> megabytes of font files for every language.

Precisely why client-side fonts are a huge win -- the X server will not
end up holding all of these glyphs in memory at once, rather the client
will cache a recently used subset of them, limiting memory usage in both
the client and X server. With server-side fonts, the server always holds
all of the glyphs and metrics while the client always holds all of the
metrics. Client-side fonts permit client-controlled caching of metrics
and images on both sides of the wire.

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20050830/b481119e/attachment.pgp>