Path: utzoo!attcan!uunet!husc6!bloom-beacon!home.csc.ti.COM!ekberg From: ekberg@home.csc.ti.COM (Tom Ekberg) Newsgroups: comp.windows.x Subject: strange thing from XLoadQueryFont Message-ID: <8808171657.AA01182@home> Date: 17 Aug 88 16:57:08 GMT References: <8808171221.AA00462@LYRE.MIT.EDU> Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 44 It's time for me to get up on my soapbox on this one. From: Ralph R. Swick>> 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