I just looked at briefly at the sample ant script in Dave's setup guide. I
don't know if he discusses it elsewhere, but I'd recommend using Ant's xslt
task instead of the java task to invoke the xslt processor. The big advantage
the xslt task has is that you can use the "if" and "unless" attributes to
control whether certain params are passed in. For example:
<param name="base.dir" expression="${base.dir}" if="base.dir"/>
Means that the base.dir param is passed in with the value of the base.dir
property if the base.dir property is set. To my knowledge there's no convenient
way to do that if you use the java or exec tasks to invoke your processor.
See http://ant.apache.org/manual/CoreTasks/style.html
David
________________________________
From: Carlos Araya [mailto:[email protected]]
Sent: Wednesday, March 03, 2010 11:29 AM
To: Remko Tronçon
Cc: [email protected]
Subject: Re: [docbook-apps] Compile xsl with xalan
I guess it's up to the individual.
Ant is the answer to your comment about using batch/shell scripts. It
is written in Java so it's portable and can be built so classpaths are not
necessary; they are built by Ant as part of the build process. There's still a
learning curve but it's less steep than having to learn both shell and batch
file syntaxes. There are also ways to incorporate non-Java based tools to a
system like Ant to be run alongside Java programs like xmllint, and fop. This
is how I run xsltproc in my Java toolchain.
Perhaps Dave Pawson's setup guide (http://dpawson.co.uk/docbook/setup/)
is a good starting point for people wanting to build/explore the different
options. It still requires a learning curve but hopefully it's less steep than
having to learn it from scratch. It can be further extended with examples of
how can you incorporate non-Java tools into the tool-chain.
2010/3/3 Remko Tronçon <[email protected]>
Hi,
> There are 2 steps to producing PDF from Docbook XML.
Right, and that's what I've been doing for years. However, my
point
was that, although I didn't measure it yet, I expect a lot of
the lost
time in processing to be due to the overhead of starting a java
VM. If
I'm going to start the VM anyway, the time lost by using a
complete
java-based toolchain is probably a lot smaller. It also removes
some
overhead by only parsing your document once, and taking it
through the
whole conversion chain without re-parsing (although parsing is
quite
fast).
Another aspect is the usability: using a toolchain based on
command-line tools like xsltproc etc. may be acceptable for the
people
who know their way around shells, make, ..., but it's not for
'normal'
people. Building an integrated toolchain based on shell tools
in a
maintainable way is pretty hard on operating systems like
Windows.
That's where the Java tools come in handy: you can easily build
one
usable, cross-platform toolchain. I think that outweighs the
performance hit for most people.
Now, if there would be a good native FO to PDF alternative,
this story
would change: you could build a complete native toolchain by
linking
against these other processors.
cheers,
Remko
