Documentation?

[Jim Gettys]

On Thu, 2009-04-09 at 16:01 +0200, Olivier Galibert wrote:
> On Thu, Apr 09, 2009 at 09:31:01AM -0400, Jim Gettys wrote:
> > If you look at our paper here:
> > 
> > http://keithp.com/~keithp/talks/usenix2003/
> > 
> > You'll discover that the font metadata turned out to be as large as
> > the glyphs actually used.
> > 
> > And client side fonts with server caching therefore turns out to be a
> > wash as far as bits transferred in practice, while avoiding a huge
> > number of round trips to get font metadata (which was always
> > inadequate), and *horrible* for application performance at starup.
> 
> At least in theory you do not need more than one round trip per used
> font to get font metadata.  Bulk-sending the list of supported
> characters and associated metrics in one message for caching in the
> client makes sense.  Sending the list of existing fonts is costly but
> otoh "fc-list :"'s result is 20 times smaller than "xlsfonts"'s.

The problem is you need the font meta-data to do decent font (set)
selection.

So you get to enumerate all the fonts.

If your only mechanism is to retrieve the fonts remotely, and you have
hundreds or thousands of fonts, you *die*.

When we were designing X11, this didn't happen, and the font coverage
was typically of order 100 glyphs, so it wasn't a problem.

It became a problem over the subsequent 15 years.

Having this database local (the fontconfig information) allows font set
selection to be local and fast.

> 
> 
> > So the X11 core font design is fundamentally a mistake, which we fixed.
> 
> Someday somehow I'll try to do some tests to check whether that's
> really true with a better optimized protocol, because right now
> everything that uses xft over a ssh tunnel is an horrible pain in the
> ass, 

I don't know what problem you are seeing.

Over ssh in particular, with compression (-C), performance is much, much
better with client side fonts than it ever was with server side fonts.

> while stuck-in-the-past applications like xemacs are way, way
> more responsive.
> 

The other motivation for client side fonts is an evolutionary argument:
 o we had seen 5 generations of font formats, and X was still stuck on
the first.
 o If you have to deploy a new server before you get the benefit of the
new font technology, you're likely stuck as we were for years, and that
means that new applications depending on those improvements in
technology never get built and deployed....
                      - Jim

-- 
Jim Gettys <jg at freedesktop.org>