Conference bulova::decw_jan-89_to_nov-90

    
    Has the server restarted since you placed the files in the decw$font
    directory?

By "server restarted" do you mean a full reboot? No.  Is that necessary???
The description in some of the other notes about adding fonts (re Ultrix)
described editing a directory structure.  Is there no "online" method
for adding additional fonts?

					/Brad

    I think you'll have to do an @SYS$MANAGER:DECW$STARTUP "RESTART" from
    an attached terminal or reboot....

Still no go, after trying the suggestion in .3.  I've looked
at the DECW$SERVER startup procedures, and everything is being
defined correctly.  I examined "DECW$SERVER0_TABLE" and everything
is correct.  The server will not add the new files to its font tables!!

The files are both .SNF and .DECW$FONT.  Can anyone suggest something to
tell the server that I have new font files??

					/Brad

    A server restart on VMS should have automatically found your new
    font files. What directory are you putting them in?

The file are in SYS$COMMON:[SYSFONT.DECW.USER_75DPI].

$ dir sys$common:[sysfont.decw.user_75dpi]

Directory SYS$COMMON:[SYSFONT.DECW.USER_75DPI]

STANDARD.DECW$FONTS;1                   STANDARD.SNF;1      

Total of 2 files.

Is there someother naming convention used??  Should I QAR this?

				/Brad

    
    How about getting a full list of the fonts the server knows about.  The
    following program, xlf, can be used to list the font names.  Define
    decw$display to point to the server and run the program.  If you define
    a foreign command, it will take a font pattern as the first argument.
    
    					Monty

#include    <stdio.h>
#include    <decw$include/X.h>
#include    <decw$include/Xlib.h>

main( int argc, char *argv[] )
{

    char    line[80],
	    **extNames,
	    *extName;
    int	    i,
	    majorOpcode,
	    firstEvent,
	    firstError,
	    numNames;
    Display *dsp;


    printf("\n\n\t\tX List Fonts\n\n" );
    if ( (dsp = XOpenDisplay( (char *) NULL ) ) == (Display *) NULL ) {
	printf( "[Can't open display]\n" );
	exit();
    }

	if ( (extNames = XListFonts( dsp,
				     (argc>1?argv[1]:"*"),
				     (argc>2?atoi(argv[2]):10000),
				     &numNames ) ) == (char **) NULL ) {
	    printf( "[No fonts returned]\n" );
	}
	else {
	    printf( "%d font names returned\n", numNames );
	    for ( i=0; i<numNames; i++ ) {
		extName = extNames[i];
		printf( "Font %5d name: <%s>\n", i, extName );
	    }
	    XFreeFontNames( extNames );
	}
}

I believe the actual name of the font in STANDARD.DECW$FONT is something like:

	/site/Chris/Xconq/lib/xconq.onx.bdf

If you create this from a .BDF file using the VMS font command, try

    $ font standard.bdf/report=standard.report

and see the report file for more info.

Jatin

Yes, the name is what .8 said, but the XLF listing didn't even show
that name.  Is there a restriction on the font name conventions?

				/Brad

Ok, after a FULL reboot, I have made the new fonts visible.  There seems to
be  a  problem  performing  a  "RESTART",  which  causes  a new server to be
created, a new process "WSAx", and some cryptic error message number which
(of course) I didn't note down.

On another note, I think our current method for adding new fonts BITES!!
Is this an X-imposed restriction?  Could we push for a better alternative?

					/Brad

    Well, you could also have done XSetFontPath to the DECW$FONT:.  That
    forces the server to rescan the directory.  (You may have to set it
    some other directory first and then back to DECW$FONT...I don't
    remember).
    
    You should not have to reboot.  If you have privs, RESTART should
    work.  If you don't, it should mmediately exit wiith a nice, albeit
    English, message.  I have never seen it fail.  Where did the error
    message appear?  (It was probably just one of the stupid connection
    failed message from the new loginout process trying to connect to your
    server when it was not authorized to do so (because you were still
    logged in)).  The question is, why did it not restart?  I presume
    that you did not have to log in again, right?  If restart had worked,
    you would have to log in.
    
    Burns
    

The answer to the RESTART failure was that the DECW$STARTUP procedure was
started from a connected terminal.  Unfortunately, this is my thoerizing,
it seems to want to use the connected terminal as a WSAx device.  Not good,
negative outcome.  And the error message shows up (in VERY small print) on
the big screen.

Now that I have the FONT names correct (thanks to previous replies), I'll
have to retry the XSetFontPath to force a rescan.

			/Brad

    I'm not sure what you mean by "connected terminal", but I can't think
    of any reason why DECW$STATUP RESTART should not run from anywhere on
    the system, as long as you have privs.  What is does is start a
    detached process to do the dirty work anyway.
    
    Burns
    

Yes, I noticed the detached process, but it something gets confused.  I was
logged into SYSTEM on my workstation, via SETHOST from another node.

Specific scenario:
	1) Session on uVax-II with VMS V5.1 (Node A)

	2) Session on remote vax. (Node B)

	3) SET HOST A

	4) login SYSTEM

	5) @DECW$STARTUP "RESTART"

	6) Session 1 (Node A) hangs. The session logged in remotely
	   is fine.  Several additional tries to startup DECwindows.
	   No good.



			/Brad

    Sorry to revisit this one . A customer has hit the problem of the
    server not seeing new fonts if a XLoadFont call fails or if they
    load the same font again and purge the other fonts (the server seems
    to keep a note of the version  number).The problem is solved by
    calling XSetFontPath,as suggested in this note.However this takes
    about 45 seconds on a VS2000 , time in which you can do nothing
    else on the system.The customer takes a dim view of this.
    	All I really doing is adding more evidence that the way that
    the server is able to update itself of its environment isn't winning
    us many friends.The same sort of problem arises when DEcnet bounces
    and the X$X0 object is lost.It would be nice if the server was more
    responsive to the link going down.Maybe this should be brought up
    in a different note.
    
    regards Mark

Why don't you qar this problem.  One reason we have not done anything about
this is that no one has complained.

I'm also not sure how this relates to the network link, but I answered that
question in another place.

The deal is that the font names are not the same as file names.  The server
needs to be able to map font names to file names quickly, so at startup
time, it builds a table.  This is a slow process since it has to open
every font file in the directory and read in enough to find the font name.
After that it never scans the directory again (because it is so slow) until
someone does a SetFontPath.   Then it happens again.

One possible thing to do is to keep an accelerator file in the same directory
which keeps the font/filename correspondance.  The problem with that is that
the file may get out of date.  Maybe that is ok?  Comments welcome.

Burns

How about a new call to add font in file to the list?  Pass the file 
name and let the user worry about it having the right font name.