Remote images not loading

Dan Mandle

unread,

Aug 16, 2011, 8:45:14 PM8/16/11

to dompdf

First, let me say how much simpler dompdf is than any of the other
solutions out there.

I'm having one problem though... It won't include any remote images in
the PDF. It includes local images just fine. My guess is that pulling
in the images is timing out or something like that.

Any help or suggestions would be greatly appreciated.

BrianS

unread,

Aug 16, 2011, 9:45:38 PM8/16/11

to dom...@googlegroups.com

Glad the project is working out for you. Which version of DOMPDF are you using? If 0.6.0 you can check that your system has all the requirements by visiting dompdf/www/setup.php via your web browser.

Some of the most common issues related to loading of remote images would be:

allow_url_fopen is set to false
your web server doesn't have read/write access to the DOMPDF_TEMP_DIR
DOMPDF_ENABLE_REMOTE is set to false

Sometimes the problem proves trickier to pin-point, but check those first. Also check your PHP error log (if you have on set up). And, you could also check that you are able to pull remote images by just writing a script that uses file_get_contents() to pull a remote image and see what happens.

Dan Mandle

unread,

Aug 16, 2011, 10:32:46 PM8/16/11

to dom...@googlegroups.com

That fixed it! Thanks a ton for the quick and thorough response! DOMPDF_ENABLE_REMOTE was set to false.

Dan Mandle

unread,

Aug 16, 2011, 11:34:42 PM8/16/11

to dom...@googlegroups.com

Well of course I spoke too soon. Now most of the photos are loading... Tried to increase PHP timeout, but that didn't help anything...

BrianS

unread,

Aug 17, 2011, 11:36:20 AM8/17/11

to dom...@googlegroups.com

It could be a memory issue, but this would typically result in DOMPDF crashing and not producing a PDF at all.

Do you have a sample document/images we can test against to see if there's any kind of incompatibility?

Dan Mandle

unread,

Aug 17, 2011, 10:00:53 PM8/17/11

to dom...@googlegroups.com

Due to the contents of the PDFs, I can't post them... I don't think it's running out of memory, because it's not the last pictures aren't showing up, it's random ones in the middle.

BrianS

unread,

Aug 17, 2011, 10:28:29 PM8/17/11

to dompdf

It's possible there's an incompatibility with some of the libraries on
your system. What type of images are giving you problems? Are they
dynamically generated? Is the problem consistently with the same image
or, for generated images, images from the same source?

Your problem is getting trickier, especially without any indication of
errors from your server. If you can share some of the problematic
content outside of posting on the forums (e.g. via email) feel free to
contact me directly.

Dan Mandle

unread,

Aug 18, 2011, 8:12:37 AM8/18/11

to dom...@googlegroups.com

All of the images are JPEGs being pulled from the same remote server. The baffling thing is that I have a "preview" page that generates the HTML into a varriable, then the page just echos $pageContents and that shows everything as it would be displayed in the PDF. When you press the "Generate PDF" button, it does a POST and sends $pageContents to genPDF.php.

So on the preview page, everything shows up fine. Below is the code for genPDF.php. I'm still not able to send you the PDF, however, what methods would you use to find the errors? Maybe I can dig those out and show them here.

<?php

require_once("dompdf/dompdf_config.inc.php");

$pageContents = NULL;

$pageContents=$_POST["pageContents"];

if ($pageContents == NULL){

$pageContents = "Cannot Generate PDF. No content was passed from <a href='index.html'>before</a>. Please click the link and try again.";

$success = FALSE;

}

else {$success = TRUE;}

$html =

'<html><head><link href="style.css" rel="stylesheet" type="text/css" /></head> '.

'<body><div class="all">'.$pageContents.'</div></body></html>';

if($success != FALSE){

$dompdf = new DOMPDF();

$dompdf->load_html($html);

$dompdf->render();

$dompdf->stream("my_pdf.pdf", array("Attachment" => 0));

}

else {echo $html;}

?>

BrianS

unread,

Aug 18, 2011, 1:54:54 PM8/18/11

to dom...@googlegroups.com

What paths are used to reference the images? Since you're using load_html, any relative path will be relative to the physical path of genPDF.php on your server.

Dan Mandle

unread,

Aug 18, 2011, 1:57:09 PM8/18/11

