dma@pcssc.UUCP (Dave Armbrust) (10/05/90)
Under SCO UNIX 3.2 there seems to be major problem with using raster graphics on a HP Laserjet printer. This is a major problem for our software firm. If the problem can not be worked around we will not be able to market SCO Unix to our customers. All systems we sell include HP lasersjets. What happens is that when a file is sent to the laserjet it causes a major slow down. I sent a file that was 5K in size including the raster graphics. I takes 10 MINUTES to print the file. Once the page was finally printed it contained garbage where the graphics should have appeared. When I remove the raster graphics from the file everything works fine. The problem still occurs regardless if I use the SCO supplied hpjet model file or not. The problem also occurs if I cat the file directly to the port (/dev/lp0). The problem may be the binary 8 bit data being sent through the parallel printer driver. The data contained in the byte stream is virtually random and any values between the value of 0x00 and 0xFF is valid. Therefore any combinations of bytes could be sent. Both the characters 0x00 and 0xFF is common in the byte steam that is being sent. The files also print fine using the same printer etc.. under DOS (7 seconds). The files print fine using the same printer etc.. under SCO Xenix (11 seconds). The files do at times seem to printer slower under SCO Xenix then it should but the speed under SCO Xenix is marketable. The speed, disregarding the garbage, under SCO UNIX is not. The problem is not limited to one machine as we can duplicate the problem at our site when using raster data with our laserjet. The problem does seem to be limited to (SCO?) UNIX. The problem occurs both with laserjet series II and laserjet series III. When talking to SCO on previous slow parallel printer problems with HP laserjet their response was. "Internally we only use serial interfaces for HP laserjets". For those of you that are not familiar with raster graphics on the laserjet I will explain what it consists of. To tell the printer that you want to start raster graphics at the current page position the following escape sequence is sent for 300 dots per inch resolution. The \033 indicates the escape character. \033*t300R\033*r1A Then for each line of graphics the following is sent. The \033*b#W[raster data] # = Number of bytes in the line of data [raster data] = The bits of raster data (1's and 0's) sent to the printer describe single dots to be printed on the page. The most significant bit (bit 7) of the first byte of data corresponds to the first pixel within that line. A one indicates that the dot is to be printed, and a zero indicates that the dot should not be printed. The following escape sequence informs the printer that all raster graphics data has been transferred to the printer: \033*rB I prefer not to use a serial interface unless this is the only way to solve the problem. A parallel port should be faster then serial. Also a parallel port does not have the problem of print jobs going off into 'never-never' land when the printer is not turned on. All ideas on this problem with be a great help. If anyone has been able to print 'raster graphics' under SCO Unix on a HP Laserjet please let me know as then I will at least know I am not kicking a 'dead horse'. Dave Armbrust | uunet!pcssc!dma PC Software Systems | dma@pcssc.com 2121 Cornell Street | Phone: (813)365-1162 Sarasota, FL 34237 | Closing the barn door when a dead gift horse is in mid-stream won't make him drink.
gt0178a@prism.gatech.EDU (Jim Burns) (10/05/90)
in article <4@pcssc.UUCP>, dma@pcssc.UUCP (Dave Armbrust) says: > The problem may be the binary 8 bit data being sent through the parallel > printer driver. Wild guess - is the xfer protocol 8 bits? > I prefer not to use a serial interface unless this is the only > way to solve the problem. A parallel port should be faster > then serial. The limiting factor for graphics should be the processing and printing time, NOT the xfer rate. Also a parallel port does not have the problem > of print jobs going off into 'never-never' land when the > printer is not turned on. True enough. I have the same problem on an HP 9000/800. HP said the hardware protocol used w/ their mux interface doesn't support hardware handshaking, so we're always losing files till someone turns the printer on. Now you tell me PC's do this too?! What's wrong w/unix vis-a-vis serial hardware handshakes? -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
johnl@esegue.segue.boston.ma.us (John R. Levine) (10/05/90)
In article <14574@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (Jim Burns) writes: >The limiting factor for graphics should be the processing and printing >time, NOT the xfer rate. A 6x10" image at 300dpi is over 600K bytes. Even assuming some reasonable zero compression, it's often 400K. If you assume a rather optimistic 10K bytes/sec for your parallel port, that's still 40 seconds per page, which is much slower than the printer prints. -- John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|spdcc|world}!esegue!johnl Atlantic City gamblers lose $8200 per minute. -NY Times
ske@pkmab.se (Kristoffer Eriksson) (10/06/90)
In article <14574@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (Jim Burns) writes: >in article <4@pcssc.UUCP>, dma@pcssc.UUCP (Dave Armbrust) says: > Also a parallel port does not have the problem >> of print jobs going off into 'never-never' land when the >> printer is not turned on. > >True enough. I have the same problem on an HP 9000/800. HP said the >hardware protocol used w/ their mux interface doesn't support hardware >handshaking, so we're always losing files till someone turns the printer >on. You shouldn't need hardware handshaking for that, just a power-on indication (often DTR will do, but unfortunately it doesn't on the old Laserjet I have) going from the printer to the DCD input on the computer port, and I don't expect that the DCD input would be missing on many systems. On my system the lp spooler automatically disables the printer if the printer is off too long (and DCD therefore is inactive), which maybe is not exactly what you want, but it does prevent loss of print jobs. I think hardware handshaking will let the spooler wait indefinitely for the printer to come online and accept input, if you make DCD permanently active, which I suppose is what you really want. However, hardware handshaking is a murky area, and has not been available in the tty drivers from AT&T (don't know about the very latest versions, though). There are unix systems that have added this to their drivers, but they often use incompatible ways to control it. Also, since unix has not required the hardware to be able to handle hardware handshaking, there have been many pieces of hardware constructed for unix without that ability, like the mux interface you have. -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske