Print to PDF appears to outrun wkhtmltopdf on Windows with Apache and PDF doesn't download

I take it that you have corrected the 1.10 typo first mentioned in #521776: Windows wkhtmltopdf support, as your description of line 315 doesn't include it.

If the return is a null string, it means that it managed to open the file, but but failed in reading it. Can you make sure that the file exists by doing a var_dump(file_exists($pdf_output)) before the file_get_contents call ?

I guess the way to solve this would be to not use file_get_contents but to replace it with:

$fh = fopen($pdf_output, 'r');
flock($fh, LOCK_EX)
$pdf = fread($fh, filesize($pdf_output));
fclose($fh);

Can you also test the above code and tell me if it works for you?

João

Well, if Windows needs to sleep, then sleep it shall.

@jcnventura: I can confirm that this works with my site also, but I must disable 'send directly to printer', as you had asked me to do in the other post #521776: Windows wkhtmltopdf support

@dogbertdp: Just wanted to say thanks, and nice work. Makes me wish I could code.

Jim

Hi,

I tried the above patch but with not much luck. The files stayed 0 bytes. So i changed the code slightly so it is now a bit different for windows (but works).

I replaced the $cmd= line with

  //veg: added
  $htm_output = (stristr(PHP_OS, 'Win')) ? tempnam(file_directory_temp(), 'htm') : '-';
  if (stristr(PHP_OS, 'Win')) {
    $fh = fopen($htm_output, 'w') or die("can't open file");
    fwrite($fh, $html);
    fflush($fh);
    fclose($fh);

    //veg: changed,  inserted < %$htm_output
    $cmd = realpath($print_pdf_pdf_tool) ." --page-size $print_pdf_paper_size --orientation $print_pdf_page_orientation --dpi $dpi $print_pdf_wkhtmltopdf_options - $pdf_output < $htm_output";
  } else {
    $cmd = realpath($print_pdf_pdf_tool) ." --page-size $print_pdf_paper_size --orientation $print_pdf_page_orientation --dpi $dpi $print_pdf_wkhtmltopdf_options - $pdf_output";
  }

So windows now used a temp htm file on disk and uses a piping symbol ('<') instead of the pipes directly. And start with a sleep before requesting the filesize(). In my case I had a couple of time that the filesize kept returning 0 when the file already had size (must the the error filesize can return).

Next I untwined the *nix/windows code:

  if (is_resource($process)) {
    //veg: moved to else clause..
    //fwrite($pipes[0], $html);
    //fclose($pipes[0]);

    if (stristr(PHP_OS, 'Win')) {
      // It seems Windows can't use the pipe properly so get the contents from a file and then delete it.
      //$pdf = file_get_contents($pdf_output);

      //veg: Added
      //Make sure wkhtmltopdf is done writing the temporary PDF.      
      
      $file_size_stable = FALSE;
      $file_size_then = -1;
     while (!$file_size_stable && file_exists($pdf_output))
      {
        sleep(1);
        
        $file_size_now = filesize($pdf_output);
        if ($file_size_then < $file_size_now || $file_size_now == 0) {
  	  $file_size_then = $file_size_now;
 	  //sleep(1);
        } else {
	  $file_size_stable = TRUE;
        }
      }      
      $pdf = file_get_contents($pdf_output);

      //veg: added	      
      unlink($pdf_output);
      unlink($htm_output);
    }
    else {
      //veg: moved from above
      fwrite($pipes[0], $html);
      fclose($pipes[0]);
      
      $pdf = stream_get_contents($pipes[1]);
    }
    fclose($pipes[1]);

I have recently managed to get pdf printing working on Windows, using wkhtmltopdf. In case it helps anyone else, here is what I did.

Using print module 6.x-1.x-dev (2010-Jan-12), Drupal 6.12, Windows server 2003 with Apache and php 5.

download wkhtmltopdf 0.9.5 and install to modules/print/lib. Note that this version of wkhtmltopdf corrects the bug which resulted in no output to stdout, and required much of the OS specific patching above.

Remove Win OS specific conditional processing in print.pdf.pages.inc - $pdf is populated from the pipe regardless of OS, and there is no need for a temporary pdf file.

Remove the --dpi $dpi command line option from the $cmd used to invoke wkhtmltopdf in print.pdf.pages.inc - this does not seem to be a valid option in this version and causes an acrobat "wrong operand type" error and a blank pdf file to be generated.

No temp files, no sleeping, no file size checks, no OS dependencies. Hope this helps.

I really wanted wkhtmltopdf to work, but I had to give up. I have the latest, and I even tried the tweaks in #9. What happens is, nothing happens; the target page reloads, I get a zero byte file in the server's windows\temp folder and no PDF. It feels like a problem with a parameter, but I just don't have time to figure out what the parameters ARE that the module is sending it that aren't making it happy. If I could figure that out, I could run that command on the server and see what happens (perhaps the stream is not getting closed with control-Z?).

TCPDF worked the first time, Windows server and all.

A patch for what Mikeq said: when using wkhtmltopdf 0.9.5 it'll work right out of the box, no workarounds required for Windows anymore.

Patch totally works, thanks!

I am noticing that the output of wkhtmltopdf is fairly different from that of tcpdf on printing the same node. Different enough to possibly need to tweak settings, and I'm actually leaning toward tcpdf as the more attractive of the two, just out of the box.

I have the logo print turned on, and the logo is too small with wkhtmltopdf. Tcpdf adds a nice footer rule line and prints the breadcrumb, although it uses a smaller font and overrides the link color to match the body text color instead of leaving them blue.

I confirm that the above worked. For those using IIS (not sure about Apache on Win), you may also have to do the following:

1) Browse to where cmd.exe is and grant execute permission to the anonymous user that the web site uses to run things. This eliminates a proc_open error.

