marc@rna.UUCP (Marc Johnson) (09/27/88)
Many thanks to those who responded to my query about compressing PostScript bitmaps output with the "image" operator. Alas, all the responses (and there were several good ones) gave various methods for compressing the original image data, and then decoding it either in PostScript itself, or just prior to sending to PostScript printer. My problem is not the original image files, but the amount of sheer data being sent to the printer. I want to be able to cut down on the number of bits I actually have to send down the pipe at 9600 baud. I gather that there really is no way to do this, since no one else seemed concerned with the transmission time. If anyone knows a way to send less bits and have it all come out looking right, please let me know!! Thanx, Marc Johnson Rockefeller Univ. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = Marc Johnson BITNET: rna!marc@rockvax.bitnet = = Rockefeller U. Neurobiology UUCP: ...cmcl2!rna!marc = = New York City (129.85.2.1) INTERNET: marc%rna@rocky2.rockefeller.edu =
jef@hot.ee.lbl.gov (Jef Poskanzer) (09/28/88)
I just spent a few hours modifying my pbmtops filter to produce run length
encoded PostScript output. The results are not spectacular for me -- yes,
the files are smaller, but the printing times are about the same. But I'm
printing over the network. If you were stuck with the serial line, this
would be a big win.
I've appended a sample program generated by my filter. If anyone sees
ways to improve the code, please let me know, I'm not much of a PostScript
hacker. This version of pbmtops will be distributed to comp.sources.misc
and expo.lcs.mit.edu sometime in October.
---
Jef
Jef Poskanzer jef@rtsg.ee.lbl.gov ...well!pokey
Prerecorded for this time zone.
- - - - - - - - - -
%! t.ps
/rlestr1 1 string def
/rlestr 128 string def
/readrlestring {
currentfile rlestr1 readhexstring pop 0 get
dup 127 le {
currentfile rlestr 0 4 3 roll 1 add getinterval
readhexstring pop
} {
256 exch sub dup
currentfile rlestr1 readhexstring pop 0 get
exch 0 exch 1 exch 1 sub { rlestr exch 2 index put } for
pop rlestr exch 0 exch getinterval
} ifelse
} def
293 393 translate % move to lower left corner of box
15 15 scale % scale box
16 16 1 % width height bits/sample
[ 16 0 0 -16 0 16 ] % transformation matrix
{ readrlestring } % proc
image
1f000055543ffe7ffc3ffe7ffc3ffe7ffc8003c0018003c0018003c001aa
abffff
showpagejohn@trigraph.UUCP (John Chew) (09/28/88)
In article <271@rna.UUCP> marc@rna.UUCP (Marc Johnson) writes: >Many thanks to those who responded to my query about compressing PostScript >bitmaps output with the "image" operator. > >Alas, all the responses (and there were several good ones) gave various methods >for compressing the original image data, and then decoding it either in >PostScript itself, or just prior to sending to PostScript printer. My problem >is not the original image files, but the amount of sheer data being sent to the >printer. I want to be able to cut down on the number of bits I actually have >to send down the pipe at 9600 baud. I gather that there really is no way to >do this, since no one else seemed concerned with the transmission time. Please take another look at what I posted and sent to you. The reason I wrote the code was to improve transmission time at 2400 baud. It works. The data is compressed at some point before transmission, and is transmitted in compressed form. It does not get uncompressed until it arrives at the PostScript printer, safely past the serial link. John Chew -- john j. chew, iii poslfit@utorgpu.bitnet trigraph, inc. poslfit@gpu.utcs.toronto.edu toronto, canada {uunet!mnetor!utzoo,utgpu,utcsri}!trigraph!john [it is my opinion that these are solely my opinions.]
geof@apolling (Geof Cooper) (09/30/88)
The "frame maker" postscript driver does something like this. What they do is to encode an image as a single byte of command followed by N bytes of argument. The "image" procedure reads the first byte and looks it up in a table of procedures, then executes the procedure, which must consume the "right" amount of input (maybe they have a length field in there too). The procedures do things like replicate a given 8-bit pattern, fill in with zeros, fill in with ones, etc.. The processing time for this is a few percent slower for the interpreter overhead, but most images spend all their time scaling the image, so it isn't too signficant. This kind of compression can help a LOT if an image has significant regions of constant gray (can you say "margins" boys and girls?). Have fun,