batcheldern@hannah.dec.com (Ned Batchelder, PostScript Eng.) (05/09/89)
In article <8407@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: >How many places does something have to appear in an official reference >manual to make it official. My reason for excluding Appendix D was not that something has to be repeated to be meant, but that Appendix D is not defining the PostScript language. The Red Book that has appendix D does more than define the language, it also describes implementation details about a particular printer (the Apple LaserWriter) that implements the language. Not everything that the LaserWriter does is part of PostScript. >Perhaps we should have a separate discusssion about printers that emulate >the apple laserwriter and stop talking about ^D and postscript. Although one of the reasons for not putting ^D in a file is that some printers don't understand it, it is not the main reason. We could restrict our discussion to LaserWriters only, and we would still get into problems if ^D's are in the files. The Unix spoolers that are looking for the ^D echo will still get confused if it is a LaserWriter at the end of the wire. The main point to keep in mind is that the intention of the ^D was as an end-of-file marker to be used by spoolers (or application back-ends if they were spooling the file). They were never intended to be put into files. If you are working in an environment which does not fully support the PostScript model of printing, there are naturally many ways you could patch things to get it to work for you. But if you patch it in the wrong way, it will work for ONLY you. Putting ^D in files is the wrong patch. The right patch is to arrange that a ^D is sent to the printer after the file is sent. As a number of people have pointed out here, it isn't that difficult to get a ^D to a printer in MS-DOS. If you make the small effort required, everything will work. --Ned Batchelder, Digital Equipment Corp, BatchelderN@Hannah.DEC.com
les@chinet.chi.il.us (Leslie Mikesell) (05/10/89)
In article <8905091312.AA22444@decwrl.dec.com> batcheldern@hannah.dec.com (Ned Batchelder, PostScript Eng.) writes: >Although one of the reasons for not putting ^D in a file is that some The Unix spoolers that are looking for the ^D echo will still get >confused if it is a LaserWriter at the end of the wire. > The echo of the ^D is an entirely different issue than the embedded ^D. If you have an NEC 890 using the parallel interface you won't see any echos but the ^D still resets the postscript VM. >end-of-file marker to be used by spoolers (or application back-ends if they >were spooling the file). They were never intended to be put into files. > And I will continue to insist that applications should never need to know if their output is going to a device, file, or another process. >PostScript model of printing, there are naturally many ways you could patch >things to get it to work for you. But if you patch it in the wrong way, it >will work for ONLY you. Putting ^D in files is the wrong patch. The right >patch is to arrange that a ^D is sent to the printer after the file is sent. > >As a number of people have pointed out here, it isn't that difficult to get >a ^D to a printer in MS-DOS. If you make the small effort required, >everything will work. OK, let's accept the fact that there is a problem here, which is mostly that ^D is not "white-space" when it actually is passed to the postscript parser, or that end-of-job is not a plain-text postscript command. Now we have to decide where to fix it - you seem to suggest that all *dumb* applications and drivers be made aware of whether or not they are directly connected to a printer that needs the ^D or not. This sounds much more difficult to me than fixing the "postscript-aware" programs to remove anything that isn't postscript - after all, they are supposed to know about such things. Anything that knows it is supposed to add a ^D at the end can easily strip them anywhere else. Keep in mind just *how dumb* the dumb applications and drivers are - for example the suggestion of making a batch file to add the ^D for MDOS will fail if it is being called from another batch file unless that batch file knows it is invoking another batch file. Also if you transport it on a floppy (a likely reason for writing to a file in the first place) you have to make sure the support files go along. Les
batcheldern@hannah.dec.com (Ned Batchelder) (05/12/89)
les@chinet.chi.il.us suggests that we fix the ^D problem by making PostScript-aware programs "remove anything that isn't postscript". That solution will work in some environments, but not in others. In fact, Digital's ScriptPrinter symbiont does strip out ^D's that it finds in files (it also strips ^S, ^Q, ^C, and ^T). That makes sense, because the ScriptPrinter is a serial device, and the symbiont knows that a ^D on the wire will do the wrong thing (unless the symbiont sent it). But how should we handle the same situation for the PrintServer 40? There a ^D can be sent to the printer just fine. It really only makes sense if the input is being read by the PostScript program, rather than the PostScript interpreter, and it certainly won't be portable to other environments, but does it make sense to limit the use of the printer in this way? Some customer may know what they are doing, and may accept that his software won't be portable, but will opt to use full eight-bit binary image transmission (for example) because it makes things go faster. If we were to write the PrintServer 40 symbiont to strip out ^D's, it would be close to an arbitrary limitation of the transparent data path to the printer. les@chinet.chi.il.us in the same note states that an application shouldn't know if its output is going to a printer, a file, or another process. I whole-heartedly agree, with one exception. If an application has decided to shoulder the responsibility of controlling the printer, then it ought to know if its output is going to the printer or not. And writing ^D's is part of controlling the printer. If your application is outputting ^D, then it has to know where its output is going. --Ned Batchelder, Digital Equipment Corp, BatchelderN@Hannah.DEC.com