summaryrefslogtreecommitdiffstats
path: root/README
diff options
context:
space:
mode:
authorDaniel Baumann <mail@daniel-baumann.ch>2015-11-07 14:06:49 +0000
committerDaniel Baumann <mail@daniel-baumann.ch>2015-11-07 14:06:49 +0000
commit38911c04adbe853acb3d534e1853a8a0ffce88bd (patch)
tree77e6c7cdc56b911b917f20219c93423641d959a3 /README
parentAdding debian version 1.7~pre1-1. (diff)
downloadlzlib-38911c04adbe853acb3d534e1853a8a0ffce88bd.tar.xz
lzlib-38911c04adbe853acb3d534e1853a8a0ffce88bd.zip
Merging upstream version 1.7~rc1.
Signed-off-by: Daniel Baumann <mail@daniel-baumann.ch>
Diffstat (limited to 'README')
-rw-r--r--README21
1 files changed, 11 insertions, 10 deletions
diff --git a/README b/README
index 542d8ef..8906a13 100644
--- a/README
+++ b/README
@@ -36,14 +36,14 @@ library are given in the files 'main.c' and 'bbexample.c' from the
source distribution.
Compression/decompression is done by repeatedly calling a couple of
-read/write functions until all the data has been processed by the
+read/write functions until all the data have been processed by the
library. This interface is safer and less error prone than the
traditional zlib interface.
Compression/decompression is done when the read function is called. This
means the value returned by the position functions will not be updated
-until some data is read, even if you write a lot of data. If you want
-the data to be compressed in advance, just call the read function with a
+until a read call, even if a lot of data is written. If you want the
+data to be compressed in advance, just call the read function with a
size equal to 0.
If all the data to be compressed are written in advance, lzlib will
@@ -61,13 +61,14 @@ All the library functions are thread safe. The library does not install
any signal handler. The decoder checks the consistency of the compressed
data, so the library should never crash even in case of corrupted input.
-There is no such thing as a "LZMA algorithm"; it is more like a "LZMA
-coding scheme". For example, the option '-0' of lzip uses the scheme in
-almost the simplest way possible; issuing the longest match it can find,
-or a literal byte if it can't find a match. Inversely, a much more
-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.
+In spite of its name (Lempel-Ziv-Markov chain-Algorithm), LZMA is not a
+concrete algorithm; it is more like "any algorithm using the LZMA coding
+scheme". For example, the option '-0' of lzip uses the scheme in almost
+the simplest way possible; issuing the longest match it can find, or a
+literal byte if it can't find a match. Inversely, a much more elaborated
+way of finding coding sequences of minimum size than the one currently
+used by lzip could be developed, and the resulting sequence could also
+be coded using the LZMA coding scheme.
Lzlib currently implements two variants of the LZMA algorithm; fast
(used by option -0 of minilzip) and normal (used by all other