raj@pollux.geog.ucsb.edu (Richard A Johnson) (12/07/90)
We have one postscript printer here which gets print jobs from all over a little network. (Mostly DOS machines) If someone prints a graphics image from a DOS program named "CorelDraw" to the printer and then someone sends a normal text file (which gets converted to postscript via the transcript program "pstext", but I've used "enscript" also with the same results), the CorelDraw image comes out just fine but the text file gets printed in a little tiny font and in mirror image fashion! Has anyone seen this before? Is there some command that I can put in the header of all jobs going to the printer which would fix this? If someone can give me hint of what's happening (what CorelDraw is not resetting correctly), I can call them and turn in a bug report. HELP! /raj
rokicki@Neon.Stanford.EDU (Tomas G. Rokicki) (12/07/90)
> If someone prints a graphics image > from a DOS program named "CorelDraw" to the printer and then someone sends > a normal text file, the > CorelDraw image comes out just fine but the text file gets printed in a > little tiny font and in mirror image fashion! Your `spooler' (whoever is managing the printer) is not terminating each job by a control-D. It is the spooler's responsibility to do this. This control-D (which many programs mistakenly include in their PostScript output) tells the printer that the job is over, reset back to initial conditions for the next job. -tom
ken@csis.dit.csiro.au (Ken Yap) (12/07/90)
>We have one postscript printer here which gets print jobs from all over a >little network. (Mostly DOS machines) If someone prints a graphics image >from a DOS program named "CorelDraw" to the printer and then someone sends >a normal text file (which gets converted to postscript via the transcript >program "pstext", but I've used "enscript" also with the same results), the >CorelDraw image comes out just fine but the text file gets printed in a >little tiny font and in mirror image fashion! Yes, this happens when one job changes the transformation matrix and then the next job follows without an intervening control-d (EOJ). >Has anyone seen this before? Is there some command that I can put in the >header of all jobs going to the printer which would fix this? If someone >can give me hint of what's happening (what CorelDraw is not resetting >correctly), I can call them and turn in a bug report. Make sure all your jobs are properly terminated by control-d. Ideally the spooling software should append this, but in PC environments programs tack on a control-d at the end.
claus@suncvt13.verfahrenstechnik.uni-stuttgart.de (Claus Fleischer) (12/07/90)
In article <7699@hub.ucsb.edu> raj@pollux.geog.ucsb.edu (Richard A Johnson) writes: >We have one postscript printer here ... > ... If someone prints a graphics image >from a DOS program named "CorelDraw" to the printer and then someone sends >a normal text file (which gets converted to postscript via the transcript >program "pstext", but I've used "enscript" also with the same results), the >CorelDraw image comes out just fine but the text file gets printed in a >little tiny font and in mirror image fashion! > We have the same problem on our installation after sending PS-output from LaTeX (converted with dvips 4.2) to the laser printer. The behavior Richard described occures exactly for the first page of the next print job. Our laser printer is a "QMS-PS810 turbo". * Is the behavior a result of a bug in the printer software ( does it have to be configured differently)? * Is it possible that some adjustments hafe to be made in the "config.ps" file from the dvips? Any help would be appreciated. With thanks in advance Claus claus@suncvt13.verfahrenstechnik.uni-stuttgart.de
toms@fcs260c2.ncifcrf.gov (Tom Schneider) (12/08/90)
In article <7699@hub.ucsb.edu> raj@pollux.geog.ucsb.edu (Richard A Johnson) writes: > ...but the text file gets printed in a >little tiny font and in mirror image fashion! >Has anyone seen this before? Is there some command that I can put in the >header of all jobs going to the printer which would fix this? Yes, that happend to me before we installed 'transcript'. To get around it you should be able to simply: initgraphics before (or between) each job. This should get you going quickly. Of course, the better solution is to get the control-D solution working. >/raj Tom Schneider National Cancer Institute Laboratory of Mathematical Biology Frederick, Maryland 21702-1201 toms@ncifcrf.gov
ajcd@cs.edinburgh.ac.uk (Angus Duggan) (12/08/90)
In article <371@rusux1.rus.uni-stuttgart.de>, claus@suncvt13.verfahrenstechnik.uni-stuttgart.de (Claus Fleischer) writes: > In article <7699@hub.ucsb.edu> raj@pollux.geog.ucsb.edu (Richard A Johnson) writes: > >We have one postscript printer here ... > > > ... If someone prints a graphics image > >from a DOS program named "CorelDraw" to the printer and then someone sends > >a normal text file (which gets converted to postscript via the transcript > >program "pstext", but I've used "enscript" also with the same results), the > >CorelDraw image comes out just fine but the text file gets printed in a > >little tiny font and in mirror image fashion! > > > > We have the same problem on our installation after sending PS-output > from LaTeX (converted with dvips 4.2) to the laser printer. The behavior > Richard described occures exactly for the first page of the next > print job. > What is happening is that you are sending two jobs without an end of job terminator (\004) between them. Dvips alters the current transformation matrix to make it similar to DVI file coordinates (origin top-left, resolution-dependent scaling on axes); this transformation is happening twice for the second job. The solution is: 1) If you are using dvips 5.4 (and some earlier versions, I can't remember when this option was added), add the -F option to the command line. If you don't have dvips 5.4, upgrade to it, because it's a whole lot better. 2) If you aren't using dvips, create a file with a single EOF (\004) in it, and add it on to anything you send to the printer. 3) Send your second job after the job timeout has expired :-) A. -- Angus Duggan, Department of Computer Science, | I'm pink, therefore I'm Spam. University of Edinburgh, JCMB, | JANET: ajcd@uk.ac.ed.lfcs The King's Buildings, Mayfield Road, | VOICE: (UK) 031 650 5126 Edinburgh, EH9 3JZ, Scotland. | OR: ajcd%lfcs.ed.ac.uk@nsfnet-relay.ac.uk
mzellers@starnet.uucp (Mark Zellers) (12/11/90)
In article <1971@fcs280s.ncifcrf.gov> toms@fcs260c2.ncifcrf.gov (Tom Schneider) writes: >Yes, that happend to me before we installed 'transcript'. To get around it >you should be able to simply: > initgraphics >before (or between) each job. This should get you going quickly. Of course, >the better solution is to get the control-D solution working. > I would definitely advise against using initgraphics as a solution to this problem. If you take this approach, there is a good chance that if you send many jobs to the printer one after the other that you will run out of virtual memory. That is because the VM consumed by the previous job will not be reclaimed by the server loop unless it sees the end of the job. One alternative method that will work is to surround the job with something along the lines: /SaveMe save def .. .. .. SaveMe restore This will not only get the coordinate system back to the default but also reclaim the VM. Mark H. Zellers 1550 Cowper St Palo Alto, CA 94301 decwrl.dec.com!batgirl!bwayne!mark
pipkinsj@cpqhou.uucp (Jeff Pipkins @Adv Dev@SE hou ) (01/03/91)
In article <371@rusux1.rus.uni-stuttgart.de> claus@suncvt13.verfahrenstechnik.uni-stuttgart.de (Claus Fleischer) writes: >In article <7699@hub.ucsb.edu> raj@pollux.geog.ucsb.edu (Richard A Johnson) writes: >>We have one postscript printer here ... > >> ... If someone prints a graphics image >>from a DOS program named "CorelDraw" to the printer and then someone sends >>a normal text file (which gets converted to postscript via the transcript >>program "pstext", but I've used "enscript" also with the same results), the >>CorelDraw image comes out just fine but the text file gets printed in a >>little tiny font and in mirror image fashion! >> > >We have the same problem on our installation after sending PS-output >from LaTeX (converted with dvips 4.2) to the laser printer. The behavior >Richard described occures exactly for the first page of the next >print job. > Just send a control-D (ASCII 04) to the printer to reset it after running CorelDraw. You can use the DOS echo command "echo ^D>lpt1" (of course, the ^D is what DOS displays when you hold down the ctrl key and hit D, but it sends the correct code). -- Jeff D. Pipkins (uunet!cpqhou!pipkinsj) My disclaimer: My opinions do not necessarily reflect those of my employer. Papaw's disclaimer: I've already told you more than I know.
brown@vidiot.UUCP (Vidiot) (01/03/91)
In article <1991Jan02.190554.5285@cpqhou.uucp> pipkinsj@cpqhou.UUCP (Jeff Pipkins @Adv Dev@SE hou ) writes:
<
<Just send a control-D (ASCII 04) to the printer to reset it after running
<CorelDraw. You can use the DOS echo command "echo ^D>lpt1" (of course,
<the ^D is what DOS displays when you hold down the ctrl key and hit D,
<but it sends the correct code).
According to the new PostScript reference manual, the ^D character is device
dependent and should not be used (page 26).
--
harvard\ att!nicmad\ spool.cs.wisc.edu!astroatc!vidiot!brown
Vidiot ucbvax!uwvax..........!astroatc!vidiot!brown
rutgers/ decvax!nicmad/ INET:<@spool.cs.wisc.edu,@astroatc:brown@vidiot>pipkinsj@cpqhou.uucp (Jeff Pipkins @Adv Dev@SE hou ) (01/05/91)
In article <1196@vidiot.UUCP> brown@vidiot.UUCP (Vidiot) writes: >In article <1991Jan02.190554.5285@cpqhou.uucp> pipkinsj@cpqhou.UUCP (Jeff Pipkins @Adv Dev@SE hou ) writes: >< ><Just send a control-D (ASCII 04) to the printer to reset it after running ><CorelDraw. You can use the DOS echo command "echo ^D>lpt1" (of course, ><the ^D is what DOS displays when you hold down the ctrl key and hit D, ><but it sends the correct code). > >According to the new PostScript reference manual, the ^D character is device >dependent and should not be used (page 26). That's an interesting statement. The ^D scheme is implemented in every PostScript printer ever shipped. What alternative, if any, is offered by page 26? -- Jeff D. Pipkins (uunet!cpqhou!pipkinsj) My disclaimer: My opinions do not necessarily reflect those of my employer. Papaw's disclaimer: I've already told you more than I know.
henry@angel.Eng.Sun.COM (Henry McGilton) (01/05/91)
In article <1991Jan04.173636.9674@cpqhou.uucp>, pipkinsj@cpqhou.uucp (Jeff Pipkins @Adv Dev@SE hou ) writes: *** Just send a control-D (ASCII 04) to the printer to reset it after *** running CorelDraw. You can use the DOS echo command "echo *** ^D>lpt1" (of course, the ^D is what DOS displays when you hold *** down the ctrl key and hit D, but it sends the correct code). In article <1196@vidiot.UUCP> brown@vidiot.UUCP (Vidiot) writes: ** According to the new PostScript reference manual, the ^D ** character is device dependent and should not be used (page 26). Vidiot is correct in stating that Control-D characters are device dependent. That does not mean, however, that they should not be used at all -- they can be used with printers that support Control-D. In article <1991Jan02.190554.5285@cpqhou.uucp> pipkinsj@cpqhou.UUCP (Jeff Pipkins @Adv Dev@SE hou ) writes: * That's an interesting statement. The ^D scheme is implemented in * every PostScript printer ever shipped. What alternative, if any, * is offered by page 26? The Control-D character is a device dependent PROTOCOL that some PostScript printers suport. If your particular PostScript printer supports this protocol, it's fine for you to use a Control-D character to indicate End Of Job to the printer in question. If your printer does not support this protocol, as for example, a Linotronic connected via an Ethernet will not, you then must use whatever the defined protocol is for indicating end of job to the printer.
brown@vidiot.UUCP (Vidiot) (01/05/91)
In article <1991Jan04.173636.9674@cpqhou.uucp> pipkinsj@cpqhou.UUCP (Jeff Pipkins @Adv Dev@SE hou ) writes: <In article <1196@vidiot.UUCP> brown@vidiot.UUCP (Vidiot) writes: <>In article <1991Jan02.190554.5285@cpqhou.uucp> pipkinsj@cpqhou.UUCP (Jeff Pipkins @Adv Dev@SE hou ) writes: <>< <><Just send a control-D (ASCII 04) to the printer to reset it after running <><CorelDraw. You can use the DOS echo command "echo ^D>lpt1" (of course, <><the ^D is what DOS displays when you hold down the ctrl key and hit D, <><but it sends the correct code). <> <>According to the new PostScript reference manual, the ^D character is device <>dependent and should not be used (page 26). < <That's an interesting statement. The ^D scheme is implemented in every <PostScript printer ever shipped. What alternative, if any, is offered by <page 26? Unusual for me to say or unusual for Adobe to say? In any event that is what the book says and they give no alternative. Is the ^D supposed to clear all of VM and restore the printer to a "power-up" state? -- harvard\ att!nicmad\ spool.cs.wisc.edu!astroatc!vidiot!brown Vidiot ucbvax!uwvax..........!astroatc!vidiot!brown rutgers/ decvax!nicmad/ INET:<@spool.cs.wisc.edu,@astroatc:brown@vidiot>
louie@sayshell.umd.edu (Louis A. Mamakos) (01/06/91)
<That's an interesting statement. The ^D scheme is implemented in every <PostScript printer ever shipped. What alternative, if any, is offered by <page 26? Err, excuse me.. The two Ethernet attached DEC PostScript printers that I use know nothing at all about control-D characters. Please.. the control-D character IS NOT PART OF THE PostScript LANGUAGE. It is a mechanism for indicating ``end of file'' on most serially attached PostScript printers; but that is not the case when you use Appletalk or a TCP connection across an Ethernet to talk to your PostScript printer. louie
pipkinsj@cpqhou.uucp (Jeff Pipkins @Adv Dev@SE hou ) (01/08/91)
The question I responded to specified a parallel interface. Ctrl-D's are only for parallel and serial interfaces, and as many of you have pointed out, have no place in network sessions such as Appletalk, Ethernet, or whatevernet. It is true that the Ctrl-D character is not part of the PostScript language itself. The PostScript language has no convention for marking the end of a job! If you are connected to a network, then finding the end of the job is no problem, since the protocol implies that information (end of file == end of job). If you are connected to serial or parallel, then the printer itself (or other graphics device) needs to know when the job ends. All Adobe PostScript implementations on every device I have ever heard of use the Ctrl-D to mark the end of the job on parallel or serial channels. This does not mean that it's part of the language -- but it seems to be a part of Adobe's implementation of the PostScript language. In reference to what actually happens: before running a job, the PostScript interpreter's "server loop" does a "save". When PostScript gets a Ctrl-D (over the parallel or serial port) it does a "restore" (thereby reclaiming VM) and then another "save" for the next job. That's why you have to exit the server loop to make changes that persist from job to job. BTW, the Ctrl-C character (over parallel or serial) "cancels" the current job, but I'm not completely sure what is meant by that, nor whether it is implemented the same in all cases. On the serial channel only, you can send a Ctrl-T and it will send a short status string back. This is also clearly not part of the PostScript language, but it is there in most implementations. Well, there's the can of worms. Everybody dig in... -- Jeff D. Pipkins (uunet!cpqhou!pipkinsj) My disclaimer: My opinions do not necessarily reflect those of my employer. Papaw's disclaimer: I've already told you more than I know.
louie@sayshell.umd.edu (Louis A. Mamakos) (01/08/91)
In article <1991Jan07.165702.26015@cpqhou.uucp> pipkinsj@cpqhou.UUCP (Jeff Pipkins @Adv Dev@SE hou ) writes: >device I have ever heard of use the Ctrl-D to mark the end of the job >on parallel or serial channels. This does not mean that it's part of the >language -- but it seems to be a part of Adobe's implementation of the >PostScript language. No, its an implementation of a communications facility that allows you to submit jobs to the PostScript interpreter. In my mind, the distiction is importatnt. On an Ethernet attached DEC LPS40, you send an OP_EOJ (end of job) opcode on the TCP connection to distinguish between different jobs of the same print session. Normal PostScript program text is transmitted to the printer across the TCP connection using an OP_DATA opcode, for example. >BTW, the Ctrl-C character (over parallel or serial) "cancels" the current >job, but I'm not completely sure what is meant by that, nor whether it >is implemented the same in all cases. A control-C character on a serial or parallel printer causes an "interrupt" error condition for the currently executing job. On an Ethernet attached DEC LPS40, you send an OP_KILL opcode as TCP urgent data to accomplish the same thing. In the case of status messages, the DEC LPS40 printer transmits logging and status messages on seperate TCP connecton(s) to one or more management servers on the network. It a bit of a different way of looking at that particular issue, since multiple hosts can submit jobs to the same printer. In the case of my personal NEC LC-890 PostScript printer, control-T doesn't do anything too useful on the parallel port. If you make a distinction between the PostScript program which puts marks on the page from the details of how you shove the bits from here to there, you don't get yourself into too many problems. Perhaps in the future, PostScript printer on network can access NFS servers directly, and we simply give them the name of the PostScript file to print which resides somewhere on an insititutional filesystem. Or perhaps Adobe will implement the 8 bit transparent serial channel on some PostScript printer products which specifies who to escape link control character codes. There's an interesting document on the Adobe archive server that discusses how this might be done. The wonderful thing about PostScript is that the applications which generate PostScript files can be ignorant of the mechanisms used to print them. louie