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:
http://www.renderx.com/Tests/fo2html/fo2html.xsl
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):
http://www.CraneSoftwrights.com/links/ipepaper.htm
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