Error parsing image file exception on HTTP errors with cURL

[bcarroll2k3]

I have an issue that is driving me insane, hopefully someone can shed some light. I have pages in a WordPress environment that generate PDFs. One is in a directory located at the root of the WP filesystem and is called directly (no WP URL rewrite). The other is served from WP and the code for PDF generation is located in functions.php for the theme.

The page located in the directory at the WP root works fine. The PDF generated from functions.php, which is nearly identical to the other page, constantly throws this error:

mPDF error: IMAGE Error (http://dev.xxxx.com/wp-content/themes/rw/img/logo_new.gif): Error parsing image file - image type not recognised, and not supported by GD imagecreate

The html that's being rendered is identical. I'm using WriteFixedPosHTML to add an image to the document. The page that works defines this image as:

$img = '<img src="../wp-content/themes/rw/img/logo_new.gif" style="width: 145px;">';

The code in functions.php, which doesn't work, defines the image as:

$img = '<img src="http://dev.xxxx.com/wp-content/themes/rw/img/logo_new.gif" style="width: 145px;">';

I have to define it this way otherwise I get the error regardless. I have tried the following:

• Setting src local to function.php: src="img/logo_new.gif", results in

mPDF error: IMAGE Error (http://dev.xxxx.com/img/logo_new.gif): Error parsing image file - image type not recognised, and not supported by GD imagecreate

• Setting src to be src="../rw/img/log_new.gif", results in

mPDF error: IMAGE Error (http://dev.xxxx.com/img/logo_new.gif): Error parsing image file - image type not recognised, and not supported by GD imagecreate

note the path hasn't changed

• Setting src to be src="http://dev.xxxx.com/wp-content/themes/rw/img/logo_new.gif" results in

mPDF error: IMAGE Error (http://dev.xxxx.com/wp-content/themes/rw/img/logo_new.gif): Error parsing image file - image type not recognised, and not supported by GD imagecreate

So, for the life of me I don't understand why

1. One page works with relative pathing and the other doesn't (???)
2. The page that doesn't work doesn't seem to recognize the image as being valid. I can browse to http://dev.xxxx.com/wp-content/themes/rw/img/logo_new.gif just fine.

The php code used to generate pdfs from both pages is identical

    $pdf = new mPDF('','Letter', 0, '', 15, 15, 16, 16, 9, 9, '');
    $pdf->debug = true;
    $pdf->showImageErrors = true;
    $pdf->WriteHTML($html_utf8); // this is identical on both pages
    $pdf->WriteFixedPosHTML($img, 17, 17, 50, 50);
    $pdf->Output();

I'm using mPDF v6 and PHP v5.4.45

Anyone? Thanks!

[Klap-in]

a quick general remark... some links to docs about images
https://mpdf.github.io/what-else-can-i-do/images.html
https://mpdf.github.io/troubleshooting/image-errors.html

http://stackoverflow.com/questions/39374464/mpdfexception-image-error-error-parsing-image-file-yii2
http://stackoverflow.com/questions/20543677/generated-picture-in-mpdf

[Klap-in]

Hmmm, does this issue looks like yours? #13 (just converting the url to base64 helped in this issue...) Question: why...?

There is one other place where I could find the error message in the code, i.e. in utils/image_details.php

mpdf/utils/image_details.php

Line 511 in f3c3295

else if ($type == 'gif') {

What happens if you fill in your urls in this util script? (however I have no idea if code of the getImage() function in mpdf.php uses still the same logic). If it is still throwing the same issue, somewhere it missed the info to detect that you provided an image of type gif.

(The getImage() function is from about line 9347 to 9880 of mpdf.php)

[cjsinnbeck]

@bcarroll2k3 Did you ever solve this? I have the exact same issue, also with WP thrown into the mix. Strange thing is that my code works on one particular shared hosting (and on my XAMPP on my local machine), but not on another, so I suspect some difference in GDlib version, maybe? Best regards.

[zanvidmar]

@cjsinnbeck in my case, I need to allow allow_url_fopen in php settings, because my image was not hosted on the same server.

[Web1776]

I was also getting the "Error parsing image file - image type not recognised, and not supported by GD imagecreate" error. In my case, it was caused by having an .htaccess password in place.

[ghost]

I had a similar issue and I fixed it by adding streamwrappers to the $options of the \Mpdf\Mpdf() constructor:
'whitelistStreamWrappers' => stream_get_wrappers(),

[Abe2021]

I have the same error message using mpdf8.0.x but the error seems to be a red-herring and it seems that the curl_exec is quietly failing in RemoteContentFetcher.php.

As a temporary local edit, I've added the following code after the $data = curl_exec($ch) line....

`

     if ( strpos($data,"404 Not Found")>-1 ) {

        echo "<LI>ERROR: ImageProcessor: getImage: [$url] "
                              .str_replace("404 Not Found", "<B>404 Not Found</B>:",strip_tags($data, "BR"));

    }

    if ( strlen($data)==0 ) echo "<LI>ERROR: ImageProcessor: getImage: no data retrieved for [$url]";

`

.. this exposes that the underlying problem is a 404 Not Found. I've not worked out why the curl_error($ch) doesn't pick up the error (setting CURLOPT_FAILONERROR to true doesn't make it happen either).

The mpdf problem seems to be around the fact that the curl isn't being allowed to read the image URL and I've not been able to work this out (putting in a simple curl test bed seems to result no solution), but as a mPDF work-around I have switched from using the img URL to the img filename, i.e. <img src='/var/www/vhosts/....'> (as the file I'm PDF'ing is on my local host anyway).

it would be good if the curl_exec error checking could be added in the Git code - I'll leave that to the code managers.

Hope that helps
A

[finwe]

Closing as stale. Will gladly reopen, if still applicable on current version which changed loading external resources a fair bit.