I have a survey node type, that has about 100 fields - 75-80 that appear on view.
When I submit a node with about half the fields entered, the pdf will generate properly.

But if I submit with most or all fields answered, the pdf is blank.

The print & email versions work properly in all cases.

Is there a page or other limitation that could be causing this?
If so, how to increase limit?

Using:
Drupal 6.14
CCK 2.5
Print 1.8 with TCPDF

On Apache/2.0.52
PHP 5.2.6
MySQL 4.1.22

Any help you can provide will be appreciated.
Thanks

Comments

goldoak jp’s picture

goldoak jp commented
Assigned: goldoak jp » Unassigned
goldoak jp’s picture

goldoak jp commented

Upon further testing it appears that the limit is about 6 pages.
By manipulating the fields that are set to display on the print page, I can reproduce the condition with different fields, nodes and browsers.

How can I increase the limit of pages for pdfs?

Thanks

jcnventura’s picture

jcnventura
Primary language English
commented
Status: Active » Postponed (maintainer needs more info)

Try increasing PHP's memory limit to see if you manage to generate all the fields..

goldoak jp’s picture

goldoak jp commented

Thanks for the suggestion, but that didn't seem to help.

It was at 64 Mb, then we increased to 96 Mb, but it made no difference.
Still seems to be limited at about 6 pages.

Other than the site logo in the header, these nodes are all text so should be fairly simple to process. I'm guessing the full content will need about 8 or 9 pages - maybe more once we do some formatting.

What would think the PHP memory limit should be set at?

jcnventura’s picture

jcnventura
Primary language English
commented

Are you using tables?? TCPDF seems to choke up on those.

Other than that, I'd like to see an example of such a page. Can you PM to me a URL to that page or a copy of the printer-friendly version?

goldoak jp’s picture

goldoak jp commented

No tables.
Using default print page from Zen.

I've sent you a message from your contact page with a URL to the print page. Hope that is what you meant by "PM".

Thanks

jcnventura’s picture

jcnventura
Primary language English
commented

I'll take a look into it then.. I need you to provide access to the print version to the anonymous user, though..

goldoak jp’s picture

goldoak jp commented

Oh yea,
I've set permissions for the print, pdf & email versions, as well as to view all the fields for anonymous users.

Thanks

jcnventura’s picture

jcnventura
Primary language English
commented
Status: Postponed (maintainer needs more info) » Active
goldoak jp’s picture

goldoak jp commented

I've tried dompdf now and that doesn't give blank page when all content is present. So that's good, I guess.

But it all shows in the top 1" of the page, all the fields on top of each other in a unreadable blob.

Why doesn't the pdf show like the printer-friendly page?

I've tried it with no style sheet specified in the module config, tried it with the print.css file that comes with your module, and with the style.css file that comes with dompdf. They all give the same result.

How do I configure so that dompdf uses the same css as the print-friendly page?

Why did you change status of this issue to "postponed..."? Are you waiting for info from me?

Thanks

jcnventura’s picture

jcnventura
Primary language English
commented

Hi,

The unreadeable fields are probably caused by the use of the <fieldset> tag which isn't supported by dompdf (#373725: Fieldsets not supported? ).

I actually changed the status from postponed to active, as I still have to try your data in my test site.

goldoak jp’s picture

goldoak jp commented

Hi
Thanks for the info.
I've changed the fieldsets to "simple" on print display and that fixed the blob. Getting closer!

Now I just need to figure out how to apply some styling. How do I make dompdf use a stylesheet?

Thanks

jcnventura’s picture

jcnventura
Primary language English
commented
Status: Active » Postponed (maintainer needs more info)

In my tests, I was actually unable to get dompdf 0.5.1 to work on your page.

However, since you've got it working, I guess I don't need to bother myself with it.

As to your question, there's two ways you can use to specify a stylesheet.

1. You can set your own CSS file in the module settings page, or
2. You can add your CSS file to the the module's CSS file or to the print.tpl.php file.

João

goldoak jp’s picture

goldoak jp commented

Thanks, João

I have specified a style sheet via the print module settings and that style sheet gets used for the PF page, but not for the PDF. Shouldn't the PF page and the PDF file be using the same CSS file?

I've tried using the "style.css" file located in the 'print/dompdf/www' directory and I've tried using the "print.css" file that is in the 'print/css' directory. Neither way makes any difference in the pdf file.

Also the PDF file does not show the images (just red boxes) that should be in the header & footer. If those images can be found for the PF page, why can't the PDF find them?

I've read through all the docs, but I'm not seeing what I'm doing wrong. Got any ideas?

Thanks again!

jcnventura’s picture

jcnventura
Primary language English
commented

The PDF version uses the same CSS as the printer version. It seems weird that it doesn't apply. Try to change the body font size or something like that to test for it, please. Use the print/css/print.css file as your base.

You're still using dompdf right? TCPDF has no support for CSS files..

As to the red boxes for the head and footer images, that's usually a problem in accessing the image.

goldoak jp’s picture

goldoak jp commented

Hi
I think I found the problem.
The dompdf config file has a setting for "DOMPDF_ENABLE_REMOTE". The default is set to false, but needs to be true so that dompdf can access image & css files...remotely, I guess.

I didn't think that just another directory on the same server would be considered "remote", plus with the security warning, I had left it as false. But when I changed it to true, I got my styling and images to show on the PDF.

Also found out that dompdf does not fully support css so now I have to figure out how to layout the reports without using floats, visibility, or positioning.

Anyway, thanks again for your help.

jcnventura’s picture

jcnventura
Primary language English
commented
Status: Postponed (maintainer needs more info) » Fixed

Strange.. That setting is set by default to true in my case (dompdf 0.5.1).. Which version of dompdf are you using?

I am guessing remote access means anything that gets accessed via http, even if it is in the same server.

Anyway, I am setting this to fixed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

ezra-g’s picture

ezra-g commented

For 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...