2) Not sure if I needed to do this or not, but granted the anonymous user read/write access to C:\windows\temp.

3) Because the wkhtmltopdf is an executable, make sure your site in IIS is set to run both scripts and executables.

I think that is it. The PDF generated looks the same as the printer friendly version. I would imagine that is what it is supposed to look like unless I create different tpl files, right?

Can someone else please test and hopefully confirm the patch so this can go to "reviewed and tested" and possibly rolled out? That would be cool, thanks.

I should mention, I was having this problem on a system that did not have wkhtmltopdf, it is using TCPDF, and the patch fixed it right up.

The patch #11 works for me. Thanks.
-Windows 2008 (x86)
-Apache
-wkhtmltopdf 0.9.9

I've just committed #11 to CVS.

I seem to be having this problem with the following:

-Windows server 2003 sp2
-Apache/2.2.11
-PHP 5.2.14
-Drupal 6.20
-Print 6.x-1.12
-wkhtmltopdf 0.9.9

wkhtlmltopdf works fine from the command line, there's no watchdog messages, no php log messages, and no apache log messages. Both tcpdf and dompdf work fine (though their output is unsatisfactory).

The browser just spins and spins and never comes back so I'm at a loss as to how to continue troubleshooting-- any suggestions would be greatly appreciated.

Check for NTFS permissions on the Windows temp folder. Try granting rights for your web server's anonymous user, IUSR_SERVERNAME or the account that the PHP ISAPI application pool is using, possibly IWAM_SERVERNAME.

Look for temp files with zero byte sizes and time stamps that correspond to your print attempts, I had to search the whole server disk for files modified within the past day and sort the result set by date modified to see where it was trying to work.

Using 'die' i've narrowed it down to it definitely failing on the line 351 of print_pdf.pages.inc fwrite. But i'm using apache and there is no IUSR_SERVERNAME or IWAM_SERVERNAME and I can't find any 0 byte files either (plus tcpdf and dompdf work fine with the current permissions).

ok, after troubleshooting this for hours, I stumbled across the problem-- it doesn't like the "--disable-local-file-access" option-- if I remove that everything works as expected. I couldn't find any documentation about that option so I don't know what it does or what the ramifications of removing it are.

any one know what that option is?

and i just confirmed the same problem with print 6.x-1.x-dev -- and commenting out the "--disable-local-file-access" line also fixes it.

Thanks for the correction, I think Apache runs as 'system' so that's not it.

Possibly related: http://drupal.org/node/892920#comments

If I am reading it correctly, and this is not a given, the gist is, with the latest patch to this module which was for security, if you keep the directive (un-mod the module code), you would now also need to allow anonymous users to access uploaded files in permission administration, since the process making the PDF is accessing the site over http as an anonymous user. Possibly only relevant for private file systems. I have not tested any of this, though.

@verta -- thanks for all your help. For some reason I didn't come across that link or the security advisory when I googled '--disable-local-file-access'.

In any case, my site is an intranet site behind a firewall and no one but admins have access to unfiltered html. So, if I understand the issue with "--disable-local-file-access", I should be ok. Besides, if there is a hacking problem in that scenario I have more serious problems than wkhtmltopdf security, lol.

as a side note to anyone who stumbles across this issue-- wkhtmltopdf is by far the best pdf renderer choice. It solved all my output problems and blows tcpdf and dompdf away. well worth the time I spent troubleshooting to get it working.

guess we can consider this closed again.

I totally agree, way superior output. I'll revisit it, now that this is closed with a workaround.