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