cplai@daisy.UUCP (Chung-Pang Lai) (04/21/89)
In Glenn Reid's previous posting, he mentioned an idea of code factorization.
It is a very good idea especially for unix users. Imagine something like:
cat pie-chart.lib market-share.ps | lpr -Pps
A predefine set of functions (e.g. a pie chart drawing package) can be sold
by PS software vendors and user of the package can write a simple few line
program to pass data to the functions and outcome a nicely drawn EPSF ready
for printing or import into other documents.
Just like a C program, we can use predefined functions by #include <stdio.h>
and many many other packages. C is a compiled language, the unresolved
references to the external routines are handled by the linker. In an
interpretive language like PS, the unresolved references can be handled
by a preprocessor and the functions' definition is downloaded to the printer
before the job is. If the preprocessor is well written, it will include
only the function needed and hence reduce the download time to the printer.
Many users have struggled with Mac PS files on unix printer simply because
the laserprep is designed for apple printer and cannot be used on a unix
printer. If the prolog and the script of a PS program are stored separately,
a PS file will only contain the script and a PRAGMA to indicate that it uses
the laserprep library. When the file is printed on a mac, the mac driver
prepend the mac version of the laserprep designed for the specific printer
before the job is send to the printer. On a unix system, the preprocessor
or the driver add the unix version of the laserprep to the job. Firstly,
all PS file will be shrunk to its minimal size and hence save a lot of disk
space. Secondly, all PS file can be more portable as long as everyone is
using standard packages.
Imagine if you need to print 10 Adobe illustrator files, the Adobe prolog
is inside each file and hence is download to the printer 10 times. However,
if Adobe release an Illustrator library, and the Illustrator program only
output the script portion, then the files are much much smaller and the
printing is much faster because the prolog is down load only once.
e.g. cat Illust.lib pic1.art ... pic10.art
Seem like this can be done without any modification to the language. Perhaps
a %%include meta-comment can be added to the conforming PS standard. It is
just a matter of changing the coding convention.
Why wasn't it done? Did I miss something?
Please reply thru e-mail because by the time I get back from vacation, the
news article will expire. e-mail to pyramid!daisy!cplai Thanks.
--
.signature under construction ...
{pyramid, osu-cis, uunet, killer}!daisy!cplai C.P. Lai
cplai%daisy.UUCP@uunet.UU.NET cplai%daisy@killer.DALLAS.TX.USA
Daisy Systems Corp, 700B Middlefield Road, Mtn View CA 94039. (415)960-6961greid@adobe.com (Glenn Reid) (04/25/89)
In article <2994@daisy.UUCP> cplai@daisy.UUCP (Chung-Pang Lai) writes: > >Just like a C program, we can use predefined functions by #include <stdio.h> >and many many other packages. C is a compiled language, the unresolved >references to the external routines are handled by the linker. In an >interpretive language like PS, the unresolved references can be handled >by a preprocessor and the functions' definition is downloaded to the printer >before the job is. If the preprocessor is well written, it will include >only the function needed and hence reduce the download time to the printer. This is a good idea, of course. >Imagine if you need to print 10 Adobe illustrator files, the Adobe prolog >is inside each file and hence is download to the printer 10 times. However, >if Adobe release an Illustrator library, and the Illustrator program only >output the script portion, then the files are much much smaller and the >printing is much faster because the prolog is down load only once. >e.g. cat Illust.lib pic1.art ... pic10.art I did this very thing when writing a book that used Illustrator drawings. >Seem like this can be done without any modification to the language. Perhaps >a %%include meta-comment can be added to the conforming PS standard. It is >just a matter of changing the coding convention. It's already there. When was the last time you read through it? >Why wasn't it done? Did I miss something? Yes, you did. Look at the %%IncludeFile, %%ExecuteFile, %%IncludeProcSet, %%BeginFile, %%EndFile, %%BeginProcSet, %%EndProcSet, %%BeginSetup, %%EndSetup, and %%EndProlog comments. They all contribute to this idea. The hardest part about this is that PostScript programmers notoriously neglect this kind of possibility. For example, consider the following piece of code, which, despite the comments, you can't factor into one prologue plus more than one instance of the script. It's pretty common: %!PS-Adobe-2.0 %%EndComments /myprog save def %%BeginProcSet: prologue 1.0 0 /proc1 { a b c } def /proc2 { a b 2 div c 2 mul } bind def %%EndProcSet: prologue 1.0 0 %%EndProlog %%Page: 1 1 (whatever) proc1 proc2 %%Trailer myprog restore %%EOF Since the "save" is done inside the prologue, and the restore is done at the end of the document, it will only work once. Incidentally, that makes the file NON-CONFORMING, despite the comments that claim that it is a conforming document. Anyway, it is all a good idea and worth doing. Glenn Reid Adobe Systems
smithda@cpsvax.cps.msu.edu (J. Daniel Smith) (04/25/89)
In article <2994@daisy.UUCP> cplai@daisy.UUCP (Chung-Pang Lai) writes: >Please reply thru e-mail because by the time I get back from vacation, the >news article will expire. e-mail to pyramid!daisy!cplai Thanks. This all sounds very interesting. Why don't you post and send EMAIL. The rest of us don't want to miss out. :-) Dan ========================================================================= J. Daniel Smith Internet: smithda@cpsvax.cps.msu.edu Michigan State University BITNET: smithdan@msuegr There was things which he strechted, but mainly he told the truth. - Mark Twain, Huckleberry Finn =========================================================================
rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (04/25/89)
> The hardest part about this is that PostScript programmers notoriously > neglect this kind of possibility. For example, consider the following > piece of code, which, despite the comments, you can't factor into one > prologue plus more than one instance of the script. It's pretty common: > > /myprog save def > %%BeginProcSet: prologue 1.0 0 ... > %%EndProcSet: prologue 1.0 0 ... > myprog restore > Glenn Reid Okay, so where does a global save/restore go, in the context of EPSF? (Don't tell me that we should assume the save/restore, as supplied by the printer, because many people on microcomputers lack the proper spooling software that sends ^D's at the end of the file.) The restore has to go in the trailer. The save can't be in any of the pages. Between the prologue and the pages? But I want to lose the prologue definitions too, if possible. Comments?
greid@adobe.com (Glenn Reid) (04/26/89)
In article <8751@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes: >> The hardest part about this is that PostScript programmers notoriously >> neglect this kind of possibility. For example, consider the following >> piece of code, which, despite the comments, you can't factor into one >> prologue plus more than one instance of the script. It's pretty common: >> >> /myprog save def >> %%BeginProcSet: prologue 1.0 0 > ... >> %%EndProcSet: prologue 1.0 0 > ... >> myprog restore >> Glenn Reid > >Okay, so where does a global save/restore go, in the context of EPSF? >(Don't tell me that we should assume the save/restore, as supplied by >the printer, because many people on microcomputers lack the proper >spooling software that sends ^D's at the end of the file.) The restore >has to go in the trailer. The save can't be in any of the pages. >Between the prologue and the pages? But I want to lose the prologue >definitions too, if possible. Comments? The save and restore pairs go around each page. And yes, I am going to tell you that you should assume the save/restore as supplied by the printer if you want to be a conforming PostScript file. If you want to protect yourself against the lowest common denominator (people who don't have the ability to add ^D), you give up the functionality of page reversal and conforming documents. If you are going to the trouble to write a preprocessor that can syntactically rearrange pages based on a sophisticated parser, I won't buy the argument that you can't add ^D at the end when you send it to the printer. The "proper spooling software" can consist of a two-line batch file that tacks an end-of-file indication at the end of each job. If you don't do this, page reversal will be the least of your problems. Anything printed that contains "exitserver" will cause the printer to use up memory indefinitely until it blows up, unless you terminate the job with an end-of-file. Anyway, forgive my impatience with the ^D issue. It is a plague on portability and on the world. But I will declare your program to be nonconforming if you put save/restore around the %%EndProlog boundary. It is worthy of note that it is possible to write a fully conforming PostScript file that begins with "save" and ends with "restore", as long as you put %%EndProlog before the first "save" and otherwise take care to stay within the restrictions of conforming documents. Glenn Reid Adobe Systems
labc-4da@e260-4d.berkeley.edu (Bob Heiney) (04/26/89)
Hi, I'm just getting in to PostScript, and I've just joined this newsgroup. My edition of the Redbook, which I just bought, has only version 1.0 of the program structuring conventions. How can I get the 2.0 conventions? I understand Adobe has some kind of mail-based downloading system. Is this where to go? Could someone email me as to how to use it? Sorry if this is the upteen-billionth time someone has asked this on this newsgroup. ------------------------------------------------------------------------------- | Bob Heiney "And in the end, the love you | | labc-4da@rosebud.Berkeley.edu take is equal to the love you make." | | -- The Beatles | -------------------------------------------------------------------------------
paolucci@snll-arpagw.UUCP (Sam Paolucci) (04/26/89)
In article <783@adobe.UUCP> greid@adobe.COM (Glenn Reid) writes:
->If you are going to the
->trouble to write a preprocessor that can syntactically rearrange pages
->based on a sophisticated parser, I won't buy the argument that you
->can't add ^D at the end when you send it to the printer.
->
->The "proper spooling software" can consist of a two-line batch file
->that tacks an end-of-file indication at the end of each job. If you
->don't do this, page reversal will be the least of your problems.
->Anything printed that contains "exitserver" will cause the printer to
->use up memory indefinitely until it blows up, unless you terminate the
->job with an end-of-file.
->
->Anyway, forgive my impatience with the ^D issue. It is a plague on
->portability and on the world.
Let's see. Say I have a PostScript printer attached to the serial port
of my PC. And say that I can just copy the file directly to the serial
device. Also, say that I can redirect the output of an application
that outputs PostScript to either a file or the serial device directly.
If the application does not append a ^D to the end of the output, and
the output is redirected to the serial device, then we have no end of
file. Also if the output is redirected to a file, and later the PC
user decides to copy the file directly to the serial device, again we
have no end of file.
Thus it appears to me that in a PC world where access to the serial
device is easy and transparent, the only option is for the application
program to append a ^D to the end of the PostScript output. This
guarantees that the file will be handled properly whether it is
redirected to the serial device, or later copied to it.
--
-+= SAM =+-
"the best things in life are free"
ARPA: paolucci@snll-arpagw.llnl.govholland@m2.csc.ti.com (Fred Hollander) (04/27/89)
In article <23602@agate.BERKELEY.EDU> labc-4da@e260-4d.berkeley.edu (Bob Heiney) writes: >Hi, I'm just getting in to PostScript, and I've just joined this newsgroup. >My edition of the Redbook, which I just bought, has only version 1.0 of the >program structuring conventions. How can I get the 2.0 conventions? > >I understand Adobe has some kind of mail-based downloading system. Is this >where to go? Could someone email me as to how to use it? Send a message with subject "help" and no content (or a message with "help" on a line by itself) to ps-file-server@adobe.com. Fred Hollander Computer Science Center Texas Instruments, Inc. hollander@ti.com The above statements are my own and not representative of Texas Instruments.
evans@ccicpg.UUCP ( Scott Evans) (04/28/89)
In article <98@snll-arpagw.UUCP>, paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: > Thus it appears to me that in a PC world where access to the serial > device is easy and transparent, the only option is for the application > program to append a ^D to the end of the PostScript output. This > guarantees that the file will be handled properly whether it is > redirected to the serial device, or later copied to it. > > Can we help it if the PC is a "brain-dead" kind of machine and has no other way telling when it gets to an "end of file"???? This is purely a kludge to get around a limitation on the PC. It is especially apparent when you see a ^D not only at the end of a Postscript file but also at the beginning!!! The postscript printer that is hooked up to our Unix system does not like the ^D at the beginning of the file and so we have to filter all the files that come from a PC before they can be printed.
paolucci@snll-arpagw.UUCP (Sam Paolucci) (04/28/89)
In article <22489@ccicpg.UUCP> evans@ccicpg.UUCP ( Scott Evans) writes: ->In article <98@snll-arpagw.UUCP>, paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: ->> Thus it appears to me that in a PC world where access to the serial ->> device is easy and transparent, the only option is for the application ->> program to append a ^D to the end of the PostScript output. This ->> guarantees that the file will be handled properly whether it is ->> redirected to the serial device, or later copied to it. ->> ->> ->Can we help it if the PC is a "brain-dead" kind of machine and has no ->other way telling when it gets to an "end of file"???? -> ->This is purely a kludge to get around a limitation on the PC. It is ->especially apparent when you see a ^D not only at the end of a Postscript ->file but also at the beginning!!! -> ->The postscript printer that is hooked up to our Unix system does not like the ->^D at the beginning of the file and so we have to filter all the files that ->come from a PC before they can be printed. This is baloney, and I'll tell you why. First of all I was not talking about what you refer to a "brain-dead" PC. I was talking about an Amiga. Remember, the whole world does not revolve around big blue. But that is besides the point. A copy command (or cat, or type, or ...) should not append anything to a file. It is not their job. These commands have no way, and should not have any way of telling that you are redirecting their output to your serial device. Only the user knows this. The standard joe user does not know that Adobe defines a "job" as a file which includes a ^D at the end. Furthermore, to my knowledge, nowhere in the PostScript red book does it say explicitly that a "job" consists of a PostScript program terminated by a ^D. Granted, anytime you include binary data in a file reduces portability. But I was referring to a DEDICATED PostScript printer attached to the serial port of a machine that might not have a print spooler, and where the serial port can be directly and easily accessible to the user with a simple copy command. In this case it is a lot more convenient and efficient to have a utility that strips off ^D at the end of a file occasionally when you have to move it over some other system, than to have to append a ^D every time you print something. Finally, I never excused the sending of a PostScript file with ^D's to a networked printer spooler. That is just bad manners. But that is a different question. -- -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
richard@gryphon.COM (Richard Sexton) (04/30/89)
In article <100@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >In article <22489@ccicpg.UUCP> evans@ccicpg.UUCP ( Scott Evans) writes: >-> >->Can we help it if the PC is a "brain-dead" kind of machine and has no >->other way telling when it gets to an "end of file"???? >-> [details of networked UNIX systems deleted] >This is baloney, and I'll tell you why. First of all I was not talking >about what you refer to a "brain-dead" PC. I was talking about an Amiga. Uh, yes thats nice you have a big clump of 6/32's talking to a PS printer Scott, but the difference between your set up and Sams and mine is that *we own* our equipment :-) -- "My latest 'problem', btw, is that I'm working out an opportunity to get laid with some girl over the net." - Ted Kaldis richard@gryphon.COM decwrl!gryphon!richard gryphon!richard@elroy.jpl.NASA.GOV
nelson@sun.soe.clarkson.edu (Russ Nelson) (05/01/89)
In article <98@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: In article <783@adobe.UUCP> greid@adobe.COM (Glenn Reid) writes: ->Anyway, forgive my impatience with the ^D issue. It is a plague on ->portability and on the world. Also if the output is redirected to a file, and later the PC user decides to copy the file directly to the serial device, again we have no end of file. #include <stdio.h> #include <gnu_general_license.h> #define PRINTER "prn" main() { int c; FILE *printer; if ((printer = fopen(PRINTER,"w")) == NULL) { fprintf(stderr, "Uh-oh, you don't have a printer."); exit(1); } while ((c = getc(stdin)) != EOF) { putc(c, printer); } putc(4, printer); fclose(printer); } Problem solved. Now you just have to teach your applications that emit PS to append a ^D if stdout is a device. On MS-LOSS it looks something like this: if (isatty(stdout)) putc(4, stdout); -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) I'm a right-to-lifer -- everyone has a right to earn a living sufficient to feed himself and his family.
paolucci@snll-arpagw.UUCP (Sam Paolucci) (05/01/89)
In article <NELSON.89May1004223@sun.soe.clarkson.edu> nelson@clutx.clarkson.edu writes: ->In article <98@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: -> -> In article <783@adobe.UUCP> greid@adobe.COM (Glenn Reid) writes: -> ->Anyway, forgive my impatience with the ^D issue. It is a plague on -> ->portability and on the world. -> -> Also if the output is redirected to a file, and later the PC -> user decides to copy the file directly to the serial device, again we -> have no end of file. -> ->#include <stdio.h> ->#include <gnu_general_license.h> -> ->#define PRINTER "prn" -> ->main() ->{ -> int c; -> FILE *printer; -> -> if ((printer = fopen(PRINTER,"w")) == NULL) { -> fprintf(stderr, "Uh-oh, you don't have a printer."); -> exit(1); -> } -> while ((c = getc(stdin)) != EOF) { -> putc(c, printer); -> } -> putc(4, printer); -> fclose(printer); ->} -> ->Problem solved. Now you just have to teach your applications that emit ->PS to append a ^D if stdout is a device. On MS-LOSS it looks something ->like this: -> -> if (isatty(stdout)) -> putc(4, stdout); I had only a three line script that accomplished the same thing. But it doesn't solve the problem since a user can redirect stdout to a file, and the if he uses the above routine to print it out, he than has not 1, but 2 ^D's, one in the file, and one appended when he prints it out. The right answer is to have a print spooler. This would solve all the problems. But until that happens, I think it is proper to generate the PostScript files with a ^D at the end on machines that have a DEDICATED (non shared) PostScript printer. -- -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
hadgraft@civeng.monash.edu.au (Roger Hadgraft) (05/02/89)
In article <22489@ccicpg.UUCP>, evans@ccicpg.UUCP ( Scott Evans) writes: > In article <98@snll-arpagw.UUCP>, paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: > > This is purely a kludge to get around a limitation on the PC. It is > especially apparent when you see a ^D not only at the end of a Postscript > file but also at the beginning!!! > > The postscript printer that is hooked up to our Unix system does not like the > ^D at the beginning of the file and so we have to filter all the files that > come from a PC before they can be printed. My experience has been exactly the opposite. Our PS printers connected to our terminal network won't print PS files WITHOUT a ^D at the start! -- Roger Hadgraft | hadgraft@civeng.monash.edu.au@munnari.oz Lecturer in Civil Engineering | phone: +61 3 565 4983 Monash University | fax: +61 3 565 3409 Clayton, Vic. 3168. Australia. |
greid@adobe.com (Glenn Reid) (05/03/89)
In article <109@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >I had only a three line script that accomplished the same thing. But it >doesn't solve the problem since a user can redirect stdout to a file, and >the if he uses the above routine to print it out, he than has not 1, but >2 ^D's, one in the file, and one appended when he prints it out. You missed the most important part of his message. The script/program to add a control-D is easy. The important part is OMITTING IT when you are writing to a file and you know you are writing to a file, and INCLUDING IT when you are writing to a device like a tty: >->Problem solved. Now you just have to teach your applications that emit >->PS to append a ^D if stdout is a device. On MS-LOSS it looks something >->like this: >-> >-> if (isatty(stdout)) >-> putc(4, stdout); > >The right answer is to have a print spooler. This would solve all the >problems. But until that happens, I think it is proper to generate the >PostScript files with a ^D at the end on machines that have a DEDICATED >(non shared) PostScript printer. The right solution is to do something different when you write to a local file. In fact, lots of things should probably be different, not just the ^D at the end. You should include the prologue, not just the document part (if you have downloaded the prologue separately into the VM of the printer on a "DEDICATED" printer). You should TAKE OUT any device-specific code that selects, say, a paper size, and put in COMMENTS instead that will teach a spooler somewhere else how to print the file correctly on a different printer. When you write a PostScript language program to a file, there are only three likely uses of it, in my opinion: 1. The user wants to drag the file to another system for printing, or mail it to his friend, or otherwise export the file. 2. The user wants to paste it into another application as an illustration (EPS file). 3. The user is a hacker and wants to hack and look at PS. In cases 1 and 2 above, you don't want ^D in the file. And if all you want to do is to print it on your dedicated printer, a three-line script will do it. Or you can COPY PSEOF.TXT yourself, since you typically have 30 seconds before you timeout. Sigh. I wish this weren't such a problem. IBM has recently come out with a PostScript interpreter for their 370 mainframe machine which can drive almost all of their printers. The single biggest red flag item on their list was that PC software puts ^D into print files, and they would generate an ERROR on the 370 machine. This is not a local problem, and it is false to assume that PostScript files are going to stay on the user's system, because people take them EVERYWHERE, and the people who get it right will have a lot more customers who are happy. Glenn Reid Adobe Systems
les@chinet.chi.il.us (Leslie Mikesell) (05/04/89)
In article <809@adobe.UUCP> greid@adobe.COM (Glenn Reid) writes: >When you write a PostScript language program to a file, there are only >three likely uses of it, in my opinion: > 1. The user wants to drag the file to another system for > printing, or mail it to his friend, or otherwise export > the file. > 2. The user wants to paste it into another application as > an illustration (EPS file). > 3. The user is a hacker and wants to hack and look at PS. > >In cases 1 and 2 above, you don't want ^D in the file. And if all you >want to do is to print it on your dedicated printer, a three-line >script will do it. Or you can COPY PSEOF.TXT yourself, since you >typically have 30 seconds before you timeout. >Sigh. I wish this weren't such a problem. Why aren't the things that actually handle postscript intelligently (i.e. print spoolers and programs that include EPS into a larger postscript entity) smart enough to delete the embedded ^D put out at the end of a file by ordinary applications. If the postscript in question is in a file, it's pretty easy to see that the ^D is the last character and delete it when it is not appropriate. Even if the data comes from a pipe it only takes one character of read-ahead to detect it. Am I missing something here? Is there any case where a ^D at the end of a file would mean something other than EOF in postscript? Making PS-aware programs deal with this would allow "dumb" programs/drivers to work with the embedded ^D. Les Mikesell
moore@PULSAR.FAC.CS.CMU.EDU (Dale Moore) (05/04/89)
Ok. I've bit my tongue for too long about this Control-D stuff. I can't hold it in any longer.... FLAME ON Control-D should not be in the PostScript file. Don't confuse the Language with the transport mechanism. You don't put Control-S and Control-Q in your file do you? Yet they serve the communication protocol as importantly as Control-D. Control-D does not mean End of File or End of Session or whatever in PostScript. Check out the red book (RTFM). I've got several PostScript printers that are connected to an Ethernet. You don't send down a Control-D on the ethernet to indicate End-Of-File. You send a Packet with the FIN bit set, or some other protocol dependent thing. Maybe I want a Control-D in my file. Maybe I don't want to have my spoolers filter it out. Maybe my code looks something like... /foobar currentfile 8 string readstring Foo\004Bar\003 def I'm tired of PC weanies coming to bitch at me because their PostScript files won't work on my printers. And I look at their PostScript, and they have Control-D in them. This is just another example of how the PC is setting back Computer Science at least decade. END OF FLAME Above is a collection of random characters. They do not represent the opinion of anyone anywhere. All flames can be filed in /dev/null, NLA0:, WasteBasket, our your favorite Trashcan Icon, which may or may not be trademarked, copyrighted, and patented. --
wcs) (05/10/89)
In article <809@adobe.UUCP> greid@adobe.COM (Glenn Reid) writes:
] You missed the most important part of his message. The script/program
] to add a control-D is easy. The important part is OMITTING IT when you
] are writing to a file and you know you are writing to a file, and
] INCLUDING IT when you are writing to a device like a tty:
] The right solution is to do something different when you write to a
] local file. In fact, lots of things should probably be different, not
] just the ^D at the end. You should include the prologue, not just the
] document part (if you have downloaded the prologue separately into the
] VM of the printer on a "DEDICATED" printer). You should TAKE OUT any
] device-specific code that selects, say, a paper size, and put in
] COMMENTS instead that will teach a spooler somewhere else how to print
] the file correctly on a different printer.
Unfortunately, the right solution *was* to do something better with
the language/EPSF/printer planning, but it's too late now.
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.)
Shouldn't this have been done by defining the appropriate EPSF code?
--
# Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs
# also found at 201-271-4712 tarpon.att.com!wcs
# welcome, to mars, eh, hosers! Have a brew and some donuts, eh?greid@adobe.com (Glenn Reid) (05/12/89)
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