There is a service in LiveCycle to convert PDF files to HTML, and it the output 
looks pretty decent, but after looking at the html code, we realized that there were a bunch of DIVS and such that were added to the forms. This didn't work out to great as a solution for us, because we planned to place that html into an email, and with all the divs and such it would look horrible (since some email clients don't follow a standard). There were a few options in the service to try and manipulate the CSS and such, but nothing that gave a satisfactory result.
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 when 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 0 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.