I started perusing the fonts list archives this afternoon....
There seems to be some fundamental disconnect between people who like
server side fonts, and those who like client side fonts. The details of
STSF aren't germane until this more fundamental discussion takes place,
and that the first discussion should be at this level of architectural
abstraction.
I personally come down strongly on the client side font of the arguments
rather than any server side schemes, but there are some items worth some
discussion and measurement in this debate.
I used to believe in server side fonts, until about 18 months ago.
I hope the following discussion helps you all understand how I changed
my mind, and some of the issues that made the client side font argument
compelling to me, having been on the other side of the argument initially...
Large Scale Distributed Systems Deployment
==========================================
We have a large distributed system in the X environment: it is infeasible
to update all the (X) servers to support new font technology. I used to
think the X extension mechanism allowed a way out, but in fact, it is
only a partial way out; and particularly in large scale commercial systems,
you run applications remotely from the X server on the desktop.
This then implies that you can't deploy applications that depend on the
new technology unless/until the X server is updated, which may not
even be possible. If you want immediate deployment of applications
universally, you *MUST* be able to run on unmodified X servers.
This therefore implies that the client must be able to render anything
bit for bit identically to what the server would, if only to be
able to deploy.
Reality is that many older systems can never be updated with new extensions,
and that therefore any extensions can only be performance enhancers, if
you want universal deployment and widespread acceptance by software
developers. Application developers won't use something if it badly restricts
the market for their software.
The remaining arguement for server side fonts on a functionality side
seems to be to provide AA text to legacy binaries: I believe updating
the shared libraries (e.g. Xt, Xaw, Motif, etc) to support AA text
will be as simple a way to get AA text universal than updating the X server
for a new application.
I've been pummelling Keith for the last 18 months that Xft had to do client
side rendering, and Keith recently implemented client side rendering in
Xft, so that Xft will work against unmodified X servers, allowing quick
deployment and interoperability with the installed base of X servers;.
deploying render will just improve performance; the functionality is
universal, even when running over the net, maximizing the audience for
application developers.
Applications that will work (even if somewhat slowly) always trump
applications that won't run at all, from the point of view of an ISV
(who wants to sell product), or an open source developer who wants to
get their application out there.
Historical Observation about Opaque Server side fonts
=====================================================
Longevity of font formats
-------------------------
Over the history of X, with which I'm a bit familiar :-), we've
gone through 4 generations of font formats:
o 1983-1990
o Speedo 1991
o Type1 1992
o TrueType 1997
And OpenType is coming, number 5.
We've gone through 4 generations of font technology so far, and have a
fifth on the immediate horizon. It seems that every 5 years or so, there
is likely to be a new generation/format for font files, with increasing
quality (along some dimension, whether it be typographic, or character
set, or whatever).
As each new font technology has deployed, it has been necessary for
applications to access the new data contained in the font files for the
new information. So whatever system is used to distribute fonts needs
to allow applications to access this information (or there isn't any utility
to the new font format at all). Sufficient information must be available
for either X's use, or for printing use (something we ignored in the design
of the X protocol). So to be useful to applications on systems, any access
to fonts must be able to access *any* information in the font files, which
will continue to evolve.
File system based font sharing
------------------------------
You'll still have to provide access to font files to enable printing
applications (and agressive X applications) to access any information
not in any custom protocol one might build. No matter what you design,
you won't get it right: that is the way design is, and we know there will
be future font formats and layout algorithms. One has to design a
system in which your mistakes don't haunt you (as they have for the
last 15 years, though I didn't understand it). But server side fonts
have haunted us for almost 20 years, though I did not appreciate how badly
until relatively recently.
The core protocol design of hiding the font file format has been shown
by history to be fundamentally broken; all it has done is caused
configuration nightmares trying to get the font files accessable to both
the application and the X server, *since all non-trivial applications have
required access to the font files*. You can blame me partially for this
nightmare: it seemed like a good idea at the time. It is a good example
of where in the X protocol we tried to go too far, with unforseen results.
Alternatively, I think that a font sharing/adminstration scheme that is
network file system based, that can take advantage of the full file
sharing/authentication infrastructure, is likely a much easier to build
to get central adminstration of fonts, licensing, etc, than building a
custom protoocol. Applications can get the font information they want
and need, and leverage the full caching/replication protocol work going
on in network file system design.
This alternative I suspect is much simpler than a custom protocol, and
with modern caching/replicating distributed network file systems, likely
to be much faster way to distribute fonts to large customers (e.g. a site
license for a set of customer's custom fonts, to a world wide enterprise,
using any of a number of such file systems (AFS, Coda, Intermezzo, to name
a few)).
Text Layout
-----------
Similarly, believing that text layout can be similarly hidden seems also
to be wishful thinking: applications generally need to be aware of where
text is rendered (just think about highlighting selections, editors, etc),
so at best it client and server will be replicating the layout work, and
at worst, will get different answers, with the results you might imagine.
By the argument above, however, it must be possible to render both
on the client and server side, to:
o be able to deploy without requiring X server upgrade
o Support the next generation of fonts we don't know about
yet.
This implies either you try to have the same algorithms on both sides
of the wire, (which then will cause a similar deployment problem in the
next generation), or step back and only try to render the results remotely.
Xft does the latter, rather than the former.
Performance
===========
Typically, X performance is more limited by round trips than bandwidth.
By having fonts server side objects, either you can minimize round trips
at the expense of bandwidth by shipping the font metric information (and
by the previous argument, any ancillary information) to the client, or
reduce the bandwidth requirements by only accessing the data needed
when you need it, but that increases round trips.
Font files used to have of order 128 glyphs: these days, fonts of thousands
of glyphs are typical, so the overhead of the metrics have gone up at
least an order of magnitude over the life of X, for the fonts people
now actually want to use (e.g. the Microsoft TrueType core set).
Keith Packard's recent data is shows client side fonts using less bandwidth
than server side fonts (having already saved the round trips) by the fact
that the font information does not have to go over the wire (and all serious
applications need this information). And this is without tweaking on
XRender's protocol for further efficiency; just its current incarnation.
Only the glyphs actually rendered get sent, or even rasterized.
More data would be good of course, now that we have fully functioning
serious applications, and I've asked Keith to generate more of them (e.g.
using Mozilla or other serious applications with and without Render).
One argument I've seen which strikes me as worth serious further
investigation is what the bandwidth usage will be as screen resolutions
increase: one comment claimed this will go up as N^2'ed, but similarity
between lines means that even trivial compression algorithms will make
that no more than linear with resolution, and in fact, given most parts
of glyphs will have the same color, it should be sublinear (remember,
once we're above 200-300DPI or so, we're better off without AA and subpixel
rendering games.
Therefore another piece of performance data we should gather on client
side fonts is how well glyphs compress, so we can forsee bandwidth usage
scaling as screen resolution increases over the next few years. I suspect
a fair way to gather such preliminary data is to take a page of text,
render at various resolutions, and see where GZIP compression gets us;
plot this and we'll get an upper bound on the function of bits on the
wire of client side fonts versus server side fonts as the resolution
increases. It will be sublinear with resolution, but how sublinear is
worth finding out. I say upper bound, as that cleverness might improve
things further beyond gzip. Above 200-300dpi (whatever the golden number
is believed to be), the rendering should not be AA or subpixel decimated.
Maybe a freetype person would like to do the experiment? And then we
can have a more rational discussion of the tradeoffs of client side
versus server side fonts on performance grounds.
Conclusions
===========
I do argue, that the architectural issues outlined in the first couple
section are in fact more essential/compelling than the performance issues,
however. Experience has shown server side fonts to be a bad mistake,
and we should only really investigate if there are any lurking performance
traps in client side fonts now that we have running code in truly serious
applications, and if there are, how to mitigate them.
To date, all experience is that server side fonts have never provided
what serious application and toolkit developers actually need; I see no
reason in the discussion to date to believe they will in the future. But
I could be wrong: lets take the discussion up to this level of abstraction
rather than down at the API level of abstraction.
- Jim Gettys
--
Jim Gettys
Cambridge Research Laboratory
Compaq Computer Corporation
[EMAIL PROTECTED]
_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
