Xref: utzoo comp.sources.d:2096 comp.binaries.ibm.pc.d:229
Path: utzoo!attcan!uunet!pilchuck!ssc!happym!kent
From: kent@happym.UUCP (Kent Forschmiedt)
Newsgroups: comp.sources.d,comp.binaries.ibm.pc.d
Subject: Re: compressing compressed stuff
Message-ID: <437@happym.UUCP>
Date: 7 May 88 11:10:04 GMT
References: <292@cullsj.UUCP> <696@fig.bbn.com> <4744@teddy.UUCP> <5198@umn-cs.cs.umn.edu>
Reply-To: kent@happym.UUCP (Kent Forschmiedt)
Organization: Happy Man Corp.
Lines: 28

In article <5198@umn-cs.cs.umn.edu> randy@umn-cs.UUCP (Randy Orrison) writes:
[ says that compress and its cousins know better than to mess with a
  file if it won't get smaller.  Suggests that news software won't
  compress, or shouldn't, if stuff is already compressed, so what's
  the problem? ]


News articles are usually collected into batches before 
transmission. 

Some sites eat long articles, so there is a practical limit of
around 50 or 60k on article size.

So, the problem is:

Since many sites transmit batches that are several times that size, 
even the longest article will generally get collected into a file 
with other articles.  When the file is compressed before sending to 
another site, a file which is already 40% compressed and uuencoded 
will get enough smaller to satisfy compress, but it will not be as 
small as if the big article were only uuencoded.  This is true 
whether the original is random binary or 6 bit text.  Compressing 
twice makes it worse. 

-- 
--
	Kent Forschmiedt -- kent@happym.UUCP, tikal!camco!happym!kent
	Happy Man Corporation  206-282-9598