fritz@timer1.UUCP (fritz) (10/06/89)
I have several postscript files which are roughly 80000 bytes long. When I send them through a spooler, every fourth file is non-existent, no page or anything. When I send 13 of these, I get 1,2,3,5,6,7,9,10,11,13 printed. If I shorten these files to 2500 bytes, I will get 1,2,3,8,9,10,14,15,16 I SUSPECT that an error occurs every fourth file and that the printer, an NEC LC-890, dumps its buffer and reads until an EOF. For large files, the printer will dump its buffer and read to the end of the fourth file. For small files, (a few might be in the printer) the printer will dump its buffer and read to EOF of the next file waiting. In either case, after the printer starts printing again, the cycle repeats itself. If I change the order of the printouts, the same cycles are repeated. This means that the unprinted files are actually printable. Virtual memory usage in the printed files is at around 106000 of 240000. Save nesting is 2. No dictionaries are out of bounds. stacks are not out of bounds. xon/xoff appears to be working properly. If anyone has any advice, I would appreciate hearing from you. Thank You, fritz concannon Rightime Econometrics, Inc. uunet!timer1!fritz Disclaimer: Nothing I say can be construed as opinions of management
klg@dukeac.UUCP (Kim Greer) (10/12/89)
In article <370@timer1.UUCP> fritz@timer1.UUCP (fritz) writes: >I have several postscript files which are roughly 80000 bytes >long. When I send them through a spooler, every fourth file >is non-existent, no page or anything. > >When I send 13 of these, I get 1,2,3,5,6,7,9,10,11,13 printed. >If I shorten these files to 2500 bytes, I will get >1,2,3,8,9,10,14,15,16 > >I SUSPECT that an error occurs every fourth file and that the printer, >an NEC LC-890, dumps its buffer and reads until an EOF. For large I have noticed this very same type of thing with the same printer, *after* I tried switching from 4800 baud to 9600 (but still without xon/xoff alas). Several "pages" in the same file (these were grayscale images coming from stdio into lpr) would fail to print, but if split up and printed a minute or so apart would do just fine. My "solution": put a "sleep 30" in a shell script wrapper to give each image time to finish before the next set would come along. This "works" in that overall print time is still less than at 4800 baud. BTW: I have had no problems that I know of with character (and simple graphics) oriented output.
syd@DSI.COM (Syd Weinstein) (10/13/89)
klg@dukeac.UUCP (Kim Greer) writes: :In article <370@timer1.UUCP> fritz@timer1.UUCP (fritz) writes: :>I SUSPECT that an error occurs every fourth file and that the printer, :>an NEC LC-890, dumps its buffer and reads until an EOF. For large : I have noticed this very same type of thing with the same printer, :*after* I tried switching from 4800 baud to 9600 (but still without xon/xoff :alas). Several "pages" in the same file (these were grayscale images :coming from stdio into lpr) would fail to print, but if split up and printed :a minute or so apart would do just fine. My "solution": put a "sleep 30" :in a shell script wrapper to give each image time to finish before :the next set would come along. This "works" in that overall print :time is still less than at 4800 baud. BTW: I have had no problems that :I know of with character (and simple graphics) oriented output. What you need to do is teach you spooler to wait for the 'IDLE' acknowledge to a status query before sending the next job. Postscript printers don't like the jobs coming in back to back like that. They loose info when they do a end of job reset. (Especially true for the LC890). The status query is control-t, and it will reply in ascii the status of the printer (just like what is displayed on the lcd on the front of the lc890). Just poll it every 5 seconds or so after the job has been sent and that will tell you exactly how long to wait. We send our lc890 the output at 19200 and it does fine this way, and 19200 is noticably faster than 9600 for us also. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or {bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235