OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [docbook-apps] Compile xsl with xalan

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

From: Carlos Araya [mailto:carlos.araya@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 <remko@el-tramo.be>

> 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

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]