Your example is similar to what I have. This is DoD work where the
customer wants the IETM as a primary deliverable, but wants PDF/paper
for in process reviews (and sometimes will request us to make an
actual Mil-Spec manual).
I have at least 3 environments that I need to keep consistent.
1) Arbortext editing environment
2) IETM output as HTML
3) 3rd party application that merges the data modules together into
one XML file that is then processed to make the PDF. Originally
designed to be a mil-spec manual output but typically now just used
for review copies where the requirement is to make it more like the
IETM output.
So there are 3 sets of stylesheets that were developed at different
times by different parties. These have existed for several years now
and I'm trying to refactor them and hopefully make them easier to
maintain. There has been a lot of cruft accumulated in these
stylesheets due to conflicting purposes and changes in direction that
any project encounters.
Your idea of processing one output into another was an approach I
hadn't thought of. I'm not sure I can make it work here with our
current tools and workflow, but it might be something to consider -
that is changing the workflow to make this approach work.
FYI, this is S1000D content where everything is written in topic
based data modules. So there are lots of individual files that have
to be combined. The PDF generating tool has the functionality that
brings these all together.
..dan
At 12:37 PM 5/26/2012, G. Ken Holman wrote:
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(_at_)CraneSoftwrights(_dot_)com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
---------------------------------------------------------------------------
Danny Vint
Panoramic Photography
http://www.dvint.com
voice: 619-938-3610
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--