-----BEGIN PGP SIGNED MESSAGE-----


 ============================================================================
 LZO -- a real-time data compression library
 ============================================================================

 Author  : Markus Franz Xaver Johannes Oberhumer
           <markus.oberhumer@jk.uni-linz.ac.at>
           http://www.infosys.tuwien.ac.at/Staff/lux/marco/lzo.html
 Version : 1.01
 Date    : 10-Aug-1997


 Abstract
 --------
 LZO is a portable lossless data compression library written in ANSI C.
 It offers pretty fast compression and very fast decompression.
 Decompression requires no memory.

 In addition there are slower compression levels achieving a quite
 competitive compression ratio while still decompressing at
 this very high speed.

 LZO is distributed under the GNU General Public License.


 Introduction
 ------------
 LZO is a data compression library which is suitable for data
 de-/compression in real-time. This means it favours speed
 over compression ratio.
 I named it LZO standing for Lempel-Ziv-Oberhumer.

 LZO is written in ANSI C. Both the source code and the compressed
 data format are designed to be portable across platforms, and LZO
 should work on each architecture that has at least 32 bit integers.
 Support for some popular 16 bit systems (DOS, Win 3.1) is provided
 as well.

 The LZO implements a number of algorithms with the following features:

 - Decompression is simple and *very* fast.
 - Requires no memory for decompression.
 - Compression is pretty fast.
 - Requires 64 kB of memory for compression.
 - Allows you to dial up extra compression at a speed cost in the
   compressor. The speed of the decompressor is not reduced.
 - Includes compression levels for generating pre-compressed
   data which achieve a quite competitive compression ratio.
 - There is also a compression level which needs only 8 kB for compression.
 - Algorithm is thread safe.
 - Algorithm is lossless.


 Design criteria
 ---------------
 LZO was designed with speed in mind. Decompressor speed has been
 favoured over compressor speed. Real-time decompression should be
 possible for virtually any application. The implementation of the
 LZO1X decompressor in optimized i386 assembler code runs about at
 the third of the speed of a memcpy() - and even faster for many files.

 In fact, I first wrote the decompressor of each algorithm thereby
 defining the compressed data format, verified it with manually created
 test data and at last added the compressor.


 Performance
 -----------
 To keep you interested, here is an overview of the average results
 when compressing the (in-)famous Calgary Corpus test suite with
 a blocksize of 256 kB, running on my Intel Pentium 133.

 This release includes the 8 algorithms LZO1, LZO1A, LZO1B, LZO1C,
 LZO1F, LZO1X, LZO1Y and LZO2A.
 I first published LZO1 and LZO1A in the Internet newsgroups
 comp.compression and comp.compression.research in March 1996.
 They are mainly included for compatibility reasons. The LZO2A
 decompressor is too slow, and there is no fast compressor anyway.
 So the algorithms of current interest are LZO1B, LZO1C, LZO1F,
 LZO1X and LZO1Y. Each of these has a slightly different characteristics,
 and it seems that the LZO1X algorithm is a good overall
 choice for a wide range of data.

 The naming convention of the algorithms goes LZOxx-N, where N is the
 compression level. Range 1-9 indicates the fast standard levels using
 64kB memory for compression. Level 99 offers better compression at the
 cost of more memory (256kB), and is still reasonable fast.
 Level 999 achieves nearly optimal compression - but it is slow
 and uses much memory, and is mainly intended for generating
 pre-compressed data.

 The C version of LZO1X-1 is about 4-5 times faster than the fastest
 zlib compression level, and it also outperforms other algorithms
 like LZRW1-A and LZV in both compression ratio and compression speed
 and decompression speed.

 +------------------------------------------------------------------------+
 | Algorithm        Length  CxB   ComLen  %Remn  Bits   Com K/s   Dec K/s |
 | ---------        ------  ---   ------  -----  ----   -------   ------- |
 | LZO1-1           224401    1   118377   53.5  4.28   5687.73  13972.45 |
 | LZO1-99          224401    1   101560   46.7  3.73   1602.15  14459.92 |
 |                                                                        |
 | LZO1A-1          224401    1   115990   52.0  4.16   5482.72  13932.93 |
 | LZO1A-99         224401    1    99958   45.5  3.64   1595.73  14098.98 |
 |                                                                        |
 | LZO1B-1          224401    1   110653   49.6  3.97   5119.85  15645.77 |
 | LZO1B-2          224401    1   107416   48.6  3.89   4677.83  15781.88 |
 | LZO1B-3          224401    1   105537   47.9  3.83   4282.89  15777.39 |
 | LZO1B-4          224401    1   104828   47.4  3.79   3441.61  15857.98 |
 | LZO1B-5          224401    1   102724   46.7  3.73   3297.94  15926.29 |
 | LZO1B-6          224401    1   101210   46.0  3.68   3037.49  15856.26 |
 | LZO1B-7          224401    1   101388   46.0  3.68   2842.31  15963.64 |
 | LZO1B-8          224401    1    99453   45.2  3.62   2456.49  15908.33 |
 | LZO1B-9          224401    1    99118   45.0  3.60   2110.20  15695.85 |
 | LZO1B-99         224401    1    95399   43.6  3.48   1595.72  15846.76 |
 | LZO1B-999        224401    1    83934   39.1  3.13    207.56  16809.43 |
 |                                                                        |
 | LZO1C-1          224401    1   112051   50.2  4.01   5082.06  15349.74 |
 | LZO1C-2          224401    1   108791   49.1  3.93   4682.43  15462.95 |
 | LZO1C-3          224401    1   106825   48.4  3.87   4262.31  15452.22 |
 | LZO1C-4          224401    1   105717   47.7  3.82   3279.93  15516.57 |
 | LZO1C-5          224401    1   103605   47.0  3.76   3121.57  15625.28 |
 | LZO1C-6          224401    1   102585   46.5  3.72   2956.62  15561.23 |
 | LZO1C-7          224401    1   101937   46.2  3.70   2692.98  15671.02 |
 | LZO1C-8          224401    1   100779   45.6  3.65   2458.58  15645.64 |
 | LZO1C-9          224401    1   100255   45.4  3.63   2050.61  15488.99 |
 | LZO1C-99         224401    1    97252   44.1  3.53   1596.27  15658.23 |
 | LZO1C-999        224401    1    87740   40.2  3.21    332.37  16611.62 |
 |                                                                        |
 | LZO1F-1          224401    1   116765   51.5  4.12   5128.17  15528.79 |
 | LZO1F-999        224401    1    89599   40.3  3.23    303.90  17446.40 |
 |                                                                        |
 | LZO1X-1          224401    1   110368   49.4  3.95   5038.55  15492.75 |
 | LZO1X-1(11)      224401    1   116562   52.0  4.16   5092.90  16133.94 |
 | LZO1X-1(15)      224401    1   111920   50.3  4.02   5641.44  15692.64 |
 | LZO1X-999        224401    1    83763   38.3  3.06    166.77  16803.17 |
 |                                                                        |
 | LZO1Y-1          224401    1   112992   50.2  4.02   4920.30  15519.84 |
 | LZO1Y-999        224401    1    84395   38.4  3.08    167.62  16564.04 |
 |                                                                        |
 | LZO2A-999        224401    1    87880   40.0  3.20    314.41  10352.34 |
 |                                                                        |
 | memcpy()         224401    1   224401  100.0  8.00  67200.57  68348.39 |
 +------------------------------------------------------------------------+

 Notes:
  - The assembler decompressors are even faster

 More detailed results can be found in the `doc' directory.


 Short documentation
 -------------------
 LZO is a block compression algorithm - it compresses and decompresses
 a block of data. Block size must be the same for compression
 and decompression.

 LZO compresses a block of data into matches (a LZ77 sliding dictionary)
 and runs of non-matching literals. LZO takes care about long matches
 and long literal runs so that it produces good results on highly
 redundant data and deals accecptable with non-compressible data.

 When dealing with uncompressible data, LZO expands the input
 block by a maximum of 16 bytes per 1024 bytes input (probably
 only by a maximum of 8 bytes, I still have to compute the exact
 value).

 I have verified LZO using gcc 2.7.2 with Richard W.M. Jones's
 bounds checking patches and compressed gigabytes of files when tuning
 some parameters.
 And I have also consulted various `lint' programs to spot potential
 portability problems.
 LZO is free of any known bugs.


 The algorithms
 --------------
 There are (too) many algorithms implemented. But I want to support
 unlimited backwards compatibility, so I will not reduce the LZO
 distribution in the future (what I had planned some time ago).

 As the many object files are mostly independent of each other, the size
 overhead for an executable statically linked with the LZO library
 is usually pretty low cause the linker will only add the modules that
 you are actually using.

 My experiments have shown that LZO1B is good with a large blocksize
 or with very redundant data, LZO1F is good with a small blocksize or
 with binary data and that LZO1X is often the best choice of all.
 LZO1Y is almost identical to LZO1X - it can achieve a better compression
 ratio on some files. LZO1F seems to compress better than LZO1C on these
 files where LZO1C is better than LZO1B.
 Beware, your mileage may vary.


 Usage of the library
 --------------------
 Despite of its size, the basic usage of LZO is really very simple.

 Let's assume you want to compress some data with LZO1X-1:
   A) compression
      * include <lzo1x.h>
        call lzo_init()
        compress your data with lzo1x_1_compress()
      * link your application with the LZO library
   B) decompression
      * include <lzo1x.h>
        call lzo_init()
        decompress your data with lzo1x_decompress()
      * link your application with the LZO library

 The program examples/simple.c shows a fully working example.
 See also LZO.FAQ for more information.


 Building LZO
 ------------
 Beginning with version 0.21 LZO includes GNU Autoconf support,
 and in 0.90 GNU Automake support was added - this should make the
 building process under UNIX very unproblematic.
 For detailed instructions see the file INSTALL.

 For building under DOS, Windows 3.1/95/NT or OS/2 take a look at the
 file b/00readme.txt.

 Under Linux you can also build an ELF shared library by typing
 'make linux-shared'. Please note that due to the design of the
 ELF executable format the performance of a shared library is a
 little bit slower, so you may want to link your applications
 with the static version (liblzo.a) anyway.

 In case of troubles (like decompression data errors) try recompiling
 everything without optimizations - LZO may break the optimizer
 of your compiler. See the file BUGS.

 LZO is written in ANSI C. In particular this means:
   - your compiler must understand prototypes
   - your compiler must understand prototypes in function pointers
   - your preprocessor must implement #elif, #error and stringizing
   - you must have a conforming and correct <limits.h> header
   - you should have size_t, ptrdiff_t, <stddef.h> and other ANSI C headers


 Portability
 -----------
 I have built and tested LZO successfully on a variety of platforms
 including DOS (16 + 32 bit), Windows 3.1 (16 bit), Windows 95,
 Windows NT, Linux, HPUX and a DEC Alpha workstation (64 bit).

 LZO is also reported to work under AIX, IRIX, ConvexOS, SunOS,
 Solaris and VxWorks.


 The future
 ----------
 LZO is out for a while and it seems the library is pretty stable.

 Here is what I'm planning for the next months. No promises, though...

 - check if gcc optimizer problem is fixed under IRIX
 - actually use libtool to build shared libraries
 - interfaces to Perl, Java and Python
 - improve documentation
 - a Java version of LZO1X-1
 - a stream interface (compatible to zlib) would be nice (and slow ?)


 Some comments about the source code
 -----------------------------------
 Be warned: the main source code in the `src' directory is a
 real pain to understand as I've experimented with hundreds of slightly
 different versions. It contains many #if and some gotos, and
 is completely optimized for speed and not for readability.
 Code sharing of the different algorithms is implemented by stressing
 the preprocessor - this can be really confusing. Lots of marcos and
 assertions don't make things better.

 Nevertheless the sources compile very quiet on a variety of
 compilers with the highest warning levels turned on, even
 in C++ mode.


 Copyright
 ---------
 LZO is Copyright (C) 1996, 1997 Markus Franz Xaver Johannes Oberhumer

 LZO is distributed under the terms of the GNU General Public License (GPL).
 See the file COPYING.

 Special licenses for commercial and other applications which
 are not willing to accept the GNU General Public License
 are available by contacting the author.




-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBM+2os210fyLu8beJAQFMZQP9GsV9oFYkFK+wVAx/7p3ytBChl0SNWhpj
FxelhlpfeBZP8Y5RlZ6KRjF7G2AFQm//rLEg+OK69TZQoripcoJKB3OxhgEtpS0S
dMb5OAxEk3lxBK5ZFIQrnfeLBGECITHbxOsQu26YTYeNLy7WPrsVtn9trzP1M+wV
xvz92Nd2K+k=
=aEMS
-----END PGP SIGNATURE-----
