Xorg and Fonts

[Russell Shaw]

James Cloos wrote:
>>>>>>"Russell" == Russell Shaw <rjshaw at netspace.net.au> writes:
> 
> Russell> Lazy toolkit writers have been going to client-side fonts
> Russell> just to avoid 16-bit X protocol problems instead of fixing
> Russell> it.
> 
> There is no fix other than yet another X extension.  And that requires
> new client libraries.
> 
> And using client side fonts is not lazy, but in every way an
> improvement over server-side fonts.  This was debated back when Xft
> was started, and the consensus clearly favoured a wholesale movment
> to client-side fonts.  Check the xfree86 list archives for most of
> that discussion.
> 
> And if you have an actual need for server-side, use (or improve) Sun's
> stsf project.  It is a good choice for the environment they designed
> it for, and may work as well in some other applications.
> 
> -JimC

Hi,
I read a large amount of list archive about the merits of client-side
fonts and stsf.

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.

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.

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

A hypothetical example would be an online database that is across the
country or international. Normally, you'd make a web interface for it
using php or java on the web server. As everyone knows, there's a
significant time lag when interacting with web interfaces due to
having to download complete pages of html, unless you put more
interactive stuff on the users end with javascript in the browser.

You could instead make an X interface. The X events going back and
forth should be much lower bandwidth than transferring pages of html,
and the user interface would have finer grained interactivity, almost
like running the same X client on your own pc. However, you couldn't
customize fonts unless they were X server-side accessible.

The argument for client-side fonts is that you need quick access to
font metrics. What i'd do is keep only default fonts on the client
side and do everything as is already done now with Xrender calculating
string sizes from the metrics. If the user has their own fonts available,
they can run a simple gui that allows them to select from a list of fonts
on their system, then click the root window or top-level window of their
application to set a "default font" property. A "property changed" event
will be sent to the clients, so they can upload the new font metrics
from the X server.

stsf does it's own font rendering on the X server side, and any precise
font dimensions need to be queried by the client, increasing round-trip
delay problems.

I'm not sure if the facility to upload a large font metrics file from
the X server to the client is currently available. Maybe it's just a
matter of setting the contents of a "default_font" property to be the
metrics file contents itself.