knewton@watsup.waterloo.edu (K. Glen Newton) (11/23/89)
i'm having a little bit of a problem with printing 8 bit raster
images. I have some code which works right now, but it uses
"readhexstring" and needs to have hex as input. This is fine except
that the files produced are twice as large as the original character
coded image. Here is the working header (which i got from somewhere?):
%!
currentscreen /proc exch def /angle exch def /frequency exch def
/angle 90 def /frequency 60 def
frequency angle /proc load setscreen
/picstr 313 string def
/screen {313 140 8 [313 0 0 -140 0 140]
{currentfile picstr readhexstring pop} image} def
451 72 translate 90 rotate 648 290 scale screen
3c484b4e4e514a4c4c5154545557564f42424e4f3f3339373d3d383a3d3a3c3f3d36363e3f3d3f42....etc....
I thought that if i just replaced the readhexstring with readstring
and used chars, things would work out fine. But my laser printer does
not like it when it is sent these files and does nothing... here is
the modified header:
%!
currentscreen /proc exch def /angle exch def /frequency exch def
/angle 90 def /frequency 60 def
frequency angle /proc load setscreen
/picstr 313 string def
/screen {313 140 8 [313 0 0 -140 0 140]
{currentfile picstr readstring pop} image} def
451 72 translate 90 rotate 648 290 scale screen
<HKNNQJLLQTTUWVOBBNO?397==8:=:<?=66>?=?B ....etc....
can anyone tell me what is going wrong??
by the way, i am using a QMS 810 which hasn't given us any trouble before..
thanks,
glen newton
knewton@mycologue.waterloo.ca
--
******************************************dhfghansen@cs.wmich.edu ( Jeff Hansen) (11/30/89)
[ Previous poster asks why replacing readhexstring with readstring and ]
[ hex values with ASSCII equivalents his fine image is not created ]
There are a few reasons why this could be fouling up. Is your printer
set for eight bits, no parity? If it is, read on! Using readstring is
lot more riskier than readhexstring - you've got all those pesky control
characters to worry about (remember, we're representing value 0-255).
Take a wild guess what happens when the interpreter slams into the following
values on the LaserWriter and QMS-1500: 3 (ctrl-C), 4 (D), 17 (Q), 19 (S),
and 20 (T). These are all communication character codes, and aren't passed
to the interpreter, so you're out that many characters when you go to print:
readstring compensates by eating up whatever comes after your last image
byte. Here's another brain teaser: what happens at the end of the line?
Now you're getting _too much_ data (the interpreter takes the new line
character as a data byte), and how in the heck are you going to stop that?
There are two ways: both involve "setting up" the data so each line of
data is the exact byte width of your picture (if your picstr is 313 bytes
long, make sure each line in your file is 313 bytes long). The solutions:
1.) { currentfile picstr readline pop } This will read the entire line in,
ignoring the new line character at the end. I'm still wondering what
happens when you get a new line character in the middle somewhere.
2.) { currentfile picstr readstring pop dup 313 255 put } For this
procedure to work, add one to picstr (allowing for the new line char.,
and where the "313" value is, put the value of the original picstr.
What this does is throws the new line character on to the end of the
string, then erases it (white) by tossing a 255 in its place. The
only disadvantage to this (that I can think of) is your boundingbox
is all off-kilter.
With this in mind, let's now turn to some questions I'd like to pose.
There wouldn't be anyway around this "I'll grab that character, thank you"
attitude? I'm avoiding this by multiplying each "bad value" by two (thus
shifting the bits left one, not _really_ noticeable). Especially heinous
is ctrl-Q (17) - it has a nice bit pattern, so appears an average of 5,000
times in an 176K image - as opposed to an average of 2,00 times for all the
other four characters combined (that should be a 200 ^^^). I guess that's
one question.
jeffhansen|||hansen@cs.wmich.edu|||Worship the Fisher-Price dog figurine