bzs@BU-CS.BU.EDU (Barry Shein) (12/28/87)
Ok, why are font names in the 4.2 server forced to mono-case (lower)? It's in the os/4.2bsd directory stuff. I can't find it documented anywhere (that's not a flame, that's a hint that perhaps the behavior can be just as silently elided.) There are font sets (eg. Troff oriented stuff) which distinguish lower/upper case font names and there's some convenience in being able to store them as such in the file names (particularly when doing otherwise would cause file name clashes, which is the case I just ran into.) Not a big deal, life goes on, but it seems unnecessary, particularly when it's been drawn out into the OS dependant stuff anyhow (so portability arguments are basically irrelevant, so are KSR-33s.) -Barry Shein, Boston University
karlton@decwrl.dec.com (Philip Karlton) (12/29/87)
In article <8712280138.AA18937@bu-cs.bu.edu> bzs@BU-CS.BU.EDU (Barry Shein) writes: > >Ok, why are font names in the 4.2 server forced to mono-case (lower)? >It's in the os/4.2bsd directory stuff. I can't find it documented >anywhere (that's not a flame, that's a hint that perhaps the behavior >can be just as silently elided.) > From the protocol spec on OpenFont: Loads the specified font, if necessary, and associates identifier fid with it. The font name should use the ISO Latin-1 encoding, and upper/lower case does not matter. This implies that the client should get the same font independent of asking for "fixed", "FIXED", "Fixed", or even "FiXeD" have to get the same font. The sample server implementors chose to implement this by storing all of the compiled fonts in lower case only names and smashing the requests to lower case so that the directory lookup would succeed. Any other scheme that preserves the protocol semantics is fine. For instance, enumerating all the directories on the font path and building an internal cache of the font names would work. PK