Xorg and Fonts

[Russell Shaw]

Keith Packard wrote:
> 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

I've read those previously.

> The key motivators are:
> 
>  1)	Client side fonts must be supported for application-provided fonts,
> such as those embedded in PDF files

I've agreed that client side fonts should be supported the same as now
for those reasons, but that server-side font upload capability should be
added. The client still gets these fonts and operates on them as if they
were local. When the user logs off, they can be cached or discarded.

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

Only if the user wants to use their own font. If the user doesn't like
the delay of a slow upload, they can just use the default font on the
client machine.

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

I'm still figuring out what would be involved in a canonical font format.

>  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.

I'm thinking of experimenting on my own copy of xc. It will be figured
out one day what constitutes "complete" data for a font.

>  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.

If the server is being re-architected, it's time to put everything into
it and experiment for a while. Users that don't want old apps could even
use a stripped down more modern server.

> 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.

The proposal is that all font calculations are done after uploading
all the font data into the client local ram or hard-disk.

>>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...

The proposal is to have default and special fonts on the client only,
instead of every possible font to try and anticipate what all users
would want. If a new font comes out, the user may not have access to
the client machine.

> 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.

I will, but probably on my own copy for a while.

>>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.

The proposed upload procedure transfers both metrics and glyphs in a
canonical format. So when i say "server-side" i mean server-side upload
to the client.