Xref: utzoo comp.sources.d:2118 comp.binaries.ibm.pc.d:251
Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!pasteur!ames!mailrus!tut.cis.ohio-state.edu!husc6!panda!teddy!jpn
From: jpn@teddy.UUCP (John P. Nelson)
Newsgroups: comp.sources.d,comp.binaries.ibm.pc.d
Subject: Re: Standard for file transmission
Message-ID: <4776@teddy.UUCP>
Date: 16 May 88 14:06:50 GMT
References: <292@cullsj.UUCP> <696@fig.bbn.com> <2932@cognos.UUCP> <3055@encore.UUCP>
Reply-To: jpn@teddy.UUCP (John P. Nelson)
Organization: GenRad, Inc., Concord, Mass.
Lines: 28

>The point is that an article which contains binary thats compressed and then
>uuencode/btoa/your_favorite'd will lower the compression ration for the batch
>that contains it.  The overall size of the batch will be smaller if the
>included binary was just uuencoded, etc.

If this was TRUE, it would be a good argument.  It is NOT true.

Most binary files that are compressed, uuencoded, then compressed again
are SMALLER than binary files that are simply uuencoded, then
compressed.  I have yet to see anyone post results that refute this.

A few people have pointed out counter-examples:  These usually involve
compressing an ARC file (or other binary file with very little
compressability in the first place).  The few cases I have seen where
using ARC (which will NOT try to compress a file that is
uncompressable), followed by uuencode, followed by compress generates a
larger file than uuencode/compress alone, the file lengths were within
1% of each other.

If someone has seen different results, I would be interested in seeing
them.  I already KNOW that compressing ASCII files (source or text)
then uuencoding is a bad idea:  I am interested in results from BINARY
FILES only!  I think we should SETTLE this issue once and for all!
-- 
     john nelson

UUCP:            {decvax,mit-eddie}!genrad!teddy!jpn
ARPA (sort of):  talcott.harvard.edu!panda!teddy!jpn