Xorg and Fonts

[James Cloos]

>>>>> "Russell" == Russell Shaw <rjshaw at netspace.net.au> writes:

Russell> The proponents of client-side fonts gave no valid reason for
Russell> disregarding server-side fonts

There were valid reasons given.  The clients need access to most if
not all of the data in a modern font anyway, so the server would have
to provide access to all of those tables.  And there are several
competing standards for what tables to put in sfnt fonts, regardless
of whether the actual glyphs are in glyf or cff tables.  Or, if the
server were to handle all of the complex typesetting, every time a
glyph or string of glyphs is set it would have to send a copy of the
resulting pixmap back to the client so that the client could know what
is there.  It is much easier to update a library or two on the client
side than to get new X servers installed.  A change in server-side
fonts requires a new X extension, and you've seen by how long it took
to fully support the RENDER extension how hard that is.  And if you
can install software you can install fonts, too.

In the cases where there is a desire to have only a single  physical
store for some fonts, network filesystems can server those to the X
client apps.

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

How do you run such an app?  How do you manage it?  

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

A few megs per language is a gross exaggeration for UI fonts.  Only
fine typesetting -- with a wide variety of font weights, widths and
optical sizes -- could need that much.  A few megs total, for all
current scripts is more realistic.  And not out of line with the sizes
of apps these days.  And a fully internationalized app will need to
deal with some *very* complex scripts.

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

I agree that a web app is not the best solution.  But I disagree that
X11 is the right protocol.  I'd write a GUI targetting something like
pyGTK/pycairo (python bindings to GTK and cairo) and use a mroe
customized stream protocol between the app-server and the app-client
(the latter then also being an x-client).  Ideally the protocol would
be the DB's (secured) protocol, but if a barrier is required between
the client and the SQL something simple using BEEP (rfc 3080) would be
reasonable.  (Perhaps using XML-RPC over BEEP, as in rfc 3529).  

Russell> The argument for client-side fonts is that you need quick
Russell> access to font metrics.

It isn't just metrics.  It is /all/ of the information.  The various
sfnt tables (OpenType, AAT, Graphite, proposed X11 and TeX tables,
and various proprietary tables all exist and are relevant to
converting from character strings to rendered glyphs.  And both sides
need to know the results of alpha blending et al.  

Russell> I'm not sure if the facility to upload a large font metrics
Russell> file from the X server to the client is currently
Russell> available.

OK.  You just gave me an idea.  In general it is better for the apps
to get access to the fonts via the filesystem, whether a local fs or
a network fs.  But you /could/ embed an entire font in a root-window
property.  The client would need to know to look for such a font, to
grab it into its own VM, and to be able to use a font that is in mem
rather than in a file.  It would not require an X extension; a local
app (gui or cli) can provide a means to store the file(s) and client
apps can easy grab such properties to local storage.  

The apps to store the files will be easy to write.  

Convincing toolkits to support it will be as hard as convincing them
to support a new X extension.  Perhaps a patch for fontconfig that
looks for such fonts in addition to those found via the primary
fonts.conf would be reasonable.

I don't know what limits exist on how large the value of a window
property can be; such limits may make this impossible....

-JimC
-- 
James H. Cloos, Jr. <cloos at jhcloos.com>