[changing the cc from -doc to -sgml, as that is more appropriate.] On Thu, Mar 06, 2003 at 07:00:46PM +0100, Aaron Isotton wrote: > Hi, hello. > Currently (and since I've started using it) the DocBook XSL toolchain in > Sid is somehow broken for most transformations except XML -> HTML. i would have to disagree. there is only one transformation problem that i know of (see below). > - 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). for this to work, the docbook xsl stylesheet would have to somehow read and interpret /etc/papersize. at this point, i dont know of any facilities to do this. therefore i came to the conclusion that the burden of support libpaper was in the applications using the docbook xsl, rather than in the stylesheet itself. you can set the page size by using this style sheet (and the appropriate substitutions): <?xml version='1.0'?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; version='1.0'> <xsl:param name="page.height">$paperheight</xsl:param> <xsl:param name="page.width">$paperwidth</xsl:param> <xsl:import href="$stylesheet"> </xsl:stylesheet> > - 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. the only docbook construct know to cause problems is the <itemizedlist> tag, and fabien is working on this. > Now to xmlto. xmlto (should) automate this entire process by calling > the appropriate helpers, it does this. > deleting temp files etc. what temporary files does it leave around? > It uses a hack to respect /etc/papersize, if you have a better solution i would like to hear about it. i implemented what i thought was best. it works. > but entities like — or even more important ones such as ä > do not work. no bug reports have been filed. how do you expect me to fix these problems? > 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. it is a two step process: xsltproc is called to transform (using docbook-xsl) the input xml file to xsl-fo. passivetex interprets the xsl fo (using xmltex to process the xml) and transforms it to dvi/ps/pdf. > Nobody really seems to know where the errors originate, they come from the <itemizedlist> tag. > and the maintainers seem keeen to reassign and close reported bugs > just because it worked on their machine with some sample document. the bugs remain open. see #181444. > Many of these problems do not appear with small samples, and it is thus > difficult to track them down. yes it is difficult, but i think we have finally done it. > I'd very much appreciate if somebody with more knowledge of xslt and tex > than I have could look into the problem; it is being looked into; i dont know what makes you think that it is not. > 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. i test with bogofilter's man page and documents i receive in bug reports. in fact, README.test in the debian/ directory of xmlto invites people to send me test documents. i have been testing with the file you sent me while working on your bug reports, and i am adding that file to the test code of xmlto right now. -- gram
Attachment:
pgphJXBqEGOH0.pgp
Description: PGP signature