🚀 go-pugleaf

[ 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