Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!think!snorkelwacker!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: <8912122259.AA19575@kanga.lcs.mit.edu>
Date: 12 Dec 89 22:59:31 GMT
References: <13305@granite.BBN.COM>
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: X Consortium, MIT Laboratory for Computer Science
Lines: 43



	"Can be made arbitrarily smart..."  

    Are you talking about different font server implementations being able 
    to take some known set of input formats (which may differ from font server 
    to font server) and generate X-server compatible font information, in 
    which case you can only use input formats that are supported by your 
    font server vendor?  

Different font servers will probably be able to take any format that they
choose, with BDF as a required minimum.  Font vendors will undoubtedly supply
font servers that understand their scalable formats.  Your system supplier may
choose to OEM technology from the font vendor, or you as an end user might
license the font server directly.

One might then hope for a publicly available version that would understand
something like MetaFont or one of the many other scalable formats that the
trade press claims will be published soon.  Instead of pregenerating millions
of BDF files, the font server would simply rasterize on the fly (probably with
some sort of lru caching).


    Will the proposed font server allow an application to tell the server
    about new fonts while it's running?

I certainly would want my font server to be able to do this....


    (Actually, allowing applications to define new fonts at runtime seems like
     it's going to require a server extension no matter what...)

Depends on whether or not "at runtime" means redefining glyphs and metrics out
from underneath existing applications.  If you allow the font server to look
at font state only on initial open like the X server does (meaning that it
logically caches the font data so that changes in the data aren't reflected in
any subsequent queries), then there shouldn't be any problem.  Whenever a new
font is created, the X server could receive the equivalent of a
CatalogueChanged event instructing it to throw away any local notions of the
contents of the indicated current catalogue.

Anyway, enough back-of-the-envelop sketching,
Jim