If you create a plain ole' Page node and paste the contents of the attached file (too.large_.txt) into that page and try to render the page to PDF using the print module, then I get a blank page generated by the print module. I'm using the TCPDF module to render to PDF. I haven't any idea on how to determine if the problem is related to TCPDF or something in the calling machinery of this print module. So help is required to pin-point who is at fault. If you remove the final extra period on the last sentence of the attached file then it renders a 7-page PDF just fine. Appears to be some magic number on total size of content that causes the PDF generation to fail.
Any thoughts here?
Details on my setup:
* Ubuntu 8.04.3 LTS
* Linux 2.6.24-24-virtual #1 SMP Fri Sep 18 17:58:20 UTC 2009 i686 GNU/Linux
* Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.7 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g
* Drupal 6.14
* PHP 5.2.4-2ubuntu5.7
* PHP memory limit 256M
| Comment | File | Size | Author |
|---|---|---|---|
| too.large_.txt | 31.77 KB | alphasupremicus |
Comments
Comment #1
alphasupremicus commentedI failed to mention that the provided page content is right up around 32K in size (32,454 characters to be precise). Maybe with the extra URL reference provided at the bottom and headers/footers that are added to the PDF -- this thing hits 32K and blows some memory variable? I'm just grasping at straws here, but it's a thought.
Oh, I'm using this version of TCPDF --> tcpdf_4_8_014.zip
Comment #2
alphasupremicus commentedOkay, so I went and installed wkhtmltopdf static binaries and the Xvfb package for my box. Yep, this page works fine under that setup. The above problem must be related to some size-limitation of the text getting sent to TCPDF. wkhtmltopdf is pretty cool, but is a bit slower -- but a truer rendering of the site. I'm likely to stay with wkhtmltopdf for the time being so this is being downgraded from critical to minor.
Does anyone else concur with my analysis? TCPDF must have some limitation to the total size of text it can render to PDF? Seems odd since folks on that TCPDF sourceforge site were asking if it could render a 50,000 page PDF so a mere 7-page document should be doable, but maybe not?
Comment #3
jcnventuraGlad to know that you solved the problem.
There's really nothing much I can do about it.. You seem to have found a bug in TCPDF, which I would ask to report to TCPDF's maintainer.
João
Comment #4
alphasupremicus commentedOk -- thanks. I may not report the error because I've moved on to the other PDF module. But odd that it would be so flakey and freak out at 32K of text on a single page.
Comment #5
ezra-g commentedFor reference, I submitted a bug in Sourceforge's issue queue or TCPDF, since this seems like a significant issue: https://sourceforge.net/tracker/?func=detail&aid=2903970&group_id=128076...
Comment #6
sumsum commentedhey, can you provide some information about this issue? I'm fighting with this problem. I tested a lot and I can agree that this is a file-size limitation. Please let me know if there is a solution...
Comment #7
vsmiller commentedIt's a memory issue during tcpdf rendering. I just installed and ran into it. I threw my servers memory limit up to 64MB to test and it rendered just fine. Didn't test limits at 32MB, just jumped to 64MB.
I do not recommend setting your memory limits too high in php.ini, or via apache. I did mine with ini_set directly on the tcpdf_config.php file: ini_set('memory_limit', '64M');
Obviously, php safe mode must be disabled to do so. If safe mode is enabled, you can only increase the memory limit by editting the php.ini file.
Cache, cache, cache, cache, cache.
If TCPDF is going to be eating a lot of memory, it needs to be cached!
Doesn't look like it's doing any caching now though with the print module usage.
Add Disallow: /printpdf/ to your robots.txt file (if you're using the print module) to help try and keep bots from spiking your server load (and indexing duplicate content in pdf).