to dom...@googlegroups.com

The remote images are all src="http://foo.com/bar/foo/bar.jpg"

BrianS

unread,

Aug 18, 2011, 2:02:37 PM8/18/11

to dom...@googlegroups.com

Could be a caching issue. Are the missing images reused from earlier pages? Or maybe a connection issue. Any errors/warnings thrown by PHP?

Dan Mandle

unread,

Aug 18, 2011, 2:05:49 PM8/18/11

to dom...@googlegroups.com

Thanks for keeping up with me. I really appreciate it.

No PHP errors that I can see. No matter how many times i regenerate the PDF (using the same source) it's always the same images that aren't loading, however in my "preview" all the images load fine.

BrianS

unread,

Aug 18, 2011, 2:08:06 PM8/18/11

to dom...@googlegroups.com

If you move the images to a different location in the document do they still have problems displaying correctly? If so can you share the URL?

Which version of dompdf were you using?

psychoactive

unread,

Aug 18, 2011, 2:08:45 PM8/18/11

to dom...@googlegroups.com

Its not the cache in your PDF viewer either right? I've had that cause problems before

> --
> You received this message because you are subscribed to the Google Groups "dompdf" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/dompdf/-/u-PgQ9Mr9VsJ.
> To post to this group, send email to dom...@googlegroups.com.
> To unsubscribe from this group, send email to dompdf+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/dompdf?hl=en.
>

Dan Mandle

unread,

Aug 18, 2011, 2:18:41 PM8/18/11

to dom...@googlegroups.com

You have struck a nail! The way that the HTML generation behaves is by a PHP loop that grabs a photo and text from a set serialized HTML files that are hosted remotely. So to generate the HTML, I have a form that you give a CSV of numerical values and it kicks back this report with the photos and descriptions.

To answer your question, the same images (2 of 10) fails no matter the order of the elements.

Here is the code that generates the $pageContents with some secret parts taken out:

<?php

$pageContents = NULL;

$photoIDs=$_POST["photoIDs"];

$photoIDarray=explode(",",$photoIDs);

//print_r($photoIDarray);

$pageContents = "<div class='header'><h1>".$_POST["reportTitle"]."</h1><p>".$_POST["notes"]."</p></div>";

for ($i = 0; $i < count($photoIDarray); ++$i) {

//print $photoIDarray[$i];

$contentID = $photoIDarray[$i];

//echo "Content ID: ".$contentID;

if ($contentID{0} != "L"){

$contents = file_get_contents('http://www.XXXX.com/XXXX/####.html');

if(preg_match('/<h1>(.+)<\/h1>/', $contents, $title));

if(preg_match('/<img class\=\"inset\" src\=\"(.+)\" alt=/', $contents, $thumb));

if(preg_match('/<\/span><\/p>(.*)<p class/msU', $contents, $desc));

$photoSrc = "http://www.XXXXX.com".$thumb[1];

$linkURL = "http://www.XXXXX.com/photo/".$contentID.".html";

}

$pageContents .= "<div class='item'><div class='photo'><a href='".$linkURL."' target='_blank'><img src='".$photoSrc."'/></a></div>";

$pageContents .= "<div class='text'><h2>".$title[1]."</h2>";

$pageContents .= $desc[1];

$pageContents .= "</div></div>";

}

?>

<body>

</form>

</div>

<?php

echo $pageContents;

?>

Dan Mandle

unread,

Aug 18, 2011, 2:37:43 PM8/18/11

to dom...@googlegroups.com

And I'm pretty sure I'm using version 0.6.0 beta2

BrianS

unread,

Aug 18, 2011, 2:52:21 PM8/18/11

to dom...@googlegroups.com

I don't see anything here that would cause me to believe that there's necessarily anything wrong with your script. But the fact that it's always the second image does make one wonder ...

This shouldn't have anything to do with it, but can you try $i++ instead of ++$i?

Also, with 0.6.0 you should be able to use echo $dompdf->output_html(); to see what the HTML parsed by DOMPDF looks like. DOMPDF is less lenient of any possible structural problems, so if one exists that it doesn't like you'll probably be able to see it in the parsed HTML returned by that method.

Dan Mandle

unread,

Aug 18, 2011, 3:28:51 PM8/18/11

to dom...@googlegroups.com

