Hi,
Currently (and since I've started using it) the DocBook XSL toolchain in
Sid is somehow broken for most transformations except XML -> HTML.
There are several ways to convert from XML to {PDF,DVI} but (at least
for me) none of them works the way I'd wish.
The transformations work as follows:
- XML -> FO using
/usr/share/sgml/docbook/stylesheet/xsl/nwalsh/fo/docbook.xsl. This part
works fine, BUT it doesn't respect /etc/papersize. xmlto has a hack in
it to do that, but other problems (follow).
- FO -> PDF using libfop-java. Looked ugly and didn't work properly
last time I tried, and depends on a bunch of packages which are *not* in
Debian.
- FO -> PDF using xmltex. This seems to work nicely, except it gives
dozens of warnings of the kind
Font shape `U/msb/m/n' in size <4.04994> not available
(Font) size <5> substituted on input line 208
which seem to have no bad effects, though.
- FO -> DVI using xmltex. One might think that this should work the
same as FO -> PDF, but this is not the case. It works with toy "sample"
documents, but not with longer and more complex ones.
Now to xmlto. xmlto (should) automate this entire process by calling
the appropriate helpers, deleting temp files etc. It uses a hack to
respect /etc/papersize, but entities like — or even more important
ones such as ä do not work. As almost every serious XML documents
contains some entities at some point, it's basically unusable to create
PDF.
The problems - as far as I can see - are the following.
The transformation is very complex; it is distributed onto several
packages: docbook-xsl, xsltproc (or some other xslt processor), xmltex,
passivetex, tetex-bin, and optionally xmlto.
Nobody really seems to know where the errors originate, and the
maintainers seem keeen to reassign and close reported bugs just because
it worked on their machine with some sample document.
Many of these problems do not appear with small samples, and it is thus
difficult to track them down.
I'd very much appreciate if somebody with more knowledge of xslt and tex
than I have could look into the problem; I also think that it would be
much better if the maintainers of the relevant packages would check the
toolchain with some "real" documents (as available from
http://cvs.debian.org/*checkout*/?cvsroot=debian-doc) instead of some
upstream-supplied sample documents.
Aaron Isotton [ http://www.isotton.com ]
--
My GPG public key: 64B3 080D 8D00 15A6 CA56 C8FF 9B61 CF29 F55B 1F2A
There are no rules for March. March is spring, sort of, usually, March
means maybe, but don't bet on it.
Attachment:
signature.asc
Description: This is a digitally signed message part