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
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