Package: libgtk2.0-0 Version: 2.18.0-1 Severity: important Hello Sebastien,
Please apply the following patch which is required for correct operation when building with libjpeg7. This does not affect operation with libjpeg6 build. I also attach the comment from libjpeg7 author. Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here.
--- gtk+2.0-2.16.6/gdk-pixbuf/io-jpeg.c 2009-08-29 04:36:45.000000000 +0200 +++ gtk+2.0-2.18.0/gdk-pixbuf/io-jpeg.c 2009-09-27 13:22:40.000000000 +0200 @@ -920,7 +920,7 @@ return FALSE; } } - + cinfo->scale_num = 1; for (cinfo->scale_denom = 2; cinfo->scale_denom <= 8; cinfo->scale_denom *= 2) { jpeg_calc_output_dimensions (cinfo); if (cinfo->output_width < width || cinfo->output_height < height) {
Hello all This is a report to the authors mentioned in the gdk-pixbuf/io-jpeg.c module of the current gtk+ 2.18.0 package, from Guido Vollbeding, organizer Independent JPEG Group. I'm sorry if this way is inappropriate, but I'm not involved in any forums or mailing lists. Please forward to whom it may concern if possible. I have noticed various complaints about weird display of JPEG images with applications depending on gtk+ after upgrading to the new IJG JPEG 7 version, and I have seen faulty patches to the above mentioned module to work around the problem. I have now looked through the code and found the flawed code sequence in function "gdk_pixbuf__jpeg_image_load_increment". I strongly advise to correct the code by simply inserting the statement cinfo->scale_num = 1; in front of the following code sequence in mentioned function: for (cinfo->scale_denom = 2; cinfo->scale_denom <= 8; cinfo->scale_denom *= 2) { jpeg_calc_output_dimensions (cinfo); if (cinfo->output_width < width || cinfo->output_height < height) { cinfo->scale_denom /= 2; break; } } jpeg_calc_output_dimensions (cinfo); This addition will work with older and newer versions of the library. The implicit assumption of the given code that cinfo->scale_num is initialized with 1 by the JPEG library is no longer true for versions 7 and later! Version 7 initializes this field (and the other) with 8, and version 8 and later will initialize the fields with the (variable from 1 to 16) block size of the given JPEG file. (Note that the default resulting scaling factor remains 1 in any case.) The usual recommendation for versions up to 6 has always been that "scale_num" and "scale_denom" be set *simultaneously* by the calling application. Applications following this recommendation will not suffer an incompatibility with newer JPEG library versions. Newer applications (written for JPEG library versions 7 and later) MAY choose to set only one of both fields, because the initialization defaults are now depending on the input file and are specified as mentioned above. The given correction code simply retains the same behaviour with new JPEG library versions as with old JPEG library versions. The code may later be revised to utilize the more flexible scaling choices of v7 and later, but there is no need to do this now. I have not verified other code in the module. But this part is clearly wrong for use with newer JPEG library versions and requires correction, as it may affect a lot of gtk+ dependent applications. Regards Guido Vollbeding Organizer Independent JPEG Group