Why are my 3rd-party HTML to PDF tools not recognized in Drupal 6 using Print module?

Question

I have installed Drupal 6 and have the "Printer, e-mail and PDF versions" aka "Print" module installed.

I then realized in order to generate PDF's from my html nodes that I need a third-party tool, which is fine but the Print module is not recognizing the third-party tools I have installed in the /modules/print/lib/ directory. I get the following error in the "Home › Administer › Site configuration › Printer, e-mail and PDF versions" page:

"No PDF generation tool found! Please dowload a supported PHP PDF generation tool. Check this module's INSTALL.txt for more details."

I have set 755 permissions on the folders and files for the third-party tools, as most of my other settings are set to that as well.

I have installed two of the three recommended third-party PHP PDF generating tools:

1) http://dompdf.googlecode.com/files/dompdf-0.5.1.zip 2) http://wkhtmltopdf.googlecode.com/files/wkhtmltopdf-0.8.3.tar.bz2

Why am I seeing the "No PDF generation tool found! Please dowload a supported PHP PDF generation tool. Check this module's INSTALL.txt for more details." error message? And why is the Print module not recognizing my third-party tools?

Answer 1

Just checking - did you extract the libraries from the archives?

The folder would look like /sites/all/modules/print/lib/dompdf for example

Answer 2

Hm, just tried locally and it works for me, so you should double check your setup:

The module tries to find the installed libraries via the _print_pdf_tools() function in print_pdf.admin.inc. The function searches for a specific 'key' file per possible library in two places (assuming that if that file is ther, the whole library will be there as well):

1. in 'sites/all/libraries'
2. in the directory of the print module (should be 'modules/print' in your case)

It searches those directories recursively, so it should find them in arbitrary subdirectories as well, and the actual naming of the library directories should not matter.

Taking dompdf as an example here - it will be identified by its dompdf_config.inc.php file.

So you should check:

1. that this file is really present in the directory where you extracted dompdf to (from your comments, this should be modules/print/lib/dompdf-0.5.1)
2. that it is readable for your webserver process (you said you changed the permissions - did you do this recursively, and did you adjust the owner and/or group as well?)

The 'key' files used for identifying the other two libraries would be:

• tcpdf.php for TCPDF
• wkhtmltopdf or wkhtmltopdf.exe for wkhtmltopdf

Answer 3

wkhtmltopdf:

(Linux) No longer requires an XServer to be running (however the X11 client libs must be installed)

I am 85% sure that Dreamhost doesn't have X11 client libs on their shared hosting; you should have got errors while trying to compile wkhtmltopdf on dreamhost. By the way, try running uname -a in SSH session to dreamhost to find out their OS.

If you did manage to make wkhtmltopdf work on your local test server (which involves compiling the source tarball you linked to), you may have some luck using a pre-compiled static binary version from http://wkhtmltopdf.googlecode.com/files/wkhtmltopdf-0.8.3-static.tar.bz2

dompdf

The only thing dompdf requires is fonts. Have you followed the INSTALL instructions? If yes - try running some conversion with command-line, to see which errors prevent it from functioning. You haven't provided enough information to diagnose this one.