🚀 go-pugleaf

In article <1990Jul5.205445.8084@kth.se>, d87-jse@garbo.bion.kth.se
(Joakim Sernbrant) writes:
|> In article <8561@cognos.UUCP> donc@cognos.UUCP () writes:
|> >Has anybody written such a procedure? I would like to try it out on
my sample
|> >data to see if it would gain me anything.
|> >   Any code or ideas would be appreciated.
|> >
|> >                      Don
|> 
|> I have spend many hours on this matter. I have tried runlength
|> encoding and packing six bits into each byte in the image.
|> The result have been dissapointing. Everything I've tried has
|> actually been mush slower than normal. This has been tried mostly
|> with 256 colors GIF images; special images with large white/black
|> areas can be handled with runlength encoding with good results.


I guess this is a perennial question in this newsgroup.  Probably three years
ago, I worked on this problem with similar results.  The upshot is that you
can certainly decrease transmission time by encoding, but the cost of looking
at each and every character within the *interpreted* PostScript program running
in the printer will make just about any strictly-software scheme prohibitive.

Adobe needs to get its act in gear, develop and publish an adequate encoding
scheme, and add a built-in operator to the language that decodes input based on
that encoding scheme.


| Ray Lubinsky                           rwl@uvacs.cs.Virginia.EDU (Internet) |
|                                        rwl@virginia                (BITnet) |
| Department of Computer Science,        ...!uunet!virginia!uvacs!rwl  (UUCP) |
| University of Virginia                 (804) 982-2219               (voice) |