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 >