I think you may have misunderstood me before (or I wrote it poorly). Two of the ten images don't show up. Not number two. Lets say that I have IDs 1,2,3,4,5 and 2 & 4 aren't showing up in the PDF. When I change the order to 1,3,2,5,4 (or whatever) 2 & 4 still don't load.

Tried output_html and that loaded fine.

Dan Mandle

unread,

Aug 18, 2011, 3:37:58 PM8/18/11

to dom...@googlegroups.com

Also I was hoping that it was a strangely encoded image and it just wasn't rendering correctly, however, I put the photo on the local webserver and it rendered just fine.

BrianS

unread,

Aug 18, 2011, 3:42:13 PM8/18/11

to dom...@googlegroups.com

Yes, I did misunderstand. Though you were saying it was always the image in position 2.

Are you saying that placing the photo on the local web server that it renders in the PDF just fine?

BrianS

unread,

Aug 18, 2011, 3:43:44 PM8/18/11

to dom...@googlegroups.com

Can you try setting the various debug/warning options at the bottom of dompdf_config.inc.php to true and see if anything useful is returned?

Dan Mandle

unread,

Aug 18, 2011, 3:44:21 PM8/18/11

to dom...@googlegroups.com

Yes. Downloaded the image that it's calling remotely, saved it on the PDF-rendering server and called it and it loaded just fine in the PDF.

Dan Mandle

unread,

Aug 18, 2011, 3:53:44 PM8/18/11

to dom...@googlegroups.com

Errors!!!!! Don't really know how helpful they are though.....

DOMDocument::loadHTML() [domdocument.loadhtml]: htmlParseEntityRef: expecting ';' in Entity, line: 1 DOMDocument::loadHTML() [domdocument.loadhtml]: htmlParseEntityRef: expecting ';' in Entity, line: 6 DOMDocument::loadHTML() [domdocument.loadhtml]: htmlParseEntityRef: expecting ';' in Entity, line: 11 DOMDocument::loadHTML() [domdocument.loadhtml]: htmlParseEntityRef: expecting ';' in Entity, line: 16 DOMDocument::loadHTML() [domdocument.loadhtml]: htmlParseEntityRef: expecting ';' in Entity, line: 21 DOMDocument::loadHTML() [domdocument.loadhtml]: htmlParseEntityRef: expecting ';' in Entity, line: 26 DOMDocument::loadHTML() [domdocument.loadhtml]: htmlParseEntityRef: expecting ';' in Entity, line: 31 DOMDocument::loadHTML() [domdocument.loadhtml]: htmlParseEntityRef: expecting ';' in Entity, line: 36 DOMDocument::loadHTML() [domdocument.loadhtml]: htmlParseEntityRef: expecting ';' in Entity, line: 41 DOMDocument::loadHTML() [domdocument.loadhtml]: htmlParseEntityRef: expecting ';' in Entity, line: 46

BrianS

unread,

Aug 18, 2011, 4:08:42 PM8/18/11

to dom...@googlegroups.com

That doesn't look to be problematic, but you never know. The parsing warnings aren't due to something that's part of the image URL are they?

Dan Mandle

unread,

Aug 18, 2011, 4:30:13 PM8/18/11

to dom...@googlegroups.com

I can't share it but I think I found the problem! (plus some other things)

The images are aren't loading have spaces in the title which are converted to %20. The preview page doesn't convert it, it just leaves the spaces in the code and I guess the browser thinks around it. I can't change the file names of the remote files (to remove the spaces). Any idea how to work around it?

Also, for some reason, the image tags are showing up as <img > instead of <img />, but I don't think that's the problem because some images are working and others aren't.

BrianS

unread,

Aug 18, 2011, 5:08:53 PM8/18/11

to dom...@googlegroups.com

That's it. I thought we had already addressed this problem, but some quick testing and it appears to still be an issue. I know this isn't the first time it's come up.

You can't rename the images, but since you're already doing some manual parsing to get the image URL you could just add a bit of code to handle the presence of spaces:

$photoSrc = "http://www.example.com".str_replace(" ", "%20", $thumb[1]);

Dan Mandle

unread,

Aug 20, 2011, 12:06:04 PM8/20/11

to dom...@googlegroups.com

Great success! Thanks for your help on this. I'm sure I'll have use for it past this project.

Reply all

Reply to author

Forward