There's a bug in topng which under certain circumstances may result in
broken output image.  When such an image then is fed to png(1)
diagnostics like the following are produced:

	term% png /tmp/1.png
	png: unknown filtering scheme 49

(The filtering scheme number may differ.)

This happens when at the beginning of an input line (z->x == 0) there
are only room for exactly one pixel in output buffer (b+pixwids == e),
at /sys/src/cmd/jpg/writepng.c:/^zread/+/while/.

Since every scan line should start with a filter algorithm ID it
consumes a byte in the buffer, leaving no room for the pixel.  The
"pixels" variable turns zero, no pixels are emitted, yet the alg byte
slips out.  During next run of zread() with empty buffer, the alg byte
is emitted again, causing permanent skew of output bytes.

The proposed fix is to modify the loop condition so the loop won't
proceed if there are not enough room for at least one pixel plus a
byte for the filter alg ID.

Notes:
Thu Jan 24 17:37:53 EST 2013 geoff
    covered by png-fencepost


Reference: /n/sources/patch/sorry/topng-extrabyte
Date: Mon Dec 24 13:24:17 CET 2012
Signed-off-by: yarikos@gmail.com
Reviewed-by: geoff

--- /sys/src/cmd/jpg/writepng.c	Mon Dec 24 13:24:03 2012
+++ /sys/src/cmd/jpg/writepng.c	Mon Dec 24 13:24:00 2012
@@ -79,7 +79,7 @@
 	pixwid = z->pixwid;
 	b = buf;
 	e = b+n;
-	while(b+pixwid <= e){
+	while(b+pixwid < e){
 		if(z->y >= z->dy)
 			break;
 		if(z->x == 0)