Problem:

When I visit http://mysite.com/print/page-to-print, everything looks fine (my custom styles are being used). However, when I try to print the PDF of the same page (http://mysite.com/printpdf/page-to-print) the document is either unstyled or using this module's styles instead of my custom css. See attached images for a comparison between the print and the pdf versions.

Assumption: wkhtmltopdf uses the print version (http://mysite.com/print/page-to-print) to render the pdf
Expectation: PDF should look basically the same as the print version

Details:

Background

  • My VPS is setup using the Mercury stack
  • I have tested this with Varnish disabled, explicitly bypassing varnish and accessing the site directly through Apache, making sure caching is turned off all together, disabling css and js optimization, and lots and lots of clearing the cache
  • I have overridden the print.tpl.php by copying it into my theme next to the page template
  • I explicitly call my CSS file inside the print template (<link type="text/css" rel="stylesheet" media="all" href="/sites/path/to/my/theme/css/print.css" />)
  • I have removed the call to the print module CSS file, so my custom css is the only one included

Possible Symptoms

  • In the course of experimenting I also tried adding my custom css via the print admin UI (admin/settings/print/common) and received a warning message that my CSS file was unreadable by the webserver (%t/css/mycss.css). This is odd because my styles are clearly loading for the print version.
  • The PDF version has successfully rendered on one instance: in Chrome on my development iMac. However, on no other browser (including Chrome) on any other computer does the PDF use the right styles. Perhaps there is something I am missing on the client side?

Log Output

wkhtmltopdf: Loading pages (1/6) [> ] 0% [======> ] 10% [==========================> ] 44% [==========================> ] 44% [==========================> ] 44% [============================================================] 100% Counting pages (2/6) [============================================================] Object 1 of 1 Resolving links (4/6) [============================================================] Object 1 of 1 Loading headers and footers (5/6) Printing pages (6/6) [> ] Preparing [==> ] Page 1 of 22 [=====> ] Page 2 of 22 [=======> ] Page 3 of 22 [==========> ] Page 4 of 22 [=============> ] Page 5 of 22 [================> ] Page 6 of 22 [==================> ] Page 7 of 22 [=====================> ] Page 8 of 22 [========================> ] Page 9 of 22 [===========================> ] Page 10 of 22 [==============================> ] Page 11 of 22 [================================> ] Page 12 of 22 [===================================> ] Page 13 of 22 [=====================================> ] Page 14 of 22 [========================================> ] Page 15 of 22 [===========================================> ] Page 16 of 22 [==============================================> ] Page 17 of 22 [================================================> ] Page 18 of 22 [===================================================> ] Page 19 of 22 [======================================================> ] Page 20 of 22 [=========================================================> ] Page 21 of 22 [============================================================] Page 22 of 22 Done

Configuration

Module Settings:

  • Module version: 6.x-1.12
  • PDF converter: wkhtmltopdf beta 5 (wkthmltopdf-amd64 renamed to wkhtmltopdf and located in /usr/bin and symlinked in print/lib)

System:

  • Ubuntu 10.4 Lucid x64
  • Drupal: Pressflow 6.19
CommentFileSizeAuthor
PDF_page-styles_not_working.jpg247.59 KBAnonymous (not verified)
Regular_print_page-styles_working.jpg139.24 KBAnonymous (not verified)
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

Update: This problem is apparently only afflicting my computers (MacBook pro and an iMac). I've had two other people look at it and it looks fine for them. Does anyone know of a client side issue that would prevent wkhtmltopdf from rendering the styles?

Anonymous’s picture

update: Ignore the last update. Everyone else happened to be looking at the wrong IP (an older site, which the PDF converter worked on). It's still not working on the current environment.

This is definitely a server side issue. I've tried PrinceXML, which works in a similar principal to wkthmltopdf and the result is the same. Also, I tried removing the overridden template and using the module defaults. Next I specified my custom css and it loaded successfully in the print version (no warning as I had previously reported). However, the PDF version is still rendered without any of the CSS applied.

The problem is now narrowed down to why the converter's browser is unable to load the CSS.

ice5nake’s picture

It appears to me that relative paths are not being resolved properly.

When I run:

sudo -u apache wkhtmltopdf http://webmirror.hbg.psu.edu/programs/bachelor-science-marketing /var/www/html/sites/default/files/test.pdf

The PDF has relative images and uses relative CSS.

However when I visit the the link that the print module puts on my page it doesn't work that way. It doesn't appear to resolve the relative paths.

Could this be a result of the input to wkhtmltopdf being done through stdin when the print module calls it? It appears the print module gives wkhtmltopdf the html rather than when it's done through the command line wkhtmltopdf is given a URL.

I suspect this could be bypassing wkhtmltopdf's link resolving features.

Anonymous’s picture

I was able to resolve the issue by calling the CSS explicitly in the print template using an absolute path.

adamwhite’s picture

I've experienced similar issues.

When I'm on the same internal network as my staging machine wkhtmltopdf works flawlessly. When I connect to that same machine from outside the network, where a different domain name is forwarding to it, the PDFs are output with no styling. Note that the external domain name can't be resolved behind the network equipment in the internal network, that's the key here. By hard-coding absolute paths to the print.css the PDF generation works when accessing the site from that other external address.

So to get this working in my print.tpl.php I've added:

<link type="text/css" rel="stylesheet" media="screen" href="http://localdomainname/etc/etc/print.css" />

(note that it's media=screen, not print)

I doubt this will be a problem in production but it threw me for a loop while developing. At this stage the PDF generation takes forever from the external addresses as well, but I'm not yet certain that's a related issue.

texas-bronius’s picture

I'll chime in and second @adamwhite's comment about absolute url. In the part loading my PDF's .tpl.php, I set $base_url with something along the lines of:

$base_url = url(drupal_get_path('module', 'wkhtmltopdf') .'/templates/'. $whichpdf .'/', array('absolute' => TRUE));

(note, mine's a custom module, wrapping the same wkhtmltopdf binary) and then in the PDF's tpl.php, I set:

  <base href="<?php print $base_url; ?>" />

before the various stylesheet links going on. I found it important to have wkhtmltopdf know where my site is and where all its images and other css attached to PDF templates are.

But my reason for finding this thread is to learn why wkhtmltopdf is caching css and how to get it "to not to."
[edit: oops] And as it turns out, it was not that my wkhtmltopdf was caching but something was clogging the cogs, and no error was being thrown-- as if there were still a buffer or process going.. It's all better now, and I can see that wkhtmltopdf's webkit is not caching the css.

Poke: Hey Andrew!

sdsheridan’s picture

Well, I spent some time working on this issue, as it was making me crazy, and I didn't want to have to fiddle with unnecessary .tpl.php files to fiddle a work-around. So instead, I did the following.

I'm using dompdf, and was having the same issues. so I added the following into print_pdf.pages.inc in function print_pdf_controller down at line 59 just before it deals with the file name:

  $pattern = '!<link\s+type="text/css"\s+rel="stylesheet"\s+media="([^"]*)"\s+href="([^"]*)"(.*)$!';
  $replacement = '<link type="text/css" rel="stylesheet" media="\1" href="'.$base_url.'\2"\3';
  $html = preg_replace($pattern, $replacement, $html);

What this does is effectively find all the css relative href links in the HTML head and makes them absolute. Once I did this, dompdf seemed to have no problem finding the CSS and applying it correctly, including my custom print.css.

This is working brilliantly now for me, although there is still an issue with any relative URLs in the css files for things such as background images in a style. However, all my borders, fonts, background colours, spacing, etc. are all working as expected.

Would be great if this found its way into the next release.

Shawn

essbee’s picture

I went a different route to solve the same problem, which involved removing code rather than adding more.

Currently in print.pages.inc in _print_var_generator() if the page is being sent by email it embeds the CSS. I simply commented out the if statement (lines 196, 206-209) so that it embeds the CSS in all scenarios. This ensures the PDF doesnt even need to download css files.

Possibly worth considering, maybe not for all, but at least for PDF generated pages.

Cheers,
Sam

jcnventura’s picture

Status: Active » Needs review
mesr01’s picture

Following.

jcnventura’s picture

Status: Needs review » Closed (cannot reproduce)

I never managed to reproduce this...

I've just tested and the CSS is applied, to the extent that the CSS is supported by the tools (only wkhtmltopdf supports 100%).

frishaynes’s picture

#5 worked for me to fix wkhtmltopdf output after many hours. Thank you.

RumpledElf’s picture

I just hit the same issue, using dompdf. Works great on my dev server, took it to staging and bam, no css. And not having any luck with solutions in this thread.

knigh7’s picture

have you found a solution fort his, I seem to have the same issue

Jaapx’s picture

Edit: Ignore the problem description below. The cause was an error in the serverconfig. The website was denied permission when called from a proces on the server.
------------------

I have the same problem as described above using print module version 7.x - 2.0 with wkhhtmltopdf version 0.11.0
- at first the generated pdf's were perfect but suddenly the css and images couldn 't be found with the message in the log: No stderr output available.
- another site on the same server prints the pdf's with wkhtmltopf correct.

Several tries:
- output of the $html variable that is input for wkhtmltopdf ( fwrite($pipes[0], $html); in line 58 of print_pdf.wkhtmltopdf.pages.inc). Html is perfect, absolute paths for css etc.
- force inline css by setting $expand to true in module _print_css_generator (file print/print.pages.inc ) . This is the same solution of #8 above but now for version 2.0 of the print module. Works for CSS, but images aren't still loaded.

Conclusion: wkhtmltopdf sometimes has a problem to find CSS en images files. Cause unknown. http://stackoverflow.com/questions/16627310/wkhtmltopdf-not-loading-loca... also mentions this but offered no solution for me.

A workaround is converting the html for wkhtmltopdf to html with inline css and images as is done for e-mails. Maybe somebody has a better solution? Maybe also a feature for this module to improve reliability?

jvieille’s picture

For an unknown reason, print pdf stopped taking CSS into considration - theme default or print.css and and showing images .
#8 was the solution for CSS, still searching for images

lunk rat’s picture

When wkhtmltopdf won't apply stylesheets but your print version does apply stylesheets, it is very likely caused by the wkhtmltopdf binary being unable to retrieve your stylesheet <link> tags because the href uses the https protocol, due to the TLS implementation of the wkhtmltopdf executable.

#8/#15 above work, but they alter the module code directly and are thus not in line with best practices for sustainable sites.

Possible solutions:

  • Create a new configuration option for $expand so that it can be applied to PDF versions if needed.
  • Or, make $expand default for PDF versions
  • Or, fix the implementation of linked stylesheets in print_pdf so that it works around potential https issues with the wkhtmltopdf binary

SIDE NOTE:
Note that the wkhtmltopdf binary is sensitive to DNS hosts entries on the server, so if your issues with stylesheet linking don't seem to be https-related, please see 1687736#comment-13834390 for an explanation of why you might want to take a look at your server's host entries when troubleshooting wkhtmltopdf.