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:carlos.ar...@gmail.com] Sent: Wednesday, March 03, 2010 11:29 AM To: Remko Tronçon Cc: docbook-apps@lists.oasis-open.org 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 <re...@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