This is the mail archive of the
mailing list .
[docbook-apps] Multi-part document, multiple stylesheets
- From: Larry Garfield <larry at garfieldtech dot com>
- To: docbook-apps at lists dot oasis-open dot org
- Date: Sun, 27 Mar 2005 05:25:15 -0600
- Subject: [docbook-apps] Multi-part document, multiple stylesheets
First off, thank yo to Bob and Michael. I've since switched over to
Saxon, XIncluder, and Ant and most of the technological issues seem to
have finally been taken care of. (And yes, I am using Debian. Good
eye. I take it you are too. <g>)
However, I'm now running into a design problem that I'd also appreciate
some help on.
I have/will be building a <set> of books, probably around 5 although at
the moment I just have one marked up for testing. The source is in a
series of XML files across a few directories, brought together via
XIncludes. (set.xml is mostly xi:include directives to various books,
each of which is mostly xi:include directives to various chapters/articles.)
Although all are similar, the outputs for each (HTML and PDF, just
dealing with HTML for now) will be just different enough that I need to
use separate customization XSL files for them. (Different CSS links,
for instance.) OK, fine, run each one separately via Ant. Except that
I also want to generate an index/cover page for the whole set. That
requires running the scripts against the top set.xml file. Of course,
that also then generates files for the rest of the tree, which will not
have the right customizations set.
In addition, I'm using XIncluder as a preprocessor to generate a single,
complete document before passing that to the rest of the targets. I
originally was using Xerces directly in the Saxon command, but the
version of Xerces I have still has the bug in its XInclude URI string
(2001 vs. 2003). Being a nitpicky purist I didn't want to go through
and put "wrong" namespaces in all of my documents, but I'm not sure how
to link XIncluder in directly. That means that in order to run each
book separately, I'd have to run XIncluder on a portion of the source
tree first for each one. Since neither XIncluder nor Saxon is
particularly speedy, that results in a very slow, very ugly build
process. I don't even want to contemplate how messy it would get once I
added FO/PDF output as well.
So the best I can come up with right now for the build process is
- XIncluder to resolve whole set.
- Saxon on whole set to generate set's index.html.
- XIncluder to resolve book A.
- XIncluder to resolve book B.
- XIncluder to resolve book C.
- Saxon on book A temp file, overwrite what set generated.
- Saxon on book B temp file, overwrite what set generated.
- Saxon on book C temp file, overwrite what set generated.
My mind is screaming at me that there has got to be a better, cleaner,
less ugly way than that. Can anyone point me in the direction of what
that would be? Many thanks.
Larry Garfield AIM: LOLG42
email@example.com ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps it
to himself; but the moment it is divulged, it forces itself into the
possession of every one, and the receiver cannot dispossess himself of
it." -- Thomas Jefferson