Re: Docs failing to build

Hi David,

David Nebauer <[email protected]>:
> libavalon-framework-java: 4.2.0-3
> libbsf-java: 1:2.3.0+cvs20050308a-1
> libbatik-java: 1.6-2
> liblogkit-java: 1.2.2-8
> libxalan2-java: 2.6.0-6
> libxerces2-java: 2.6.2-4
> libxml2: 2.6.26.dfsg-3
> libxslt1.1: 1.1.17-3
> fop: 1:0.20.5-8
> docbook-xsl: 1.70.1.dfsg.1-0.2
> xml-core: 0.09-0.1
>
> I'm running very recent Debian/testing with all packages up-to-date.
> Let me know if you want any other package versions.

What is the version of your xsltproc package? I remember that Debian packages
the binaries separately from the libraries. FWIW the FreeBSD port is also built
from the libxslt 1.1.17 sources.

> I have discovered the cause of the problem... but am no closer to
> understanding it.  It has to do with the /doc directory's xsltproc line.
>
> The makefile ends up executing the following command (excepting the
> backslash, of course):
>
>     xsltproc -o refdb-manual.fo --nonet --xinclude \
>     ../doc/include/manual-fo.xsl ../doc/refdb-manual.xml
>
> The FO file thus created will fail on conversion to PDF with fop.  If,
> in the xsltproc command, you strip out both instances of '../doc/' you
> end up with the following command:
>
>     xsltproc -o refdb-manual.fo --nonet --xinclude \
>     include/manual-fo.xsl refdb-manual.xml
>
> The FO file thus created is different to the one created using the
> previous command.  This FO file will be converted successfully by fop to
> PDF.
>

This is really interesting. The "../doc" path component results from the
expansion of $(top_srcdir) which is supposed to allow building RefDB outside of
the source directory. I haven't tried lately whether this works for the docs (it
used to work for the binaries). I also don't know how important this feature is
for end users and for package builders. It is quite possible that xsltproc is
not supposed to be used in this context. But then I don't understand why things
work ok on FreeBSD. As a short-term fix I could disable this feature at least
for the doc subdirectory.

OTOH if this is an xsltproc problem, you should create a simple testcase and
post it to the XML mailing list ([email protected]). Do you have any other xslt
processor installed to run a quick test?

> The FO files thus generated are different.  I do not yet understand why
> xsltproc generates different output from the same input and essentially
> similar commands.
>

One reason may be the internal path handling of xslt processors. The RefDB
manual is processed by a driver file for the DocBook stylesheets. The path is
passed as an argument and should arrive ok. But the driver file xsl:includes
another stylesheet (fotitlepages.xsl) with the titlepage customizations. This
path is specified as a relative path in manual-fo.xsl. I actually suspect that
xsltproc does not properly include this file as the failed output that you
posted contains the code to render the revision history, something that I
switched off in my titlepage customization. A comparison with other xslt
processors could show whether xsltproc is broken or whether I expected too much
from it.

regards,
Markus

-- 
Markus Hoenicka
[email protected]
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642