Description of problem: xmltex is generated with a very small memory limit, which causes it to fail when converting a simple 16-page document to PS using xmlto. The need to increase memory size is also described at http://www.hcu.ox.ac.uk/TEI/Software/passivetex/ (note that it can be done for {pdf,}xmltex only, without changing the configuration of other TeX formats). I have easily overflowed the save_size limit, which makes xmlto unusable. How reproducible: Always Steps to Reproduce: 1.Create a reasonably-sized docbook document (I can provide one upon request, if it doesn't show in Bugzilla) 2.xmlto ps foo.docbook Actual Results: Processing aborts with TeX capacity exceeded, sorry [save_size=10000] (typing from memory, may be a bit different) Additional info: Compared to docbook-utils and DSSSL stylesheets, xmlto is horribly slow (3 minutes vs. 13 seconds), but this is probably what you deserve for parsing XML in TeX.
All of the parameters mentioned on that web page are set to the recommended values or, in one case, higher. Which parameter would you increase, and to what value? As to the speed: I have found virtually no difference in speed when using DSSSL compared to XSL---the Selfdocbook, for example (http://cyberelk.net/tim/docbook/), takes about 47s for either method. I would guess, though, that the speed difference you are seeing is due to your document having no cross-references, and so needing only one pass. I'll look at making xmlto do the right thing for that case when you attach your document (or a pointer to it).
Tim, thanks for your fast reply. I'm sending the document to twaugh (subject [RHL BUG 64752] Sample XML document). You can show it to whoever you like (it's in Czech anyway;-), but I'd rather not post it to a public place like Bugzilla. As for the cross references, you're wrong at least in the case of this document. OTOH the markup/content ratio is quite high - about half of the document is <procedure><step>....
Gosh, it really is slow on that document! Increasing save_size to 15000 seems to fix it for me, and this is also that value that hugelatex uses.
(Changing component to tetex, since this is where the value actually gets set.)
Fixed in 1.0.7-48.