Bug#548580: libgtk2.0-0: patch for JPEG7 support

[Bill Allombert]

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. <ballombe at debian.org>

Imagine a large red swirl here. 
-------------- next part --------------
--- 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) {
-------------- next part --------------
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