HtmlToPdf conversion within a loop for dynamic pages?

HtmlToPdf conversion within a loop for dynamic pages?

  
Afternoon OS,

I think I might be jumping a few steps in the process of hunting for a solution, but I am really looking for confirmation.

I need to be able to send an HTML formatted email - however, the SendEmail component's styling doesnt come through to the inbox (yes, I am clued up about the limitations on html styles in Email applications/programs)...

With that in mind I started searching for a way I could email a file accross to the recipient(s), enter HtmlToPdfConverter...
Is it possible to loop through a list of reciepients, dynamically build a html page (with parameters), convert to .pdf and then send each processes output within an email?
Sure. Just create a normal webscreen that receives your recepient userid, or similar, and displays the html as you want. Then iterate and use htmltopdf to convert your dynamic url something.com/?userid=12345 for each of your users. Does this solve?

Ok - so I can pass the Web Screen parameters in the HtmlToPdf URL parameter, within the loop.
This would create the page and the pdf file, correct?

I think so, yes.
Ok, cheers Pedro.

But should I use the 'HtmlToPdfConverter' or 'GeneratePDF' action?
The HtmlToPdfConverter action uses the Download action - but i cannot see how I could attach this to an email generated and sent from within the current application, instead of (ultimately) downloading multiple .pdf files.

Hi,

I assume that what you want is to send one e-mail with several PDF's as attachments. You could call GeneratePDF for each of the users in your loop (the URL would be the "something.com/?userid=12345") . This will return a PDF for each one (PDFBinary output variable). Than add each PDF as an attachment to your e-mail (I believe you can do this with the RichMail extension).


Afraid not Pedro.
I need to loop through multiple recipeint addresses, sending one email with a single dynamically generated .pdf attachment to each address... but the procedure you suggest should still be applicable - with a minor tweek.