image_processor.php and GIF

[kegobeer]

It's been a while since I worked on the GIF support, but I see that this

Code Select Expand

function get_handle($path_to_primary_image) {

global $lang_image_processor_php;

// Let's use this information to create the handle with which to hold our lovely
// image. The variable $image_handle is the handle that points to the image's
// location in memory. Other handle creating functions are available (wireless
// bitmap, for example), but they are very rarely needed. You can learn about
// them at php.net in the function library. Look under image functions. If you
// desire, you could add these types to the following if-then-else statements.

$source_image_size_and_type = getimagesize ($path_to_primary_image) or die($lang_image_processor_php['file_corrupt']);
$source_image_width = $source_image_size_and_type[0];
$source_image_height = $source_image_size_and_type[1];
$source_image_type = $source_image_size_and_type[2];

if ($source_image_type == "1") {

        // The image is a GIF file, which we cannot use due to the Unisys patent.
        // The image can be read by GD, but GD cannot create it again. It is
        // possible to convert a GIF to PNG format using a command line call to
        // the appropriate program (i.e. GIF2PNG), but the installation of this
        // program on servers is by no means consistent. Therefore, we will
        // forgo GIF support. We will return an error.

        cpg_die(CRITICAL_ERROR, $lang_image_processor_php['GD_GIF_Warning'], __FILE__, __LINE__);

doesn't allow GIF images, even though there's a check for gif support in init.inc.php.  Shouldn't it be

Code Select Expand

function get_handle($path_to_primary_image) {

global $lang_image_processor_php;

// Let's use this information to create the handle with which to hold our lovely
// image. The variable $image_handle is the handle that points to the image's
// location in memory. Other handle creating functions are available (wireless
// bitmap, for example), but they are very rarely needed. You can learn about
// them at php.net in the function library. Look under image functions. If you
// desire, you could add these types to the following if-then-else statements.

$source_image_size_and_type = getimagesize ($path_to_primary_image) or die($lang_image_processor_php['file_corrupt']);
$source_image_width = $source_image_size_and_type[0];
$source_image_height = $source_image_size_and_type[1];
$source_image_type = $source_image_size_and_type[2];

if ($source_image_type == "1") {

        // The image is a GIF file, which we cannot use due to the Unisys patent.
        // The image can be read by GD, but GD cannot create it again. It is
        // possible to convert a GIF to PNG format using a command line call to
        // the appropriate program (i.e. GIF2PNG), but the installation of this
        // program on servers is by no means consistent. Therefore, we will
        // forgo GIF support. We will return an error.
        if ($CONFIG['GIF_support'] == 1) {
            $image_handle = imagecreatefromgif($path_to_primary_image);
        } else {
            cpg_die(CRITICAL_ERROR, $lang_image_processor_php['GD_GIF_Warning'], __FILE__, __LINE__);
        }

imagecreatetruecolor doesn't apply to GIF images.  Any time a GIF is written it must be imagecreate.  Checks must be put into this file to allow for proper GIF creation.  I also noticed the function ImageIsTrueColor is used in this file, but only php >= 4.3.2 supports it.

[kegobeer]

Since this isn't used by default, I'm not too worried about getting this fixed before, well, yesterday I guess.  Joachim, is this designed to be some sort of replacement for db_input?  When were you looking at doing the replacement?

[kegobeer]

I've made the appropriate changes for GIF support.  I didn't bother to add checks to eliminate the php 4.3+ functions, because the majority of this file is designed for a much better version of php than 4.1.0.  I don't understand the point of this file, since it only is used for single file uploads, and it appears that the only thing it does is rotate images.  Oh well, must be some reason for it I don't quite get.

There isn't code in db_input.php that grabs any of the post data that's sent after the image manipulation is done, so this file doesn't do anything right now.  I also had to comment out the spring cleaning function, since it's also in logging.inc.php.

Haven't committed any changes yet.  Is there any real point in my doing so?

[Joachim Müller]

[moderation]
bumping this unresolved thread to the top...

[kegobeer]

I'm still waiting for word on this, Joachim.  This file isn't used anywhere, so is there any point in having it?

[Joachim Müller]

please go ahead and commit.

[Joachim Müller]

*bump*

[Joachim Müller]

did you commit?

[kegobeer]

Not yet.  I have to recreate the changes as my test box crashed.  I should have it done this weekend.

[kegobeer]

Changes committed.  There were several code blocks repeated, so I commented them out and wrote a new function.  That function is now called twice instead of repeating identical lines over and over again.  GIF support is added into the file.  spring_cleaning is commented out, since it's now in two separate files.  No reason to have it in a third.