CSS sheets and images are not included in PDF. Path Issue?

I am having the same problems. Neither the CSS, nor the images are being displayed, even though the PDF is produced OK.
(This is with dompdf 0.5.1).
The print-friendly version is styling OK.

If it is affecting the HTML output, I can guarantee that you've configured the module correctly.. However, dompdf is not fully 100% CSS compliant (http://www.digitaljunkies.ca/dompdf/css21.php).

If you want 100% support, try wkhtmltopdf.

João

I have the same issue.

It is not a dompdf css-compatibility issue.

Adding

within the head of the print.tpl.php styles the PDF properly.

But, there is the issue of the image not showing up. I have a feeling we are running into an issue here:

There could also be problems with the permissions of the folder where DOMPDF caches images. This directory is set in the file, look for the constant names DOMPDF_TEMP_DIR. The user your web server runs under should have read/write access to that directory.

http://www.dashinteractive.net/dompdf/index.php?v=3275633

Will post any results I find.

Check this out.

In my dompdf install there was a test directory.

If I browse to mysite.com/sites/all/modules/print/lib/dompdf/www/test/examples.php then click on an Image PDF test, the PDF generator works.

So it does indeed seem to be a print module issue.

My investigative report
------------------------------

1) The DOMPDF test pages generate PDF's with images and external stylesheets
2) The Print Module -> Print to PDF link generates a PDF with broken images (red x) and without external stylesheets applied.
3) I found "page not found" errors in my log regarding the external stylesheets and images that Print Module -> Print to PDF link SHOULD be loading. Screenshot attached.

I therefor believe this to be some sort of $path issue. I've been trying for hours to manipulate $path and writing different absolute / relative image paths in print.tpl.php, but nothing has worked yet.

Noticing this error now. Notice how the path is incorrect? The $base_url is not being printed in the url.

I wonder of Dompdf's $set_base_path function is not working? Line 136 in print/print_pdf/print_pdf.pages.inc uses this to set the base path, and it appears that the base path is missing according to the errors below.

In a few hours I will try and hack your code to insert Drupal's $base_path into the pathname directly. I hope you come around before then because this could get ugly! Ha.

Cheers.

