TeamSite DCR To xsl:fo To PDF

I am currently experimenting with generating PDF's from TeamSite content using xsl:fo.

One thing that is hanging up the effort is dealing with content entered into a WISIWYG field. We have a STRUCTURED authoring experience but for "in sentence" links and minor formatting we do make use of TinyMCE.

Two things happen that do not lend themselves to xsl:fo conversion.

1). ® becomes ® which on the resulting PDF displays as ® instead of ®

2). TinyMCE is a web rich text editor so text marked up with html looks like this.
<b>bold</> which on the resulting PDF displays as <b>bold</b>

For structured data the XML -> xsl:fo --> PDF is pretty straight forward but the processing of the TinyMCE fields leaves me with many open questions / possible solutions.

Has any one had experience handling / pre-post processing these types of fields to generate documents using xsl:fo?

Find more posts tagged with

Comments

Tim__D

At the end of the day the solution to this for me in my run-time environment (custom application not LS) was as follows.

Important Facts:
* TinyMCE does create valid XHTML when configured.
* XSL transformations when asked will result in converting entities to utf-8 characters when configured (disable output escaping)

Solution:
My solution was to create a XSL pre-processor transformation prior to the final XSL transformation. This essentially converts the escaped XHTML saved by TeamSite FormsPublisher into un-escaped XHTML/XML.

Then the final XSL transformation is able to define xsl:template for elements like strong, table, list, etc.. and properly render the xsl:fo equivalent.

Cons of this approach include among probably many any fields which users hack in html. A simple br not br/ and it breaks. There is probably more but I implemented this a while ago and cant recall everything. & characters and knowing if they were an entity or not I remember causing problems.

Anyway I wanted to follow up on my solution for the greater good. I'm done with this thread but will leave open in case others want to contribute other perspectives.

Cheers - Tim

Rick Poulin

Cons of this approach include among probably many any fields which users hack in html. A simple br not br/ and it breaks. There is probably more but I implemented this a while ago and cant recall everything. & characters and knowing if they were an entity or not I remember causing problems.

Could this not be rectified by filtering the output through an html tidy? JTidy, for example, is an open source Java library that will liberally parse HTML and give you back a w3c Document object.