Please describe the problem:
This problem was unmasked by a previous fix for Bug 441443 on 5-30-2007.

While loading a large jpeg using pixbuf_loader_write, there is a possibility
that post-processing a scan line will return zero lines even when there are
many more lines to follow.  This causes the load_lines subroutine to quit prematurely with an error even when the jpeg is perfectly okay.

See below for more data.

Steps to reproduce:
1. Load a jpeg larger than 65536 bytes using gdk_pixbuf_loader_write.
2. Note that gtk-demo does *not* use pixbuf_loader_write and doesn't
   tickle this bug.
3. 


Actual results:
jpeg_read_scan_lines quits prematurely, returning a JERR_TOO_LITTLE_DATA.

Expected results:


Does this happen every time?
Yes.

Other information:
Example:  When trying to load a jpeg with 768 scanlines, This loop exits
prematurely at scanline 237 because nlines can be zero just after the
buffer fills up:

 while (cinfo->output_scanline < cinfo->output_height) {
                ...
                nlines = jpeg_read_scanlines (cinfo, lines,
                                              cinfo->rec_outbuf_height);
                if (nlines == 0)
                        break;   <---- should not exit here when there are more                            lines pending.  nlines can be zero just after one buffer fills up and the second
buffer starts from empty.  I don't yet know why; the complex code confuses me.

Recent versions of the Pan newsreader suffer from this bug when displaying a
large jpeg attachment: bug 477860