Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!bu-cs!buengc!bph
From: bph@buengc.BU.EDU (Blair P. Houghton)
Newsgroups: comp.windows.x
Subject: Bug or what: Cannot open font file /usr/lib/dwf/75dpi/courier_bold14.dwf
Message-ID: <4427@buengc.BU.EDU>
Date: 3 Oct 89 23:11:16 GMT
Reply-To: bph@buengc.bu.edu (Blair P. Houghton)
Followup-To: comp.windows.x
Organization: Boston Univ. Col. of Eng.
Lines: 38

Using default setups, having changed nothing on the server or in
any of the X applications recently, we now get the following for
some applications:

    Cannot open font file <*>

Where <*> is any of a number of perfectly available, previously
usable fonts.  Nothing has changed, but suddenly nothing works.

These error messages are dumped by the kilobyte into the X0msgs file in
.../adm.  It gets huge in a short period of time.  Something in the
server (is it in the server or in the application?  I don't know, and I
can't tell from looking.[1]) is writing the message for several different
fonts that the application requests, and then seems to go into an
infinite loop on one of them.

There is nothing wrong with the fonts.  I can get them to come
on-screen using xfd, but not with the offensive applications.

Munging the font paths has nothing to do with it.

Everyone has read _and_ execute permission on the font files.
The only way it could really fail to open them is if it wanted
to write to them as well...

This only happens to some users, and only on certain machines,
and started happening only recently.

If it's a difference in the resources or in the environment, we
can't identify a keyword that could be the culprit.

The hardware is a uVAX II/GPX, the system is Ultrix 3.1, UWS 2.1,
and the program doing the wrong thing is vem.

				--Blair
				  "You coulda guessed that last part."

[1] Why would a client be writing into the server's log file??