turner@daisy.UUCP (D'arc Angel) (08/17/88)
I am running X11R2 on a sun 386i under SunOS 4.0, I have the game xconq
on an NFS mounted directory (a Sun 4). I set the path in .Xdefaults to
be
xconq.IconFont: /misc/Xconq5/lib/xconq.snf
(/misc is the NFS mounted directory)
and xconq says that it can not open the font. Hmmm says I, what about xfd ?
same story. So I moved the fonts to /tmp, shazam it works for both xconq
and xfd. Anyone have any ideas why XLoadQueryFont can't open an nfs file?
The permissions were all correct (I believe that I have checked all of the
obvious problems)
--
Can this wait until after I've had my coffee ???
...{decwrl|ucbvax}!imagen!atari!daisy!turner (James M. Turner)
Daisy Systems, 700 E. Middlefield Rd, P.O. Box 7006,
Mountain View CA 94039-7006. (415)960-0123swick@ATHENA.MIT.EDU (Ralph R. Swick) (08/17/88)
> xconq.IconFont: /misc/Xconq5/lib/xconq.snf
[didn't work, where /tmp/xconq.snf did]
This is sort-of brain damage in the X11R2 implementation of OpenFont.
Turns out it lowercased the entire string, not just the final
component, before looking up the file. This was in order to match
the protocol requirement that "case does not matter [in a font name]".dana@dino.bellcore.com (Dana A. Chee) (08/17/88)
In article <1500@daisy.UUCP> turner@daisy.UUCP (D'arc Angel) writes:
I am running X11R2 on a sun 386i under SunOS 4.0, I have the game xconq
on an NFS mounted directory (a Sun 4). I set the path in .Xdefaults to
be
xconq.IconFont: /misc/Xconq5/lib/xconq.snf
(/misc is the NFS mounted directory)
and xconq says that it can not open the font. Hmmm says I, what about xfd ?
same story. So I moved the fonts to /tmp, shazam it works for both xconq
and xfd. Anyone have any ideas why XLoadQueryFont can't open an nfs file?
The permissions were all correct (I believe that I have checked all of the
obvious problems)
--
Can this wait until after I've had my coffee ???
...{decwrl|ucbvax}!imagen!atari!daisy!turner (James M. Turner)
Daisy Systems, 700 E. Middlefield Rd, P.O. Box 7006,
Mountain View CA 94039-7006. (415)960-0123
Sure do. The OS code for opening a font converts the font name to
lower case. But it doesn't take into account that the entire path
shouldn't be converted. So the file it tries to open is
/misc/xconq5/lib/xconq.snf with the X of Xconq5 changed to x. A fix
we used to get around the problem here is in
~X/server/os/4.2bsd/filenames.c function TryToExpandFontName().
/*
* reduce to lower case only
*/
for ( in=lenfname-1; in>= 0 && lowername[in] != '/'; in--)
if ( isupper( lowername[in]))
lowername[in] = tolower( lowername[in]);
Hope this helps.
--
+*************************************************************************+
* Dana Chee (201) 829-4488 *
* Bellcore *
* Room 2Q-250 *
* 445 South Street ARPA: dana@bellcore.com *
* Morristown, NJ 07960-1910 UUCP: {gateways}!bellcore!dana *
+*************************************************************************+ekberg@home.csc.ti.COM (Tom Ekberg) (08/17/88)
It's time for me to get up on my soapbox on this one. From: Ralph R. Swick <swick@athena.mit.edu> >> xconq.IconFont: /misc/Xconq5/lib/xconq.snf > [didn't work, where /tmp/xconq.snf did] >This is sort-of brain damage in the X11R2 implementation of OpenFont. >Turns out it lowercased the entire string, not just the final >component, before looking up the file. This was in order to match >the protocol requirement that "case does not matter [in a font name]". I agree with you that the implementation of OpenFont is "sort-of brain damage"d, but not in the way you suggest. I think that putting a directory name in a font string is brain damaged. Neither the Xlib documentation (Release 1, page 102ff) nor the protocol specification (Release 2, page 40, OpenFont, and pages 44-45, ListFonts and ListFontsWithInfo) indicate that the string argument for a font can contain a directory component. The purpose of SetFontPath and GetFontPath make putting a directory name in a font string for OpenFont, ListFonts and ListFontsWithInfo unnecessary. There are 2 reasons why I think putting a directory name in a font string is brain damaged. (1) It takes advantage of a hidden feature that is not defined anywhere except the code, and (2) more importantly, a '/' character which works fine for Unix, but doesn't work for many other file systems. There are servers out there that are not based upon Unix and will have trouble with an OpenFont request which contains parts of a Unix based filename. The search path for a Unix based server may even point to a file server that is not Unix based (can you say VMS?). Page 45 (SetFontPath) of the protocol specification indicates the search path is operating system dependent, but that servers will have a default search path. For non-Unix based servers, this default search path will most likely contain a non-Unix search path. Putting a '/' character as part of a font name will most likely cause the entire font name to be treated as a name component of the filename with the directory component coming from the search path. My main point for bringing this up is that the X Window System is intended to be operating system independent but this is a case where applications are using code that is dependent upon a particular operating system. -- tom (aisle C-4L), ekberg@csc.ti.com
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (08/18/88)
Date: Wed, 17 Aug 88 11:57:08 CDT
From: Tom Ekberg <ekberg@home.csc.ti.com>
I think that putting a directory
name in a font string is brain damaged.
Absolutely. This "feature" has been removed from the server code we
presently expect to ship in R3, as a side-effect of redesign to make
font names completely independent of file names.solomon@gjetost.cs.wisc.edu (Marvin Solomon) (08/19/88)
In article <8808171221.AA00462@LYRE.MIT.EDU> swick@ATHENA.MIT.EDU (Ralph R. Swick) writes: >> xconq.IconFont: /misc/Xconq5/lib/xconq.snf > > [didn't work, where /tmp/xconq.snf did] > >This is sort-of brain damage in the X11R2 implementation of OpenFont. >Turns out it lowercased the entire string, not just the final >component, before looking up the file. This was in order to match >the protocol requirement that "case does not matter [in a font name]". Not only should it not lowercase the entire path name, it shouldn't lowercase the final component either. I also had problems with fonts being "invisible" to OpenFont until I discovered that any font whose file name has uppercase letters is inaccessible. The document says that case doesn't matter, but the implementation says "case doesn't matter--so long as it's lower case". What's the solution? Get a listing of the entire directory, translate all the names there to lower case (saving an untranslated copy of each), compare against a translated copy of the font name, find a matching file name, and open the file using the untranslated copy of its name. Sounds pretty painful to me. An alternative is to leave the code as it is (except for the indicated fix to translate only the last component), but put warnings in all the appropriate places to the effect of, "if your operating system distinguishes case in file names, all font file names must be entirely in lower case". Marvin Solomon Computer Sciences Department University of Wisconsin, Madison WI solomon@cs.wisc.edu ...seismo!uwvax!solomon
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (08/19/88)
Date: 19 Aug 88 12:56:27 GMT
From: gjetost!solomon@speedy.cs.wisc.edu (Marvin Solomon)
The document says that case doesn't matter, but the
implementation says "case doesn't matter--so long as it's lower case".
What's the solution?
The solution is to make the font names independent of the file names,
and to outlaw passing file names. This will be the case in R3.