Re: [docbook-apps] Compile xsl with xalan

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 <remko@el-tramo.be>

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

docbook-apps message