Thanks a lot @Joffm for these clear examples!

Now my last concern would be about the scale of our survey: it currently has 124 questions! (yeah… I know… we are working on down-scaling it as much as we can)

So, will a single pdfReport question text space (a textarea I suppose) be able to contain the whole design? Or will we have to split it into multiple pdfReport questions? (is it even possible?)

Also, I understand the generated PDF will then be available as an answer attachment, correct? Because we will need to have a way of retrieving it through API calls after then, in which case get_uploaded_files will be the way, correct?

1. The question text is implemented as type "text" in the database.
Of course, it's up to you.
Plain
{Q1.question}: {Q1}
{Q2.question}: {Q2.shown}
...
will not require a lot of space.
But if you use a lot of HTML and inline styling, you obviously will need more.
 

2, The initial requirement was

When the end user completes the survey, a summary page is dispalyed.

Now you add this new one

Because we will need to have a way of retrieving it through API calls after then,

This seems to be something different.
But there is the method "get_uploaded_files"

Joffm

1. thanks for this precision ("text" type in DB); I was more concerned about the "textarea" limits than the DB limits, but we'll see…

2. thanks for the confirmation on "get_uploaded_files"; actually the need to generate a PDF, to be included in some external process, is our main goal, but I agree it was not expressed as such in this thread.

 I was more concerned about the "textarea" limits

What "textarea"?
Sorry, I do not understand what you are talking about

There is no "textarea" involved.
You use the question text of a question "file upload".

Joffm
 

Well, the "question text", you fill it through a web form, right? And the usual (and largest) text input object in a web form is a <textarea>. So I was wondering if we could hit any limitation here.

I've read since then that some brother limit it to 512 Kio, which surely is large enough for most usage, so we should be ok. But it's funny I can't find any official statement about it… There can't be “no limit” for sure.

No (know) browser limit
www.php.net/manual/en/ini.core.php#ini.post-max-size

And if you have a light internet connexion, even 512Ko can take time.

Look at the php settings "post_max_size" and "upload_max_filesize".

Joffm

wrote:

Look at the php settings "post_max_size" and "upload_max_filesize".

Joffm
 

With textarea : i think only post_max_size is chekced.

BUT : the textarea is saved in a DB text type …

And even in multiple text question : it can broke : MSQL limit for a row are 8Mb

An alternative method is to render your report in html first (which people seem to find easier to format than PDF) then using wkhtmltopdf.org/ which converts html to PDF via the command line.

It's easy enough to create an html version of your report in the final page text setting by using the expression manager to extract the answers, which also means you don't need to access the API.

Quick question: is there a default or auto-generated HTML template we could use with pdfReport, or do we really have to write a specific HTML template for every surveys (which also means manually process every fields in it, and re-implementing their display logic too)?

I saw in the README.md (at GitLab) that there are default stylesheets (CSS) from pdfReport and limeMpdf, but I can't find anything about a default or auto-generated HTML template, which would produce a basic default PDF for any survey. Did I miss something?

Project, but no time to work on it.

And bugs.limesurvey.org/view.php?id=14353

If LimeSurvey print sytem work out of the box, less needed.

To answer one question of the first original post.

Export to PDF queXML : this option will generate a PDF without metadata, yet all the answers are truncated to the first 10 characters.

[url] forums.limesurvey.org/forum/design-issue...-whole-answer#181273 [/url]

Joffm