Actually, I see pngfix can do a fix the same or better and is packaged in libpng-tools. Replacement diff referring to that one,
--- pngcheck.1.pod.orig 2013-06-26 19:28:27.000000000 +1000 +++ pngcheck.1.pod 2018-10-23 17:31:10.000000000 +1100 @@ -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,27 @@ is a command-line program with batch capabilities (e.g., pngcheck *.png). +=head1 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>. + +C<pngfix> also detects this problem, and can fix it by adjusting the +header to what's needed. The pngcheck sources include a +F<png-fix-IDAT-windowsize.c> program making a similar fix (but only to +maximum window). + +The problem was not as bad as it sounds because programs ignoring the +header size and decoding with maximum window (32 kbyte) read ok. +Libpng 1.2 and 1.4 always used maximum. Libpng 1.6, in its default +configuration, uses the header size so might 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. @@ -125,6 +151,7 @@ pngcomp(1) pngcp(1) pngcrush(1) +pngfix(1) pnginfo(1) pngmeta(1) pngnq(1)
