[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Writing stylesheets for Web and PDF output?

Subject: Re: [xsl] Writing stylesheets for Web and PDF output?
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 26 May 2012 15:37:08 -0400

At 2012-05-26 12:16 -0700, Dan Vint wrote:
I have a situation where I need to write stylesheets that will be used to produce HTML output as well as generate FO to create PDF documents.

I'm wondering if anyone has come up with techniques that allow you to easily manage the commonality between these environments while allowing the generation of the unique requirements in formatting for each?

Things are pretty easy to deal with when one element in the source maps to an output structure in either FO or HTML. Where is gets difficult to manage is when you do some special processing to the content that is then wrapped with the output requirements. Now I want to share that processing and make sure it stays in synch between the two formats.

So beyond the following, is there anything else to help make this process manageable?

1) Create a stylesheet for HTML output.
2) Create a stylesheet for PDF/FO output.
3) Create the special content processing in a 3rd stylesheet in such a way that it can be included in the other two. Basically write these templates like they are functions that return a single value to be wrapped.

I try to do (3) rather than (1) *and* (2).

But depending on your need for fidelity between the two, and how fancy your HTML output is, you can consider the following additional technique. I've used this in a number of projects, including two where the client wanted 3 outputs: PDF, HTML and text equivalents for their XML information. But where the PDF was the "master" and had all of the bells and whistles, the HTML output needed the identical content and same basic functionality but was more utilitarian in presentation and didn't need to be fancy. The text output was for a command-line environment where the client's client could simply pull in the documentation into a text editor for viewing and the paragraphs were blank-line separated.

4) Create the master stylesheet for PDF/XSL-FO output and then a stylesheet to go from the output XSL-FO to output HTML and another stylesheet to go from the output XSL-FO to output text. There is a stock stylesheet for this from our friends at RenderX:


To add some display nuances to the HTML, write a wrapper stylesheet around the stock XSL-FO to HTML stylesheet that is geared to recognize signals you embed in the XSL-FO using attributes in your own namespace. XSL-FO engines are tolerant of constructs in foreign namespaces. So where I needed embellishing that wasn't available in the stock stylesheet, I would add custom attributes to the XSL-FO and my wrapper stylesheet would augment the stock stylesheet with my custom presentation requirements.

You can read a case study on this approach here (for PDF/HTML, not PDF/HTML/text though the principle is the same):


Hand on heart I could assure the client of the fidelity between the PDF content and the HTML content, because the XML source went through only one transformation to produce the XSL-FO ... the HTML was simply a reflection of the XSL-FO without any content-specifics in the transformation. It "guaranteed" the original content would be the same in both renderings. This was important to the client who was publishing US intelligence documents written in XML to both PDF and HTML. And the HTML did not have to be fancy, just accurate (as you can imagine).

Interestingly, the incumbent consulting company was taking the silo approach, not only with separate XSL-FO and HTML stylesheets for any one of the client's clients, but a separate pair of stylesheets for each of the client's clients. I supplanted the incumbent with a comprehensive approach that was structurally assuring the client of fidelity between renderings and between clients. By using <xsl:import> and creating the core stylesheet library described in the paper, I replaced *all* of the renderings with a single library and then used onion-skin-thin importing stylesheets to add nuanced differences for each of the client's clients.

For the client where I went from XSL-FO to text, I embedded my own signals in the output <fo:block> constructs using my own namespace in order to distinguish a block being used for a title from a block being used for content. The creation of a flat text file was incredibly easy.

Not many people take advantage of annotating an XSL-FO file to do other things. I do it often for clients, and I have a couple research projects in my free developer resources where I've annotated XSL-FO files in order to synthesize XSLT stylesheets that create them from XML.

I hope this helps.

. . . . . . . . . . . Ken

Public XSLT, XSL-FO, UBL and code list classes in Europe -- Oct 2012
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal

Current Thread