wls@astrovax.UUCP (William L. Sebok) (02/17/86)
In net.sources.mac <678@aicchi.UUCP> David B. (Ben) Burch writes about stf,
a compression program that gives, for his examples, compression of 16% and 18%.
Has anyone yet ported the Unix compress program to the Macintosh? That program
is getting to be very common on Unix systems and in my experience tends to give
about 50% compression on text.
--
Bill Sebok Princeton University, Astrophysics
{allegra,akgua,cbosgd,decvax,ihnp4,noao,philabs,princeton,vax135}!astrovax!wlshogan@rosevax.UUCP (Andy Hogan) (02/18/86)
>In net.sources.mac <678@aicchi.UUCP> David B. (Ben) Burch writes about stf, >a compression program that gives, for his examples, compression of 16% and 18%. >Has anyone yet ported the Unix compress program to the Macintosh? That program >is getting to be very common on Unix systems and in my experience tends to give >about 50% compression on text. >-- >Bill Sebok Princeton University, Astrophysics I did a quick test on 13 binhex'd files with compress, and got an average compression of 29.5%. This would indicate that we could save a quarter to a third of the length of these postings using a good compression algorithm. But before porting compress to the Mac, let me suggest two alternatives: * use "compress" on binhex'd files before posting and "uncompress" after recieving. Would depend on whether "all" sites have the programs and if compressed files are mailable. Uncompress-ing is a lot more bearable on a VAX than a Mac. * incorporate a compress-style packing algorithm in a new version of binhex. Keep backward compatibility, of course, and keep postings of the new format down until "all" sites had successfully gotten the new binhex. (Wasn't this the difference between two of the binhex versions? Some data compression, I mean?) This could be an option, like the line feed filtering. Is either of these feasible/desirable? It's not that I don't think the basic idea is good; I just hate taking more time to do the uncompression than necessary. You can fire up a whole bunch of uncompress-ing in the background of a UNIX box and do something else (like read news), but Mac just spins the disk for a while on one file at a time...... -- Andy Hogan Rosemount, Inc. Mpls MN path: ...ihnp4!stolaf!umn-cs!mmm!rosevax!hogan Working is not a synonym for Quality.
thomas@utah-gr.UUCP (02/19/86)
In article <308@rosevax.UUCP> hogan@rosevax.UUCP (Andy Hogan) writes: > * use "compress" on binhex'd files before posting and "uncompress" > after recieving. > > * incorporate a compress-style packing algorithm in a new version > of binhex. The first is not a good idea, because compressed files use all 8 bits of each byte, and are therfore not mailable. uuencoding them to mail makes a file almost as big as the original binhex. The 30% you see from compress is basically the difference between a file full of printing characters and one full of 8 bit characters. Further evidence is that the compressed binhex file is about the same size as the original binary! Here is an example, based on a binhex file I just happened to have sitting around: size file 0 RamStart.data These three are the original file 128 RamStart.info 25804 RamStart.rsrc 35104 ramstart The BinHex 4.0 version (with mail headers) 23689 ramstart.Z Compressed version of above 32672 ram.uu uuencoded version of above. It would appear that the compression algorithm in BinHex 4.0 could be improved on somewhat, but that might make it run slower (compress isn't exactly a speed daemon). The results above were obtained using a 16 bit version of compress (that uses several megabytes of memory). A smaller version, suitable for executing on a skinny mac would use 12 bits for compression, yielding a result not as good. 27543 .i/ramstart.12.Z BinHex compressed with bits=12 Applying compress to the binary and the uuencoding gives a better result than BinHex for this program, though: 19698 RamStart.rsrc.Z Rsrc file compressed with bits=12 27172 RamStart.uu Uuencoded version. 35104 ramstart The BinHex 4.0 version (with mail headers) Anybody want to build the compress algorithm into BinHex (making binhex 6.0?) -- =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA)
wls@astrovax.UUCP (William L. Sebok) (02/28/86)
>> * use "compress" on binhex'd files before posting and "uncompress" >> after recieving. >> >> * incorporate a compress-style packing algorithm in a new version >> of binhex. > > The first is not a good idea, because compressed files use all 8 bits of > each byte, and are therfore not mailable. uuencoding them to mail makes > a file almost as big as the original binhex. The 30% you see from > compress is basically the difference between a file full of printing > characters and one full of 8 bit characters. I suggest using the btoa and atob programs which were distributed with compress rather than uuencode and uudecode. btoa produces smaller output than uuencode does. If one has compress then one should also have these two programs. I typically get a 30% total space saving for text after applying compress, then btoa. It was a great way to mail hack to my brother. Sorry for the delay in this reply, but I ordinarily don't read this group. -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,cbosgd,decvax,ihnp4,noao,philabs,princeton,vax135}!astrovax!wls