jim@ncd.COM (Jim Fulton) (10/08/90)
For instance, requiring that a database of all potential font servers be maintained wouldn't not be nice. A dynamic mechanism where the application simply registers itself as a font server would be much nicer. A font server is essentially equivalent to a font directory in that it will be an element of the X FontPath. In environments with name services (e.g. Hesiod, among others), font services could be named (well-known ones are easy; dynamic ones are also easy if the the name server supports dynamic updates itself). At worst, one could imagine a host:port syntax for naming font servers that wouldn't require name service.
jim@ncd.COM (Jim Fulton) (10/10/90)
However, even the "font server" needs to load the fonts into the X server,
(I don't think that a font server creating a .bdf file somewhere,
executing vendor-specific .bdf->server-format converter, munging servers
font search path ... is a viable solution).
Like X, the font server will be a network protocol. X servers will connect to
it and request font information (properties, glyphs, etc.). Yes, this means
that vendors will have to upgrade their servers, but it will buy them quite a
lot: simpler administration, greater interoperability, faster integration of
new font sources.