home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / compress / 4473 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  1.7 KB
  1. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!sgiblab!adagio.panasonic.com!nntp-server.caltech.edu!madler
  2. From: madler@cco.caltech.edu (Mark Adler)
  3. Newsgroups: comp.compression
  4. Subject: Re: pkzip 2.04c / unzip v5.0 compatibility
  5. Date: 8 Jan 1993 18:03:05 GMT
  6. Organization: California Institute of Technology, Pasadena
  7. Lines: 26
  8. Message-ID: <1ikfkpINN4me@gap.caltech.edu>
  9. References: <1ied29INN37p@butler.cc.tut.fi> <1if4d6INNpgs@gap.caltech.edu> <1993Jan8.142251.17607@murdoch.acc.Virginia.EDU>
  10. NNTP-Posting-Host: sandman.caltech.edu
  11.  
  12.  
  13. >>   I thought PKZip's and Info-Zip's compression engines were identical,
  14. >> but maybe PKWare sacrificed some compression efficiency for speed, as
  15.  
  16. No, they are certainly not identical.  At least on the assumption that
  17. the Katz patent has something to do with his compression algorithm.
  18. However both algorithms can trade speed for compression by changing
  19. some simple parameters.
  20.  
  21. What is identical is the *format* of the compressed data, which
  22. essentially defines what a zip decompressor has to do.  It does not
  23. put any restrictions on how that compressed data stream is generated.
  24. In particular, it does not say how matching strings are found.
  25.  
  26. In this way you can have compressors with very different speed and
  27. compression performance, yet a single decompressor can work with all
  28. of them.
  29.  
  30. This basic principle is what allows competing companies to agree on
  31. standard compressed data streams, like JPEG, JBIG, MPEG, etc.  The
  32. standard allows common decoders for the format, but the companies
  33. compete with more efficient and more effective *encoders*, as wellas
  34. cheaper or better implementations of the decoders.
  35.  
  36. Mark Adler
  37. madler@cco.caltech.edu
  38.