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