PDF generation failed if image with base64 as source is present on the page

Have you tried with wkhtmltopdf? If the module pre-processing isn't mangling the base64 encoding, that would be the only PDF library that would possibly be able to understand it.

No further info in several weeks. Closing the issue.

I made a Quick&Dirty patch for this. Maybe the use of XPath could be a solution for these problems.

trying to reopen it

I got a "closed connection" if i have base64 encoded images in the html to render as pdf.

reference.
http://stackoverflow.com/questions/15137660/php-preg-split-utf8-characters

Let me add what I've found with this issue.

We have an embedded Image tag like this:
<img alt="" src="data:image/png;base64,iVBORw0KGgoAAAA...">

This is processed in print_pdf.pages.inc function print_pdf_generate_path line 90. The callback in print.pages.inc line 337 chokes when it tries to preg_split what it receives as a result of the above.

The patch offered in #3 does not work at all.

Adding the u option to preg_split doesn't seem to do anything. Checking for base64 can mitigate the problem so it doesn't crash. I did this:

    if(stristr($matches[1],'img') && stristr($matches[1],';base64,')){
        return '(Image could not be converted to PDF)';
        //returning $matches[0] still fails.
        //returning $matches[1] will generate the PDF, but with partial untranslated base64 encoding as text. Fails to render image.
    }

Obviously this doesn't render the image, which we desire, but at least gets around the critical error.

I have verified that the dompdf library DOES handle this exact same graphic, utilizing their built in test, on the exact same code our server is running.

I should also mention I'm using the D6 version, just noticed this is a D7 ticket...

Finally fixed it in my installation:

Had to do the same fix to TWO functions:

if(stristr($matches[1],'img') && stristr($matches[1],';base64,')){
      return $matches[0];
}

This goes before the preg_split in both _print_rewrite_urls() (print.pages.inc) AND _print_replace_spaces() (print.module) for D6.

Very happy camper now, just one more hack to track...

@psicomante's "Quick&Dirty" patch in #3 works nicely with 7.x-2.x branch of Print.

Note that it is limited to png. But one can easily extend this to other image formats by simply changing

if (strpos($matches[1],"data:image/png")) {

to

if (strpos($matches[1],"data:image/jpeg") || strpos($matches[1],"data:image/jpg") || strpos($matches[1],"data:image/png") || strpos($matches[1],"data:image/gif")) {

@srees, may I suggest that you delete the data URI in #5 as it makes for an unnecessary lonnnnnnnnng scroll :-)

Forked here
https://github.com/psicomante/drupal-print

NOTE: i added some of the patches found in the issues here, and i made other modifications (eg. TOC autogeneration on mPDF, Page number alias on mPDF and other small edits); look at the commits for more details.

Please, if you would like to submit pull-request there, i will include them in the repo.
Thank you.

i was having the same issue, applied patch 3, everything seems ok now

Rerolled and just searched for image/ to allow any image type.

The whole _print_rewrite_urls() function could be rewritten in the same manner as _print_access_images_via_file()

See https://git.drupalcode.org/project/print/-/commit/2ab882a5de72fdb72544c3...

It would be even less complicated, since we would only have to use DOMDocument to find all supported tags and change their href/src.