renderhtmlform service appropriate for emails?

[Billysscreennam]

Hi all, I'm trying to use the renderhtml service to render forms into html to place into an email. However, when I open the email with different clients the html gets wonky (especially in Outlook 2007). I'm wondering if there is a more suitable service to use, or what parameters to set for the service to make the html more email friendly. I know that there there should only be inline styles and that it should transform to NoScriptXHTML, but are there any other options that i'm missing?

Thanks!

[_Nith_]

Outlook 2007 doesn't support all HTML tags except few. (e.g it supports hyperlink, font styles, color but not buttons, text inputs, checkboxes etc.)

It internally use MS Word rendering engine to render the HTML content. Hence your output will not be interactive.

Why don't you prefer attaching PDF forms to email and receive completed form through email?

Nith

[Billysscreennam]

The forms themselves are non interactive and static, so there are no form fields (text boxes, checkboxes, etc) anyway, just static txt with floating fields. The actual process is that a external program calls the process, the process pulls info and merges it into the form, the form is converted into html to email out (by another external system), and the form is stored for archiving purposes So in short, the resultant html does not need to be interactive, I just need it to look good. I realize that outlook, gmail, hotmail don't adhere to any real standard but I know that the renderhtmlform service can convert the form to xhtml, noscriptxhtml, etc, and to so extent you can manipulate the css with an external stylesheet. However, as you pointed out, some tags are not recognized by the email clients, so i'm asking if there is a set of configurations that will allow you to create an html file that is email friendly.

Unfortunately, the business requirements are that the email contains the form as an html rather than a attached pdf.

[Billysscreennam]

Hey all, i figured I would update with the solution that we came up.

We  noticed that when converting xdp to html, the best way to maintain  structure was by using tables. Subforms convert to divs, however email  clients do not always render divs properly, so we stuck to using tables  to structure our forms and also to control the layout of our forms.  However, the layout got messed up we did the conversion, so the solution  that we came up with was to use the renderHTMLForm service with the  option of nostyles, and to add the styles in manually.

Essentially  we noticed that all of the names of complex objects (objects containing  other objects, ie subforms, tables, table rows) that we created in the  form would be carried over into the created html, with some additions.

So if we have a table called Details, which was in a a subform called Content, it would be converted to a table with id=NContent_0.NDetails_0.

I'm  not sure what the "N" denotes, but the ) at the end is the index of the  object, so if you have repeating elements, the index would be noted at  the end.

At this point, ideally, we would have liked to  user the renderHTMLForms to import a css file in to use,  but it puts  the styles inbetween the head tags, which again is not great for email  clients. So instead we wrote a custom component to insert it the styles  from the css to inline (there are lots of libraries to convert css to  inline, sorry wouldn't be able to tell you which).

The  issue at this point was to know where to put the styles. Thats where the  ids come in and why we used tables to structure the form. We were able  to style the different parts of the form by placing them in the tags,  matching them up with the appropriate id's. We used a config file to map  the styles to the id's to try and automate and reuse as much as  possible.

Not as elegant as i would like, but unfortunately the only way that i could think of to resolve the issue.