bowen@sunybcs (Devon E Bowen) (05/11/88)
I'm having a problem with printing a bitmap. Originally the bitmap was
560 by 189. I used the image command as given in the example in the red
book (I had it stored in hex). This worked exactly as I expected.
After looking at the image I noticed a few lines in the bitmap data
had repeated themselves in the data file. No problem, I just went in
and deleted the lines (there were 8 of them) and changed the image
size parameters to be 560 by 181. Now it doesn't work! I have no idea
why. I finally fixed it by putting an extra 8 lines of F's at the end
of the data and changing the image row parameter back to 189. This
worked ok, but it's a waste to transmit 8 lines of null data. Does
anyone have any idea why eliminating these lines would break it? I
even watched the stdout on the tty and it didn't print any errors. It's
as though I never send the data.
I'm working on a LaserWriter NTX (I didn't try it on a LaserWriter
plus). Could it be a bug in the firmware? If there is any interest I
could try to put together a small PostScript program for you. Any
help is appreciated.
Devon Bowen (KA2NRC)
University at Buffalo
*********************************************************
uucp: ..!{ames,boulder,decvax,rutgers}!sunybcs!bowen
Internet: bowen@cs.Buffalo.EDU
BITNET: bowen@sunybcs.BITNET
*********************************************************mark@hpcvlx.HP.COM (Mark Rowe) (05/11/88)
Check the amount of data read by the data acquisition procedure (the fifth parameter to the image statement. This procedure is called a sufficient number of times to get the necessary amount of information, but does not know how much information is needed. Therefore, the final call to this procedure may read past the end of the actual data. In order to avoid having to pad data at the end of the image data it is necessary that the total number of bytes required by the image be an exact multiple of the number of bytes returned by the procedure. Mark Rowe mark@hp-pcd
johng@ecrcvax.UUCP (John Gregor) (05/18/88)
In article <11116@sunybcs.UUCP> bowen@sunybcs.UUCP (Devon E Bowen) writes: >I'm having a problem with printing a bitmap. >[ goes on to say that bitmap of one size works while another size doesn't] Yes, I've had that problem also. It seems rather arbitrary. It isn't the largest (in either or both dimensions) bitmaps or the smallest that fail. Padding with 00's or ff's always fix the problem. If I could predict which bitmaps caused the problems, I would pad them automatically. So far, the only trend I've seen is that one or both dimensions had a relatively large prime as a factor (but not always). Could it be some bug in partitioning the bitmap? More likely it's just another example of how humans impose patterns on random data. At least I know I'm not the only one... -- pqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpqpq bdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbdbd John Gregor johng%ecrcvax.UUCP@germany.CSNET