Package: pngcheck Version: 2.3.0-7 Severity: wishlist Tags: patch File: /usr/share/man/man1/pngcheck.1.gz
As a suggestion for the pngcheck man page, it'd be good to describe the symptoms of the libpng 1.2.6 IDAT window bits problem. I suggest the words below. This is the problem I struck in my bug #909638. I expect it's rare, but some docs can say how to distinguish it from something worse.
--- pngcheck.1.pod.orig 2013-06-26 19:28:27.000000000 +1000 +++ pngcheck.1.pod 2018-09-30 10:00:38.000000000 +1000 @@ -86,6 +86,11 @@ test verbosely (print most chunk data). +=item B<-w> + +Decompress IDAT chunks using maximum window, ignoring the "window bits" +size specified in the header. + =item B<-x> Search for PNGs and extract them when found. @@ -110,6 +115,29 @@ is a command-line program with batch capabilities (e.g., pngcheck *.png). +=head1 Libpng 1.2.6 Window Bits + +Libpng 1.2.6 from 2004 had a bug where, under certain circumstances, +it wrote IDAT compressed data with CINFO "window bits" header value +too small. The compressed data is perfectly good, but requires a +bigger window for decompressing than the header says. Affected files +fail the full C<pngcheck> due to "zlib data error" but pass +C<pngcheck -w>. + +The pngcheck sources include a program F<png-fix-IDAT-windowsize.c> +which corrects the problem by changing the header to maximum window. +This is a 1 or 2 byte change at the start of IDAT, and 4-byte change +to new CRC at the end. It's possible the actual required window is +smaller than maximum, but such optimizations are left to +L<pngcrush(1)> or similar. + +The problem was not as bad as it sounds because programs ignoring the +header size and decoding with maximum window (32 kbytes) read ok. +Libpng 1.2 and 1.4 always used maximum. Libpng 1.6, in its default +configuration, uses the header size so does not read. Files with the +problem should be rare but the forgiving nature of libpng 1.2 and 1.4 +may have let them go unnoticed for some time. + =head1 ENVIRONMENT None.
