Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!purdue!bu-cs!bloom-beacon!EXPO.LCS.MIT.EDU!jim
From: jim@EXPO.LCS.MIT.EDU (Jim Fulton)
Newsgroups: comp.windows.x
Subject: Re: Banish 'font not found' errors forever!
Message-ID: <8912121426.AA17018@kanga.lcs.mit.edu>
Date: 12 Dec 89 14:26:08 GMT
References: <6808@b11.ingr.com>
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: X Consortium, MIT Laboratory for Computer Science
Lines: 80


    Does this mean that the Consortium realizes there is no good, existing
    workaround to the problems I've mentioned?

To quibble a bit, "good" depends on your point of view.  Aesthetically, I think
the current situation sucks.  Practically, though, it is at least manageable.
The problems are most acute on X terminals and PC's and most of those vendors
are already supplying a variety of ways of coping with the problem.  Yes, it
isn't pretty, it isn't easy, and it needs a better answer.


    When will it be available?

Who knows.  Realistically, I would assume that various vendors would start
shipping it as soon as it became a Consortium standard.  But like all 
Consortium standards, that process does take a little while.  If you are
in dire straights, definitely talk to you vendor.  There is nothing that
prevents them from adding such an extension.


    This method of telling the X server about the font server will be
    vulnerable to server resets.

As usual, your base fonts would be configured initially by the server and 
then by your session manager.  I certainly wouldn't want to type a bunch of
xset fp's every time I login either.

    >It is extremely frustrating to our users when, after successfully
    >installing and running an application on one machine, it fails when they
    >run it remotely.  We agree with them - it is cumbersome to have to
    >install the application's fonts on every server machine.

Then fix your servers to do a private font service, use NFS to provide a
common font area, or code your extension.  No one was trying to inhibit your
ideas, just to let you know the direction in which we'd like to go.


    The user must know ahead of time which machines will act as
    font servers

Unclear.  There are a variety of techniques for locating services in a
network.  Preconfiguring is one; broadcasting for service is another.  The
XDMCP specification provides a good illustration of how this can be dealt with.


    The sendfont extension allows clients to
    propogate fonts on demand with no intervention by the user.

Granted, and you might well decide to put it into your server.  Given how
close we are to the end of "this yearish", you can guess how tightly the R4
server is locked down.  


    Also, applications may want to create fonts on the fly.  Can you do this
    using the font server?

Sure.  Off the top of my head, I can see several different approaches: 

1.  Perhaps SendFont could work in the font server context.  But, then 
    that has some of the same problems as having the extension in the 
    server (e.g. do you allow partial downloading of fonts [something
    that is imperative for large fonts], what sort of authorization
    policies would you want, etc.).  

2.  I think that a better solution would be for the application to spin
    off its own font server and tell it when it has a new font
    (through a signal, font server control protocol, etc.).

Again, this is all just brainstorming.


    We would like to have some kind of support from the Consortium for the
    sendfont idea.  What avenues of cooperation are open?

The best thing would be for you to join the Consortium (any organization is
both welcome and encouraged to join).  Then you could propose the extension
directly.  Given the enthusiasm that you clearly have for this, I really hope
that you do join.

							Jim