* warning: parse_url(http:///sites/all/modules/admin_menu/admin_menu.css?L) [function.parse-url]: Unable to parse URL in SITE.COM/html/sites/all/modules/print/lib/dompdf/include/functions.inc.php on line 143.
* warning: parse_url(http:///modules/book/book.css?L) [function.parse-url]: Unable to parse URL in SITE.COM/html/sites/all/modules/print/lib/dompdf/include/functions.inc.php on line 143.
* warning: parse_url(http:///modules/node/node.css?L) [function.parse-url]: Unable to parse URL in SITE.COM/html/sites/all/modules/print/lib/dompdf/include/functions.inc.php on line 143.
* warning: parse_url(http:///modules/poll/poll.css?L) [function.parse-url]: Unable to parse URL in SITE.COM/html/sites/all/modules/print/lib/dompdf/include/functions.inc.php on line 143.
* warning: parse_url(http:///modules/system/defaults.css?L) [function.parse-url]: Unable to parse URL in SITE.COM/html/sites/all/modules/print/lib/dompdf/include/functions.inc.php on line 143.
* warning: parse_url(http:///modules/system/system-menus.css?L) [function.parse-url]: Unable to parse URL in SITE.COM/html/sites/all/modules/print/lib/dompdf/include/functions.inc.php on line 143.
* warning: parse_url(http:///modules/user/user.css?L) [function.parse-url]: Unable to parse URL in SITE.COM/html/sites/all/modules/print/lib/dompdf/include/functions.inc.php on line 143.
* warning: parse_url(http:///sites/all/modules/cck/theme/content-module.css?L) [function.parse-url]: Unable to parse URL in SITE.COM/html/sites/all/modules/print/lib/dompdf/include/functions.inc.php on line 143.
* warning: parse_url(http:///sites/all/modules/date/date.css?L) [function.parse-url]: Unable to parse URL in SITE.COM/html/sites/all/modules/print/lib/dompdf/include/functions.inc.php on line 143.
* warning: parse_url(http:///sites/all/modules/date/date_popup/themes/datepicker.css?L) [function.parse-url]: Unable to parse URL in SITE.COM/html/sites/all/modules/print/lib/dompdf/include/functions.inc.php on line 143.
* warning: parse_url(http:///sites/all/modules/date/date_popup/themes/timeentry.css?L) [function.parse-url]: Unable to parse URL in SITE.COM/html/sites/all/modules/print/lib/dompdf/include/functions.inc.php on line 143.
* warning: parse_url(http:///sites/all/modules/filefield/filefield.css?L) [function.parse-url]: Unable to parse URL in SITE.COM/html/sites/all/modules/print/lib/dompdf/include/functions.inc.php on line 143.
* warning: parse_url(http:///sites/all/modules/lightbox2/css/lightbox.css?L) [function.parse-url]: Unable to parse URL in SITE.COM/html/sites/all/modules/print/lib/dompdf/include/functions.inc.php on line 143.
* warning: parse_url(http:///sites/all/modules/print/css/print.css?L) [function.parse-url]: Unable to parse URL in SITE.COM/html/sites/all/modules/print/lib/dompdf/include/functions.inc.php on line 143.
* warning: array_map() [function.array-map]: Argument #2 should be an array in SITE.COM/html/sites/all/modules/print/lib/dompdf/include/abstract_renderer.cls.php on line 668.
* warning: array_map() [function.array-map]: Argument #2 should be an array in SITE.COM/html/sites/all/modules/print/lib/dompdf/include/abstract_renderer.cls.php on line 674.
* warning: array_map() [function.array-map]: Argument #2 should be an array in SITE.COM/html/sites/all/modules/print/lib/dompdf/include/abstract_renderer.cls.php on line 674.
* warning: array_map() [function.array-map]: Argument #2 should be an array in SITE.COM/html/sites/all/modules/print/lib/dompdf/include/abstract_renderer.cls.php on line 668.

Screenshot for #7 - sorry for all of the separate replies

subscribing

:)

I have this issue fixed on my server. PDF's are now being generated with images and external stylesheets applied.

There were two lines in /print/print_pdf/print_pdf.pages.inc that needed to be removed.

line 136: $dompdf->set_base_path($path);
line 139: $dompdf->set_protocol($protocol);

Can you guys test this? If it works for you, then I'll create a patch.

Thanks,

1) Use dompdf 0.5.1

2) Insert an img line directly into /print/print.tpl.php file. For Instance, instead of using the default "print $logo" line I have this :

    <div class="print-logo">
    <img  alt="thre" src="sites/default/files/letterhead-redblack.jpg">
    </div>

3) Check the printer-friendly page, does the image show up?

4) Use the print-to-pdf link. Does the image show up?

Also : I just noticed that my image is NOT showing the print-friendly version of the node.

Thanks for your work on this.

Commenting out the lines did not fix the problem on my install.

mjpg: Have you put an img tag in print.tpl.php file?

This whole issue is being caused by incorrect paths. What commenting out those lines does is makes dompdf (as far as I can tell) consider the $base_path to be www.yoursite.com. This means that any images that go into the print.tpl.php file must have a relative path of "sites/wherever_your_image_is/image.jpg"

Also, only styles that I apply to the head of print.tpl.php are working for me. Here is my print.tpl.php file, which is printing my image and displaying the css (I'm still working out some style issues that I think dompdf is responsible for)

<?php
// $Id: print.tpl.php,v 1.8.2.15 2009/07/09 12:00:52 jcnventura Exp $

/**
 * @file
 * Default print module template
 *
 * @ingroup print
 */
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="<?php print $print['language']; ?>" xml:lang="<?php print $print['language']; ?>">
  <head>
    <?php print $print['head']; ?>
    <title><?php print $print['title']; ?></title>
    <?php print $print['scripts']; ?>
    <?php print $print['robots_meta']; ?>
    <?php print $print['base_href']; ?>
    <?php print $print['favicon']; ?>
    <?php print $print['css']; ?>
    <link rel="stylesheet" type="text/css" href="print.css">
	 <style type="text/css">
	 /* $Id: print.css,v 1.1.2.2 2008/08/21 22:03:40 jcnventura Exp $ */

body {
  margin: 1em;
  background-color: #fff;
  font-family: sans-serif;
}
th {
  text-align: left; /* LTR */
  color: #006;
  border-bottom: 1px solid #ccc;
}
tr.odd {
  background-color: #ddd;
}
tr.even {
  background-color: #fff;
}
td {
  padding: 5px;
}
#menu {
  visibility: hidden;
}
#main {
  margin: 1em;
}
a:link {color: #000;}
a:visited {color: #000;}
a:hover {color: #00f;}
a:link img, a:visited img {border: 0;}
.print-footnote {display:none; font-size: xx-small;}
img.print-logo {border: 0;}
.print-site_name {}
.print-breadcrumb {font-size: x-small;}



.print-submitted {font-size: small;}
.print-created {font-size: small;}
.print-taxonomy {
  text-align: right;
}
.print-taxonomy li {display: inline;}
.print-content {}
.print-hr {
  border: 0;
  height: 1px;
  width: 100%;
  color: #9E9E9E;
  background-color: #9E9E9E;
}
.print-message {
  border: medium dotted blue;
  padding: 1em;
}
.print-source_url {font-size: small;}
.print-links {font-size: small;}
.print-footer {text-align: center;}


/*******************
	INVOICE PDF's
 ******************/
 
 /* title */
 .print-title {
	margin-bottom: 15px;
	margin-top: 15px;
	display: block;
	
	border-bottom: 1px solid #545454;
	font-size: 23px;
	font-weight: normal;
	}
	
	
 		.field {
 			margin: 10px 0px 0px 20px;
 			}
 		
 		.field .field-label-inline, .field .field-label-inline-first {
 			color: #545454;
 			}
 			
 		.field-item span {
	 			font-weight: bold;
	 			color: #545454;
	 			}
	 			
 		.field a {
 			text-decoration: none;
 			color: black;
 			}
 			
 		.field .field-label {
	 		display: inline;
	 		}
 		
 		.field .field-items {
	 		display: inline;
 			}
 			
 			.field .field-items .field-item {
	 			display: inline;
	 			}
 		
 		/* date */
 		 .field-field-invoice-date .date-display-single {
 		 		margin-bottom: 20px;
 		 		display: block;
 		 		
 				font-size: 17px;
 				}
 				
 		
 		/* client */
 		.field-field-invoice-client {
 			font-size: 22px;
 			}
 			
 		/* total due */
 		.field-field-invoice-totaldue {
 			margin-top: 27px;
 			color: black;
 			}
		
		/* products list */
		.field-field-invoice-products-list .field-label {
			display: block;
			margin-top: 40px;
			}
			
		/* work performed */
		.field-field-invoice-work {
			margin-top: 40px;
			}


	 </style>
  </head>

  <body<?php print $print['sendtoprinter']; ?>>
    <?php if (!empty($print['message'])) {
      print '<div class="print-message">'. $print['message'] .'</div><p />';
    } ?>
    <div class="print-logo">
    <img  alt="thre" src="sites/default/files/letterhead-redblack.jpg">
    </div>
    <h1 class="print-title"><?php print $print['title']; ?></h1>
    <div class="print-content"><?php print $print['content']; ?></div>
  </body>
</html>

So using that type of path, you see the image on the print-friendly and I do not, and I see the image on the PDF and you do not.

Are you printing nodes?

Use the following three types of image paths to the print.tpl.php file, and see if it helps:

<img  alt="thre" src="sites/default/files/letterhead-redblack.jpg">
<img  alt="two" src="/sites/default/files/letterhead-redblack.jpg">
<img  alt="three" src="http://site.com/default/files/letterhead-redblack.jpg">

Hmmmmm......

I'm assuming that our different results are due to different server configurations. What kind of server are you on?

Also, are you using the standard dompdf config (in /print/lib/dompdf) file or did you edit it?

Yeah, I'm having the same issue. Its most definitely a bug regarding $base_path or something in the module.

I am simply resorting to print EVERY image with a direct IMG tag in print.tpl.php, including my header and footer and etc. I haven't tested background images though.

I would prefer just printing the /print/nid view from the browser if it did not print a header and footer every time.

Results of my tests:

Server is Apache/PHP 5.2

Hard-coding the image (in any path method - rel, abs or url) does not work.

Adding the styles inline does work.

The tmp directory is writable and is being written to OK.

The print version works OK.

I haven't changed anything in the dompdf library folder.

I'm using wkhtmltopdf. the printed PDF doesn't shows the image..whatever image will become links appear at footnote. how do i enable the image to appear in pdf?

Hi djmystik82, i'm posting at here because i think it might be a bug at print modules which effect all 3 3rd party pdf generators.

Hi all,

I'm seeing the same corrupted image path links behavior with 6.x-1.10 and tcpdf 4.8.032 on D6.15.

I am posting here because it seems that this issue affects all third party pdf generation tools.

It is inconsistent in that certain pages will give errors like "TCPDF ERROR: [Image] No such file or directory in /var/www/html/drupal/6.13//default/files/imagefile.png" but others will generate without a problem. In the case above, the file is exists (is displayed on the page, can be linked to, etc) but is located at /var/www/html/drupal/6.13/sites/default/files/cbfu-high-level.png

In the cases where I could generate a pdf, the path locations for the images given on the bottom of the pdf page are incorrect. Instead of http://example.com/sites/default/files/imagefile.jpg it shows http://example.com/?q=sites/default/files/imagefile.png. As the CSS and image files also do not render, my guess is that the print module is passing the pdf generator bad file locations.

Please do let me know if you need more detail

Having the same issue with version 6.x-1.10. The images are showing up as boxes with red X in them.

Sub. Same issues. Broken images in the pdf file.

This is not limited to Dompdf. I'm currently using wkhtmltopdf and I have the same problems.

Images missing in PDF
Stylesheet not being applied to the rendered PDF

It works fine when printing, but when PDF is selected, it just doesn't render the CSS nor display the images.

I'm using a custom CSS file.

I have been struggling with this same issue.

Although, I was reading through the print_pdf.pages.inc file and noticed that there is a coulple spots that refer to img tags and having to make the img elements absolute. I'm no coding genius but it appears that it is trying to append http://yoursite.com to the beginning of every img link.
this is line 41-63 in the file

<?php
  // Img elements must be set to absolute
  $pattern = '!<(img\s[^>]*?)>!is';
  $print['content'] = preg_replace_callback($pattern, '_print_rewrite_urls', $print['content']);
  $print['logo'] = preg_replace_callback($pattern, '_print_rewrite_urls', $print['logo']);
  $print['footer_message'] = preg_replace_callback($pattern, '_print_rewrite_urls', $print['footer_message']);
  // And converted from private to public paths
  $file_downloads = variable_get('file_downloads', FILE_DOWNLOADS_PUBLIC);
  if ($file_downloads == FILE_DOWNLOADS_PRIVATE) {
    switch (variable_get('language_negotiation', LANGUAGE_NEGOTIATION_NONE)) {
      case LANGUAGE_NEGOTIATION_PATH_DEFAULT:
      case LANGUAGE_NEGOTIATION_PATH:
        $lang = $language->language;
        break;
      default:
        $lang = '';
        break;
    }
    $pattern = "!(<img\s[^>]*?src\s*?=\s*?['\"]?)${base_url}/(?:(?:index.php)?\?q=)?(?:${lang}/)?system/files(/[^>]*?>)!is";
    $replacement = '$1file://'. realpath(file_directory_path()) .'$2';
    $print['content'] = preg_replace($pattern, $replacement, $print['content']);
    $print['logo'] = preg_replace($pattern, $replacement, $print['logo']);
    $print['footer_message'] = preg_replace($pattern, $replacement, $print['footer_message']);
  }
?>

it appears that this code applies to all of the pdf generators.

perhaps someone could look at this section carefully and see if it is correct?

I found this: http://www.martinvseticka.eu/index.php?sekce=browse&page=160
maybe it helps.

Havn't found time to try it out yet.

Did this work for anyone? This seems to be a serious issues. No fix yet?

No, there is no fix yet. This is the only consolidated thread on the issue, so you can check here on results.

I posted some steps starting at #14 that allowed me to get images in a PDF using the DomPDF library, but the image will not show in print preview (seems its one or the other). The steps I used to allow this did not work for another user, though.

Thanks Kevin. I'll check it out and give everyone my results.

Update: It didn't work for me either. If someone knows how to stop the red x boxes from showing up then I would be able to use the pdf of this module until a fix comes out that works for everyone.

my problem looks similar. Installed is version dompdf_0-6-0_alpha2 and the output of a test page looks as can be seen in the appended image "print_orig". I tried to track down the bug and ended in file image_cache.cls.php, function "resolve_url"

  static function resolve_url($url, $proto, $host, $base_path) {
 
    ...
    $parsed_url = explode_url($url);

    $remote = ($proto != "" && $proto != "file://");
    $remote = $remote || ($parsed_url['protocol'] != "");

    if ( !DOMPDF_ENABLE_REMOTE && $remote ) {
      $resolved_url = DOMPDF_LIB_DIR . "/res/broken_image.png";
      $ext = "png";

In lines seen above path components are checked to see if the file is a remote one.
Surprisingly it is classified as remote because of the leading protocol - which was appended before!
And when your dompdf config file is set up to reject remote files then an icon named "broken_image" is set as a placeholder for the image.

in file dompdf_config.inc.php setting

if (!defined("DOMPDF_ENABLE_REMOTE")) {
  // define("DOMPDF_ENABLE_REMOTE", false);
  define("DOMPDF_ENABLE_REMOTE", true);
}

solved THIS problem for me.

There seems still to be a problem remaining regarding fonts or CSS. See attached images

Thanks schildi! You solved the problem for me. A very simple "work-around" fix.

and please don't handle the hints above as a bug fix. It's just a work around!
Developers of the module probably expected that local files don't have a protocol in front of the URL (but file://). So the question still is: Why are file paths expanded this way?

On my installation with print 6.x-10 and dompdf-0.5.1 facts are:
- print preview works fine
- pdf generation generates [X] where images should be

The HTML used to generate the PDF also looks fine (tested using debug output).
./print_pdf/print_pdf.pages.inc:165:echo($html);

So the culprit must be in dompdf, and this is true:

in image_cache.cls.php we have around line 110:

$image = file_get_contents($url)

but on my system allow_url_fopen is off (PHP setting, security risk). <-- (!)

Setting it do "on" helps, although I would simply recommend not using a remote image then, instead use a relative path:
so instead of http://www.yourdomain.com/drupal/sites/www.yourdomain.com.drupal/themes/... (or alike)
just use 'themes/mytheme/logosmall.jpg' as the path.

This however is not possible since a URL is generated in any case as has been mentioned before.

Therefore I have made the following patch to the module at print.pages.inc around line 50:
I have extended "if ($file_downloads == FILE_DOWNLOADS_PRIVATE) {"
with an else block:

faulty patch removed -- see #45

which will now also convert the path to (public) files for the local domain to file:/// i.e. the pdf will generate correctly if LOCAL files are included and allow_url_fopen is off. Note: it will *not* generate images correctly that lie under the local domain but are not managed by Drupal (in case you have drupal running in a subdirectory and link to files in the parent directory, i.e. outside of $base_url).

As another note: on multisite installs with PHP as a fastcgi I don't like the hardcoded /tmp setting.
Change:
./lib/dompdf-0.5.1/dompdf_config.inc.php:73:define("DOMPDF_TEMP_DIR", sys_get_temp_dir());
./lib/dompdf-0.5.1/lib/class.pdf.php:4733: $tmpDir = sys_get_temp_dir();
(first check if your version of PHP supports sys_get_temp_dir())

JM

I first expected that all this logic should be done in the callback function _print_rewrite_urls (file print.pages.inc). But it looks that lines below "preg_replace_callback" - the "if ($file_downloads ==" part - does some correction to modification done by function _print_rewrite_urls.
OK, when applying the patch you provided (and reverting to DOMPDF_ENABLE_REMOTE=false) the problem raises again. The reason is that in my configuration file_downloads is set to FILE_DOWNLOADS_PRIVATE.
Obviously this is not the complete story.

Looking at your proposals:
* do you really mean directory conf_path in the replacement pattern?. Please check
* patch doesn't help at least when FILE_DOWNLOADS_PRIVATE is set
* DOMPDF_TEMP_DIR: done in dompdf-0.6x

May be someone can help me in my lack of comprehension:
* all text / images shown to a user by the print module should also be contained in the PDF version
* the print module does not distinguish between different image sources (PRIVATE / PUBLIC)
So, why should print_pdf introduce another level of security - which can collide with existing ones - by allowing / disallowing access to certain files? Isn't it enough to prefix local paths with "file://" ?
And shouldn't this logic be moved to function _print_rewrite_urls ?

Well, the "work-around" seemed to work for me posted #37.

But, it is a "work-around".

I cannot seem to get the else block in # 41 to work.

I hope this can be worked out as I see that it has become a very large security problem.

-- as a reply to #42 --

Sorry it took me a while -- I was busy ...

Concerning conf_path(): In the PUBLIC case I guess files don't need to be under 'files', but they of course can be, that's why I keep that more general in my setup -- feel free to change.

Obviously, my patch does nothing to the PRIVATE case, the problem seems to be FILE_DOWNLOADS_PRIVATE, not DOMPDF_ENABLE_REMOTE. Why do you set the latter one to disabled anyway? Better disallow allow_url_fopen in the first place. Anyway that shouldn't matter and I don't know where the error is. Probably something does not get correctly translated to the real path in the PRIVATE case on your system.

It looks as long as the path in the url is /system/files/something it should work... I tried it on a new install and it did. (see attachment which is a screenshot of the produced PDF)

* all text / images shown to a user by the print module should also be contained in the PDF version

They had better be ;-)

* the print module does not distinguish between different image sources (PRIVATE / PUBLIC)
So, why should print_pdf introduce another level of security - which can collide with existing ones - by allowing / disallowing access to certain files?

It doesn't, maybe your PHP configuration does as I noted in comment 41, since print_pdf (or more exactly: dompdf) involves retrieving remote files (which can be disabled in PHP) whereas print itself does not.

Isn't it enough to prefix local paths with "file://" ?

Yes it is, since that will no longer be classified as "remote" in dompdf, but for that, this remapping has to work... Put some debug code somewhere in your "if ($file_downloads == FILE_DOWNLOADS_PRIVATE) {" block and see if it actually does translate everything hxxp://XXXXX/system/files/YYY into file://(file_directory_path)/YYY

And shouldn't this logic be moved to function _print_rewrite_urls ?

Someone with a broader perspective on these things should maybe have a look...

-- as a reply to #43 --

I am meanwhile using another patch

--- print_pdf.pages.inc.orig    2010-02-28 19:43:04.000000000 +0100
+++ print_pdf.pages.inc 2010-02-28 19:43:56.000000000 +0100
@@ -57,10 +57,21 @@
     }
     $pattern = "!(<img\s[^>]*?src\s*?=\s*?['\"]?)${base_url}/(?:(?:index.php)?\?q=)?(?:${lang}/)?system/files(/[^>]*?>)!is";
     $replacement = '$1file://'. realpath(file_directory_path()) .'$2';
-    $print['content'] = preg_replace($pattern, $replacement, $print['content']);
-    $print['logo'] = preg_replace($pattern, $replacement, $print['logo']);
-    $print['footer_message'] = preg_replace($pattern, $replacement, $print['footer_message']);
   }
+  else { // jm
+    $pattern = "!(<img\s[^>]*?src\s*?=\s*?['\"]?)${base_url}/([^>]*?)>!is";
+    preg_match($pattern, $print['content'], $m);
+    if (substr($m[2], 0, strlen(conf_path())) == conf_path()) {
+      // removes double path
+      $replacement = '$1file://'. substr(realpath(conf_path()), 0, -strlen(conf_path())-1) .'/$2';
+    }
+    else {
+      $replacement = '$1file://'. realpath(conf_path()) .'/$2';
+    }
+  }
+  $print['content'] = preg_replace($pattern, $replacement, $print['content']);
+  $print['logo'] = preg_replace($pattern, $replacement, $print['logo']);
+  $print['footer_message'] = preg_replace($pattern, $replacement, $print['footer_message']);

   $node = $print['node'];
   ob_start();

I don't remember what was wrong with the first one, but one can see in the attachment that it works for a public file. (compare this to the previous comment's attachment where the screenshot for private download method is shown).

NoteThis seems to be a remedy to the images problem. How to make CSS work: no idea.

1) Bump...
2) Tested #37, works. (Turned around and undid it for noted security reasons.)
3) Tested patch #45: Code patch made no apparent difference, though I have absolutely no idea what is is you're trying to tell us to do in your public.png.

@sjpatrick
Image in #44 is supposed to show that it works for private downloads.
Image in #45 is supposed to show that it works for public download method.

JM, I tried this patch, as well as all of the other possible ones on this thread, for well over eight hours straight with absolutely no success whatsoever. I even went so far as to uninstall and reinstall DOMPDF's 5.1 version, because upgrading to their version 6.0 beta produced the white screen of death.

I really need help here... my problem is virtually the same as outlined by everyone else (it produces a passable PDF, but has [x] in place of the images with no CSS support).

The PHP page:
http://lcccradio.mudmagic.com/?q=talent

Rendered in Print Preview (pardon the pop-up window)
http://lcccradio.mudmagic.com/?q=print/talent

Rendered in DOMPDF:
http://lcccradio.mudmagic.com/?q=printpdf/talent

(For the record, yes, I did test to see if DOMPDF could generate images, and yes it does.)

Tinkering with this for virtually forever, I just can't figure out HOW to fix this bug... where do I exactly change the coding, how much needs to be changed, and what coding needs to be erased? The last thing I want to do is to just give up on the PDF option - TCPDF was even worse off for me, and I have no idea how to install wkhtmltopdf.

PS: How do I "subscribe" for further help?

The patch from #45 does work for me when the images are located in the site's files folder (which they are when uploaded e.g. using file attachments). It doesn't seem to work for images from anywhere else though.

Okay, thanks for the clarification. The site itself was imported to and modified with Drupal, so as a result the vast majority of images files are not in "files" folder. I'd rather not have to reload and redirect every single image file, so does this make this Dompdf problem non-repairable?

I'm sure there is a patch for everything. Feel free to come up with one :)

It may take a while to create... I've never really done anything like that before... ;)

Hello,

I've also the problem with the library dompdf.
I've patched like in #37. I've ever not the problem with the red X but I've only an icon with the name of the image instead of the image. If I click on the name, the link is good, it opened the image in a new window.

How to do to have the image instead of the icon and the name.

Have you succeed to display images?

More over, what is the unity to use in the CSS files to place block.
I use 1cm~=40px, is it the good way?

Thanks in advance

I was trying to get this to work for a long time, until the obvious struck me. My development server is seperate from the computer I'm working from and I'm working on a test site who's domain is only set in my local hosts file. Well, I forgot to set it up on the host file of the dev server. So, dompdf was trying to get the image using the absolute path but it was actually not there.. duh!

Thought I'd share this if anyone else got stuck similarly.

I can confirm #37 as well. The following patch adds the defines into print_php.module.

Thanks #37, this solved my problem too!

PS: I'm so going to buy you a beer for that !

Nice to hear!
But I would sugget you get a glass of a good wine.

Hmm #37 isnt working for me but I am using dompdf-0.5.1 and in the config we have:

define("DOMPDF_ENABLE_REMOTE", true);

So that seems to be enabled by default -- maybe I ought to try some of the other PDF generation tools...
- J

TCPDF still doesn't work:

TCPDF ERROR: [Image] Unable to get image width and height: /Applications/MAMP/htdocs/_cms/drupal-6.16-DE//default/files/imagecache/ ...

The problem seems to occur between the double slashes: instead of "drupal-6.16-DE//default" the URL should read: "drupal-6.16-DE/sites/default".

The patch from #55 works for me. I am using dompdf 0.5.1.

Can someone comment on the potential security issues using this patch, mentioned in #43?

#55 works for me using dompdf 0.6.0 beta1.

Neither #37 nor #55 worked for me using Print 6.x-1.10 and dompdf 0.6.0 beta1.

Tested. It works, thanks a lot. Port it please :) (dompdf 0.5.1)

#55 worked for me with dompdf 0.6.0 beta1 and the trunk snapshot of dompdf. I have also patched it with the following patches:

• #257896: dompdf and utf-8
• #785364: Incompability with php 5.3

Thanks for the patch! :)

Committed to CVS. I had to change the patch considerably, but thanks for the pointer!

João

Through the comments as above, I have my own way to resolve this problem:

in dompdf_config.inc.php, maybe line 333,
change from:

define("DOMPDF_ENABLE_REMOTE", false);

TO

define("DOMPDF_ENABLE_REMOTE", true);

in print_pdf.pages.inc, maybe line 60-62
I comment the code:

$print['content'] = preg_replace($pattern, $replacement, $print['content']);
$print['logo'] = preg_replace($pattern, $replacement, $print['logo']);
$print['footer_message'] = preg_replace($pattern, $replacement, $print['footer_message']);

I also had the problem of images not showing up and was able to fix it as kevin suggested in #14.
But now another issue comes up: I'd like to use an imagecache preset that's only used for pdf creation. When I change cck display settings to use this for the print display, the images don't get generated by imagecache. When the images have already created before they just get used fine by domepdf. It seems, pdf generation doesn't trigger imagecache to start processing images. Anybody aware of this (and maybe there's even a solution I couldn't figure out yet?)

I am having the same problem with wkhtmltopdf, strangely enough I was not having the problem with dompdf when I was trying that.

It may be possible, that your images are put as background-image in your HTML/PHP document. So for the reason print command doesn't support or print the background images / color to the document.

After working on this for the entire day, and following many of the suggestions above I came to realize (quite by accident) that dompdf would not render .png files. At least it doesn't in my configuration. Switched to .jpg files and all works just fine.

I don't recall seeing that in any of the documentation, and as I said it may be something unique to my configuration. However, if you're having trouble it might be worth trying, ymmv.

PDF version is still not picking up css/print.css on the latest D7 dev version of this module
Is there still no working patch after two years having this issue?

Not only .png, my installation does not work for .jpg files too.

See #1230480: Inline the CSS when sending the HTML to TCPDF for problem with CSS includes.