Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!aplcen!jhunix!hsu_wh
From: hsu_wh@jhunix.HCF.JHU.EDU (William H Hsu)
Newsgroups: comp.compression
Subject: How StuffIt works
Keywords: stuffit, speed, UNIX compress
Message-ID: <8824@jhunix.HCF.JHU.EDU>
Date: 26 Jun 91 01:12:59 GMT
Organization: The Johns Hopkins University - HCF
Lines: 16


	First of all, why is Stuffit so relatively inefficient?  I can't see
why there is such a high overhead for being a Mac application (Compact Pro
seems to do fine).  And there seems to be an "expensive" header length for
small files (< 5K).  Even the compression ratio is unimpressive.
	According to the October 1990 MacTutor article on LZW on the Mac,
Stuffit uses the UNIX compress 14-bit scheme.  From the graph recently
posted, I see that compress ranks fairly high.  Why the discrepancy (rather
large)?

	Another question: how does Stuffit (and other compression programs),
in Ray Lau's words, "determine the characteristics of the input data"?  Can
someone please direct me to such scanning code -- the kinds which determines
whether a file is binary/non-, text/non-, color/TIFF&RIFF/PICT/etc graphics,
DSAD'able data, an image (fit for lossy compression), or fractal data (if
there exists a standard format)?