Path: utzoo!attcan!uunet!aplcen!haven!uvaarpa!murdoch!amber.cs.Virginia.EDU!rwl From: rwl@amber.cs.Virginia.EDU (Ray Lubinsky) Newsgroups: comp.lang.postscript Subject: Re: Bitmap decompression wanted Message-ID: <1990Jul11.184532.520@murdoch.acc.Virginia.EDU> Date: 11 Jul 90 18:45:32 GMT References: <8561@cognos.UUCP> <1990Jul5.205445.8084@kth.se> Sender: news@murdoch.acc.Virginia.EDU Reply-To: rwl@uvacs.cs.Virginia.EDU Organization: UVa Computer Science Dept. Lines: 34 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) |