if Print PDF module is enabled cache pdf files as well :)

whats the path that the PDF module generates? is it something like node/12/pdf?

try this patch, let me know if it works. Caching new content types is semi trivial; add a little bit of code and the rest should work like magic. To test & make sure it works, I would set Boost Tags: Set Header and tags; and look at the header; make sure there is a boost header in there.

gzipping the pdf doesn't gain much; for a 3.5mb text pdf, i was able to get it down to 3.0mb. Source of that was 2.5mb text file, gzipping that reduces it down to 0.5mb.

does the code work?

Subscribing

Ok, it's been 2 years and no one has replied. But does the code work? I keep getting random characters when printpdf gets cached by boost. Is there a fix for that?

The module changed a bit internal – so we have to create a new patch for it.
I read the author don't see the need for the pdf caching and understand his point, but for some projects that might very helpful.

I'm going to try to add the new extension and filetype, but it will take some time, any tips are welcome ;)

7.x version of boost makes caching PDF's (or any other content type) very easy, create a sub module that implements a boost hook. I am aware of this issue, working on the best way to make this happen; granted I'm spread pretty thin right now so it will take time.

New patch against 6.x-1.21.
I didn't include htaccess rules for gzipped pdfs (they are generated anyway) because I had troubles with my browsers (Safari and Chrome) on delivery (they always downloaded zipped and didn't show up as pdf files). If somebody has a good idea to solve this it should be included. For the moment cached pdfs are delivered uncompressed even if the browser accepts gzipped data.

Still, they are smaller when they are zipped. I do not particularly insist on this, but I could see the bandwidth benefits.

I agree and respect your expertise :-)
Concerning the proposed patch: the gzipped pdfs are already created, because I didn't find a way of preventing the generation. So in this case it would be useful to deliver them. The processing has already been done. On the basis of your argument it would make a lot of sense to prevent the compression of the pdfs altogether.

This code works well.
I did need to cache images, I replicate the pdf stuff for the corresponding miage/jpeg and image/png that I was looking for caching.
This apparently works for anything.

A few mistakes, in boost.module:

in boost_cache_set()

-   elseif (stristr($types, 'image/jpeg') && BOOST_CACHE_HTML) {
+  elseif (stristr($types, 'image/jpeg') && BOOST_CACHE_PDF) {
        $extension = BOOST_PDF_EXTENSION;
     }

in boost_htaccess_cache_dir_generate()

added

-   if (!BOOST_DISABLE_CLEAN_URL && (BOOST_CACHE_HTML || BOOST_CACHE_XML || BOOST_CACHE_JSON)) {
+  if (!BOOST_DISABLE_CLEAN_URL && (BOOST_CACHE_HTML || BOOST_CACHE_XML || BOOST_CACHE_JSON || BOOST_CACHE_PDF)) {
/

modified

  +  if (BOOST_CACHE_PDF) {
-    $files .= "$_xml|";
+ $files .= "$_pdf|";
    $files = trim($files, '|');
    $string .= "<FilesMatch \"\.($files)$\">\n";
    $string .= "  ForceType application/pdf\n";
    $string .= "</FilesMatch>\n";
  }

Thanks!

I need to know whether a file is cached or not.
Is the time taken for the pdf loading the only indicator to say whether the pdf is cached or not?

Where is the cached pdf saved? only in the browser or somewhere in the directory inside the server?

I am closing this feature request, as Drupal 6 is no longer supported. Please re-open it if you would like the feature implemented in the Drupal 7 or 8 version of the module.