From ce34ec4f54ff8b753da236f371ad8dd23c8135c9 Mon Sep 17 00:00:00 2001 From: Lasse Collin Date: Tue, 19 Oct 2010 10:21:08 +0300 Subject: Update docs. --- TODO | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) (limited to 'TODO') diff --git a/TODO b/TODO index 9fac1b34..55fc4755 100644 --- a/TODO +++ b/TODO @@ -18,15 +18,20 @@ Known bugs XZ Utils compress some files significantly worse than LZMA Utils. This is due to faster compression presets used by XZ Utils, and - can be worked around by using "xz --extreme". However, the presets - need some tweaking and maybe this issue can be minimized without - making the typical case too much slower. + can often be worked around by using "xz --extreme". With some files + --extreme isn't enough though: it's most likely with files that + compress extremely well, so going from compression ratio of 0.003 + to 0.004 means big relative increase in the compressed file size. xz doesn't quote unprintable characters when it displays file names given on the command line. tuklib_exit() doesn't block signals => EINTR is possible. + SIGTSTP is not handled. If xz is stopped, the estimated remaining + time and calculated (de)compression speed won't make sense in the + progress indicator (xz --verbose). + Missing features ---------------- @@ -41,11 +46,13 @@ Missing features Buffer-to-buffer coding could use less RAM (especially when decompressing LZMA1 or LZMA2). - I/O library is not implemented. It will possibly be named libzzf. + I/O library is not implemented (similar to gzopen() in zlib). + It will be a separate library that supports uncompressed, .gz, + .bz2, .lzma, and .xz files. lzma_strerror() to convert lzma_ret to human readable form? This is tricky, because the same error codes are used with - slightly different meanings. + slightly different meanings, and this cannot be fixed anymore. Documentation -- cgit v1.2.3