humtech@ucschu.ucsc.edu (Mark Frost) (11/18/89)
Hello. I'm very new to postscript. I've been trying to get a 512x512 pixel
bitmap to print on our LaserWriter IINT. For some reason or another, I can
only get 256x256 images to print. When I do a 512x512 all I manage to get
is a blank page. I tried a 256x512 once and got a few pixels on either side
of the page, but the center of the image was blank. I've tried this with
8 bit per sample (the way I get the data from another machine) and 4 bits
per sample. I'm currently trying to scale it down to 1 bit per sample in
hopes that this will help.
The basic code that I'm using is
%!PS-Adobe-1.0
100 400 translate
200 200 scale
512 512 4 [512 0 0 -512 0 512]
{<
...OODLES of hex bytes go here...
>} image
showpage
I've had to print out several 256x256 pages and cut and paste (literally).
The little knowledge I have is from the 2 postscript manuals from adobe
(the "red book" and the "blue book"). As I'm not trying to learn all
about postscript I haven't read them cover to cover. I just need to make
this one project work.
Can anyone out there help me? E-mail me if you can.
Thanx!
Mark Frost
Office of the the Computing Coordinator
Humanities Division
University of California at Santa Cruz
Santa Cruz, California 95064
(408) 459-4603
Internet: humtech@ucschu.UCSC.EDU
Bitnet: humtech@ucschu.bitnet
Uucp: ...!ucbvax!ucscc!ucschu!humtechvgopal@cbnewsc.ATT.COM (venu.p.gopal) (11/21/89)
In article <9790@saturn.ucsc.edu> humtech@ucschu.ucsc.edu (Mark Frost) writes:
!Hello. I'm very new to postscript. I've been trying to get a 512x512 pixel
!bitmap to print on our LaserWriter IINT. For some reason or another, I can
!only get 256x256 images to print. When I do a 512x512 all I manage to get
!is a blank page. I tried a 256x512 once and got a few pixels on either side
!of the page, but the center of the image was blank. I've tried this with
!8 bit per sample (the way I get the data from another machine) and 4 bits
!per sample. I'm currently trying to scale it down to 1 bit per sample in
!hopes that this will help.
Most likely your problem is that of limited virtual memory. When the
image is read in, it is stored (before the image operator can "operate")
- and you may run out of memory before the entire image can be read in.
Solution - simply break up the image into smaller images and use
multiple "image" operators.
Hope that helps.
Venu P. Gopal UUCP: ..!att!ihuxy!vgopal Internet: vgopal@ihuxy.att.comhenry%angel@Sun.COM (Henry McGilton -- Software Products) (11/27/89)
In article <9790@saturn.ucsc.edu>, humtech@ucschu.ucsc.edu (Mark Frost) writes: * Hello. I'm very new to postscript. I've been trying to * get a 512x512 pixel bitmap to print on our LaserWriter * IINT. For some reason or another, I can only get * 256x256 images to print. When I do a 512x512 all I * manage to get is a blank page. I tried a 256x512 once * and got a few pixels on either side of the page, but * the center of the image was blank. I've tried this with * 8 bit per sample (the way I get the data from another * machine) and 4 bits per sample. I'm currently trying to * scale it down to 1 bit per sample in hopes that this will help. * The basic code that I'm using is %!PS-Adobe-1.0 100 400 translate 200 200 scale 512 512 4 [512 0 0 -512 0 512] {< ...OODLES of hex bytes go here... >} image showpage The basic problem with this approach is that the {< . . . >} code sequence is placing a hexadecimal string on the stack. Strings are limited in length to 65535 bytes (documented on page 260 of my Red Book). When you have a 256 x 256 x 4 bit image, this translates into 32768 bytes of data, and when you double that (two hex characters per byte) you have a string of 65536 bytes (one too many, which will probably go unnoticed. But, when you have a 512 x 512 x 4 bit image, this translates into 262144 bytes of image data, which is four times the allowable length of a string. You are much better off doing it the open ended way by using readhexstring to get the bytes from the current file. Take a look at the turkey example on page 149 of the Blue Book for a starting point. ............. Henry +------------------+------------------------+---------------------------+ | Henry McGilton | I saw the future, | arpa: hmcgilton@sun.com | | Sun Microsystems | and it didn't work. | uucp: ...!sun!angel!henry | | Mt. View, CA | | | +------------------+------------------------+---------------------------+
rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (11/27/89)
> The basic problem with this approach is that the > {< . . . >} > code sequence is placing a hexadecimal string on the stack. > Strings are limited in length to 65535 bytes (documented on > page 260 of my Red Book). When you have a 256 x 256 x 4 > bit image, this translates into 32768 bytes of data, and > when you double that (two hex characters per byte) you have Just a minor nit. Actually, the <...> syntax requires 2n+2 bytes to represent a string of length n, but that string requires only n bytes (plus 8 or so overhead) inside of the printer. So you can have a string of length 65535 represented with 131072 input bytes with no troubles. In other words, the string <0001020304050607> requires only eight bytes (plus some minor overhead) inside the printer . . . -tom