#apd
11 messages in this thread
Hi, Mike,
Welcome back from the West Coast and back on Compuserve.
Actually I think you could create such a suite of setup files with LaserStatus.
It permits you to create "sets" of PostScript files which are run sequentially.
^Steve^
Which brings to mind to ask why "exitserver" jobs can't be concatenated into a
single file. Is this Apple's doings in the LW driver, or is there some manner
of EOJ command or comment which can be included in the file? The answer may be
hopelessly obvious, but my PostScript books aren't here at home, so I can't
quickly look at them myself.
Glad we had the chance to chat. It's always a help to know that there are
others paddling upstream in the same river.
…mm
Exitserver routines can only be ended by breaking communication with the
Interpreter. The interpreter resets itself to the server mode so that the next
time you connect, you are back in the server mode.
Frankly, sounds like a deficiency in PostScript to me. Who says that the user
_doesn't_ want to send multiple exitserver routines at a whack? Hmm?
…mm
Mike You can send as many exitserver routines as you wish in a single blow. But
you can only exit the server loop once in a 'connect'. Once you've executed
'serverdict begin <password> exitserver', you can stay there till you turn blue
in the face changing persistent parameters till they're worn down (EEROM is
dead), or you can execute a single change and disconnect. There's no need for
multiple (nested) exiting of server loops because there's only one server loop.
Once it's exited, no more remain. Nate
That's kinda why I conditioned my response on not having my PostScript
references on hand – I had this feeling that a little surgery on our "standard"
exitserver job files would produce one that would do what we wanted. It's just
that my previous attempt or two to do this was a crude concatenation of files
(ending up with multiple exitserver calls) and the interpreter upchucked and
purged the trailing routines.
I shall try your suggestion. Thanks. (Thanks to you too, Steve. The test strip
idea is dynamite, now that I know how you're doing it! <grin>)
…mm
Mike,
I've discovered by experience that you can combine multiple routines within an
exitserver job. You can even print out a job outside the server loop. For
example, I've set up a density strip for the Lino that changes to each of three
resolutions, prints a density bug at each resolution, and advances and cuts the
paper. The downside is that you do lose some printer memory (all exitserver
routines take up printer memory) until the RIP is reset.
BTW, the exitserver invocation always has to be at the BEGINNING of the job.
^Steve^
Steve: exitserver can be executed anytime there are no composite objects still
on the stack or defined in dictionaries. Basically, as long as the environment
of the interpeter is the same as the beginning of a job (easily attained by
proper use of save/restore) an exitserver could even be done as the last line
of a million character file. As far as losing printer memory outside of a
server loop, you ALWAYS lose printer memory with composite objects when you
neglect proper save/restore operations. Yes, those can even be executed outside
the server loop.
Nathan,
Thanks for the correction. This is one of those poorly documented features in
PostScript which demand clarification.
Now I can add save/restore to my exitserver routines to clean up memory.
^Steve^
Yes, except that if RIP fixer (aka Disk Restore) is first in the set, the
following files in the LaserStatus set (e.g., Helvetica Narrow patch, 90 lpi
default screen reset for RIP 2 with 150-line default) get sent to Never-Never
Land instead of into RIP memory. Perhaps Laser Status in combo with a QuicKeys
Timer macro, you could get somewhere. Sending RIP fixer last, well . . .
Jungle,
If this is the "RIP fixer/Disk Restore" file you're sending:
/scratch 100 string def
systemdict /filenameforall known
{ (FC/*) {deletefile} scratch filenameforall } if
serverdict begin 0 exitserver
systemdict begin quit
…then the reason everything goes into Never-Never Land immediately after this
file is executed is that the last line resets the RIP. And if the RIP isn't
reset, the next file run gets wierd errors because the font cache files have
been deleted.
^Steve^