Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!adobe!greid
From: greid@adobe.com (Glenn Reid)
Newsgroups: comp.lang.postscript
Subject: Re: PS libraries
Message-ID: <826@adobe.UUCP>
Date: 11 May 89 18:04:41 GMT
References: <2994@daisy.UUCP> <775@adobe.UUCP> <8751@polya.Stanford.EDU> <783@adobe.UUCP> <98@snll-arpagw.UUCP> <NELSON.89May1004223@sun.soe.clarkson.edu> <109@snll-arpagw.UUCP> <809@adobe.UUCP> <495@cbnewsh.ATT.COM>
Sender: news@adobe.COM
Reply-To: greid@adobe.COM (Glenn Reid)
Organization: Adobe Systems Incorporated, Mountain View
Lines: 44

In article <495@cbnewsh.ATT.COM> wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 ho95c.att.com!wcs) writes:
>Unfortunately, the right solution *was* to do something better with
>the language/EPSF/printer planning, but it's too late now.

That may be true, although I'm not sure what EPSF has to do with it.
Perhaps there needs to be an explicit BEGINJOB and ENDJOB operator or
something like that.

>From what I can tell from all these discussions, the purpose of the
>implementation-dependent-EOT-marker ( e.g. ^D ), is to tell the
>printer this print job  is done, so it can play games with  EPSF
>like reversing pages.  (Otherwise, all it would need to do is wait
>for showpage messages and print stuff.)

Not quite.  EPSF has nothing to do with it.  Since a PostScript job may
make arbitrary changes to the state of the interpreter, including using
up memory, changing the transformation matrix, downloading fonts, etc,
the printer must guarantee that each job is COMPLETELY insulated from
the next job and the previous job, rather than relying on the
individual programs to clean up after themselves.  The way this is done
is called the "server loop".  When your job is finished, the server
loop inside the printer resets the state of the machine to the state
that existed when your job began.  It does this with "save" and
"restore", actually.

But the printer needs to know when your job is done.  "showpage" is not
enough, because you may not even call "showpage".  A downloadable font
never calls "showpage", and you can do arbitrary calculations without
ever printing a page.  The traditional way to determine the end of the
job is to rely on the communication channel.  When you send an
end-of-file, the interpreter knows that you are not going to send it
anything further.  If you send it "showpage", it waits to see if there
are more pages in your job.

>Shouldn't this have been done by  defining the  appropriate EPSF code?

I don't know quite what you mean by "appropriate EPSF code," but it
could be that there needs to be a beginjob / endjob concept in the
language.  But that's not so easy, either.  Then you have to worry
about nesting them, what it means to redefine "endjob", and things like
that.  The communciation model actually works very well.

Glenn Reid
Adobe Systems