🚀 go-pugleaf

In article <UNILRH.92Mar30133738@uts.uni-c.dk> unilrh@uts.uni-c.dk (Leif R|dgaard) writes:
>Our bootle-neck is the slow (38.400baud) serial line to the printer,
>where a 4mbyte picture will take 1000 seconds equals about 20 minutes
>transmittion-time. Here it would be nice to be able to compress (run-length-
>encoded or otherwise) before sending the file to the printer, and have
>the postscript-device uncompress the file from the serial line. Just a
>factor a 4 would reduce the transmittion time to 5 minutes.

This brings to mind a question I've had: I'm using a simple RLE scheme
I hacked to shrink the hex representation of bitmaps during the conversion
from binary to postscript.  The ps code includes a decompressor.  Anyway,
the question is this: I'm running the serial line at 38.4 as well, and the
PS interpreter continually drops CTS (equivalent to an XOFF) during 
transmission while it decompresses the incoming data stream.  The routine
to decompress the data is small and fast and simple--on most images there
is about a 6-to-1 expansion.  I'm hitting a basic speed limit in the
interpreter right?  No matter how much faster I get the serial line, no 
matter how much more compression is done, the interpreter is now telling
me it is maxed, right?  If so, the standard math (represented above by
4 meg. in 5 min.) really doesn't apply to the real world situation.  The
first solution would be to get a faster interpreter, then seeing how
often CTS comes down, then optimizing the compression, right?  Thanks for 
any input!
-- 
JeffCarey,jeffc@microsoft.com,{uunet,uw-beaver,sun,sco,decvax}!microsoft!jeffc