Path: utzoo!attcan!uunet!husc6!uwvax!gjetost!solomon
From: solomon@gjetost.cs.wisc.edu (Marvin Solomon)
Newsgroups: comp.windows.x
Subject: Re: strange thing from XLoadQueryFont
Message-ID: <6155@spool.cs.wisc.edu>
Date: 19 Aug 88 12:56:27 GMT
References: <1500@daisy.UUCP> <8808171221.AA00462@LYRE.MIT.EDU>
Sender: news@spool.cs.wisc.edu
Reply-To: solomon@gjetost.cs.wisc.edu (Marvin Solomon)
Organization: U of Wisconsin CS Dept
Lines: 29

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