Adding upstream version 1.7~pre1.upstream/1.7_pre1

Signed-off-by: Daniel Baumann <mail@daniel-baumann.ch>

1 files changed, 29 insertions, 21 deletions

diff --git a/doc/clzip.texi b/doc/clzip.texi
index 1640d18..01f5f39 100644
--- a/doc/clzip.texi
+++ b/doc/clzip.texi
@@ -6,8 +6,8 @@
 @finalout
 @c %**end of header
 
-@set UPDATED 28 August 2014
-@set VERSION 1.6
+@set UPDATED 26 February 2015
+@set VERSION 1.7-pre1
 
 @dircategory Data Compression
 @direntry
@@ -45,7 +45,7 @@ This manual is for Clzip (version @value{VERSION}, @value{UPDATED}).
 @end menu
 
 @sp 1
-Copyright @copyright{} 2010-2014 Antonio Diaz Diaz.
+Copyright @copyright{} 2010-2015 Antonio Diaz Diaz.
 
 This manual is free documentation: you have unlimited permission
 to copy, distribute and modify it.
@@ -56,9 +56,9 @@ to copy, distribute and modify it.
 @cindex introduction
 
 Clzip is a lossless data compressor with a user interface similar to the
-one of gzip or bzip2. Clzip decompresses almost as fast as gzip,
-compresses most files more than bzip2, and is better than both from a
-data recovery perspective. Clzip is a clean implementation of the LZMA
+one of gzip or bzip2. Clzip is about as fast as gzip, compresses most
+files more than bzip2, and is better than both from a data recovery
+perspective. Clzip is a clean implementation of the LZMA
 (Lempel-Ziv-Markov chain-Algorithm) "algorithm".
 
 Clzip uses the lzip file format; the files produced by clzip are fully
@@ -66,8 +66,9 @@ compatible with lzip-1.4 or newer, and can be rescued with lziprecover.
 Clzip is in fact a C language version of lzip, intended for embedded
 devices or systems lacking a C++ compiler.
 
-The lzip file format is designed for long-term data archiving, taking
-into account both data integrity and decoder availability:
+The lzip file format is designed for data sharing and long-term
+archiving, taking into account both data integrity and decoder
+availability:
 
 @itemize @bullet
 @item
@@ -86,8 +87,8 @@ data from a lzip file long after quantum computers eventually render
 LZMA obsolete.
 
 @item
-Additionally lzip is copylefted, which guarantees that it will remain
-free forever.
+Additionally the lzip reference implementation is copylefted, which
+guarantees that it will remain free forever.
 @end itemize
 
 A nice feature of the lzip format is that a corrupt byte is easier to
@@ -113,7 +114,8 @@ tar or zutils.
 
 The amount of memory required for compression is about 1 or 2 times the
 dictionary size limit (1 if input file size is less than dictionary size
-limit, else 2) plus 9 times the dictionary size really used. The amount
+limit, else 2) plus 9 times the dictionary size really used. The option
+@samp{-0} is special and only requires about 1.5 MiB at most. The amount
 of memory required for decompression is about 46 kB larger than the
 dictionary size really used.
 
@@ -175,9 +177,8 @@ elaborated way of finding coding sequences of minimum price than the one
 currently used by lzip could be developed, and the resulting sequence
 could also be coded using the LZMA coding scheme.
 
-Lzip currently implements two variants of the LZMA algorithm; fast (used
-by option -0) and normal (used by all other compression levels). Clzip
-just implements the "normal" variant.
+Clzip currently implements two variants of the LZMA algorithm; fast (used
+by option -0) and normal (used by all other compression levels).
 
 The high compression of LZMA comes from combining two basic, well-proven
 compression ideas: sliding dictionaries (LZ77/78) and markov models (the
@@ -337,20 +338,20 @@ When decompressing or testing, further -v's (up to 4) increase the
 verbosity level, showing status, compression ratio, dictionary size,
 and trailer contents (CRC, data size, member size).
 
-@item -1 .. -9
+@item -0 .. -9
 Set the compression parameters (dictionary size and match length limit)
 as shown in the table below. Note that @samp{-9} can be much slower than
-@samp{-1}. These options have no effect when decompressing.
+@samp{-0}. These options have no effect when decompressing.
 
 The bidimensional parameter space of LZMA can't be mapped to a linear
 scale optimal for all files. If your files are large, very repetitive,
 etc, you may need to use the @samp{--match-length} and
 @samp{--dictionary-size} options directly to achieve optimal
-performance. For example, @samp{-9m64} usually compresses executables
-more (and faster) than @samp{-9}.
+performance.
 
 @multitable {Level} {Dictionary size} {Match length limit}
 @item Level @tab Dictionary size @tab Match length limit
+@item -0 @tab 64 KiB @tab  16 bytes
 @item -1 @tab  1 MiB @tab   5 bytes
 @item -2 @tab  1.5 MiB @tab   6 bytes
 @item -3 @tab  2 MiB @tab   8 bytes
@@ -452,8 +453,15 @@ Valid values for dictionary size range from 4 KiB to 512 MiB.
 
 @item Lzma stream
 The lzma stream, finished by an end of stream marker. Uses default
-values for encoder properties. See the lzip manual for a full
-description.
+values for encoder properties.
+@ifnothtml
+@xref{Stream format,,,lzip},
+@end ifnothtml
+@ifhtml
+See
+@uref{http://www.nongnu.org/lzip/manual/lzip_manual.html#Stream-format,,Stream format}
+@end ifhtml
+for a complete description.
 
 @item CRC32 (4 bytes)
 CRC of the uncompressed original data.
@@ -584,7 +592,7 @@ for all eternity, if not longer.
 
 If you find a bug in clzip, please send electronic mail to
 @email{lzip-bug@@nongnu.org}. Include the version number, which you can
-find by running @w{@samp{clzip --version}}.
+find by running @w{@code{clzip --version}}.
 
 
 @node Concept index