🚀 go-pugleaf

In article <1991Mar26.171046.12170@pbs.org>, ctice@pbs.org writes:
|> 
|> Hello!  I have recently run into what appears to be a strange anomaly in a bit
|> of PostScript code, and I was wondering if anyone out there has seen anything
|> similar or could explain what is going on.  The problem I am having is with the
|> PostScript IMAGE operator.  I took a photograph and scanned it.  I then used
|> Adobe Photoshop (tm) to translate the scanned image into an EPS file.  When I
|> opened the EPS file to look at what was done the EPS code didn't make sense. 
|> It said that my scanned data was 497 samples wide, 673 samples high, with one
|> bit per sample.  So far so good.  But the string it was using to read in the
|> hex data was of size 63.  Now according to everything I have read and/or been
|> taught, the width x height x bits per sample must be evenly divisible by the
|> string size.  496 * 673 * 1 = 344,481.   344,481 / 63 = 5309.2222...  So it
|> would seem that the code as generated by Photoshop (tm) shouldn't work. 
|> However it works like a charm.  Even more confusing, if I change the string
|> size to 497, which DOES divide evenly into 497*673, nothing prints out at all. 
|> Could somebody explain what is going on?  PLEASE?
|> 
|> 						Caroline Tice
|> 						PBS


The image operator expects each scanline of the image to be padded to
a byte boundary.  Your 497-sample wide image is only 1-bit per sample
and therefore has to be padded to the nearest byte.  A single scanline
thus requires

   (497 + 7) / 8 = 63 

bytes of data.  Hence the magic number 63.

-- Rich