Xref: utzoo comp.sources.d:2016 comp.binaries.ibm.pc.d:86
Path: utzoo!mnetor!uunet!epiwrl!epimass!jbuck
From: jbuck@epimass.EPI.COM (Joe Buck)
Newsgroups: comp.sources.d,comp.binaries.ibm.pc.d
Subject: Re: Standard for file transmission
Message-ID: <2095@epimass.EPI.COM>
Date: 4 May 88 20:49:31 GMT
References: <292@cullsj.UUCP> <55@psuhcx.psu.edu> <537@csccat.UUCP> <I> <would> <like> <to> <clear> <up> <a> <couple> <of> <notions> <that> <have> <been> <expressed> <over> <296@cullsj.UUCP>
Reply-To: jbuck@epimass.EPI.COM (Joe Buck)
Organization: Entropic Processing, Inc., Cupertino, CA
Lines: 19
Keywords: protocol compression source

In article <296@cullsj.UUCP> jeff@cullsj.UUCP (Jeffrey C. Fried) writes:
>
>  1) COMPRESS is a text only compression routine.  It will not now, or ever,
>     help in the compression of binary files.

Most emphatically wrong.  compress works just fine on many types of
binary files.  It can give 90% or more compression on bitmap data,
and usually > 50% compression on Unix executable files.  About the
only type of file I know of that compress fails on consistently is
floating point data in binary format.  As long some strings of bytes
occur much more frequently than others (whether they represent
characters, opcodes, or grey levels) compress kicks ass.


-- 
- Joe Buck  {uunet,ucbvax,sun,<smart-site>}!epimass.epi.com!jbuck
	    Old Internet mailers: jbuck%epimass.epi.com@uunet.uu.net

Argue for your limitations and you get to keep them.  -- Richard Bach