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

 

David

  

  
  From: Carlos Araya 
  [mailto:] 
Sent: Wednesday, March 03, 2010 
  11:29 AM
To: Remko Tron蔞n
Cc: 
  
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蔞n <>

  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