On Sun, Nov 26, 2017 at 4:21 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.mu...@enterprisedb.com> writes: >> ... I couldn't help noticing that >> templates with match="chapter" and match="appendix" appear in our tree >> in sgml/stylesheet-speedup-common.xsl with a comment >> "Performance-optimized versions of some upstream templates from >> common/ directory". Could it be that whatever performance-enhancing >> trick they perform doesn't work on 1.1.32, or alternatively they are >> not being reached so we're falling back to non-optimised versions >> instead of these? > > If you're suspicious of that, you could try removing those parts of > stylesheet-speedup-common.xsl and see what happens ...
Good idea. Removing them didn't help (though removing them makes Apple xsltproc similarly slow). Adding "d:" namespace to "chapter" and "appendix", declared in the xsl:stylesheet element as xmlns:d="http://docbook.org/ns/docbook"; didn't help either. I suspect that could be made to work with some more tweaking, but I lack the XSL knowledge. I found another way forward though: On Sun, Nov 26, 2017 at 4:09 AM, Alexander Lakhin <exclus...@gmail.com> wrote: > It seems that your package is built from "ns" version. > (I couldn't find docbook-xsl-nons in Macports.) > If it's the only available version for Mac, it seems we need to adjust our > XSL templates to work with namespaces too. Aha, you're right! MacPorts does actually have two different ports (packages): docbook-xsl and docbook-xsl-ns, and the first one should be the no-namespace variant. But I can clearly see that the docbook-xsl packages installs stylesheets *with* namespaces. I compared this with a Debian system and found that common/labels.xsl (the file that defines the templates that our stylesheet-speedup-common.xsl seems to want to replace) has the "d:" prefix on "chapter" and "appendix", but doesn't on the Debian system. Presumably this interferes with the interposing technique. Perhaps that is a packaging error that should be reported upstream. That got me wondering... why does the Apple xsltproc in /usr/bin work then? Where is it even getting docbook-xsl from? I ran it with --profile and http://docbook.sourceforge.net instead of file:// URLs, and I could see outgoing connections with netstat. It believe that's because it doesn't find it locally in /etc/xml/catalog, whereas the MacPorts xsltproc looks in /opt/locl/etc/xml/catalog where it has been listed by the docbook-xsl package. So one solution is simply to uninstall the docbook-xsl package. That gets me back to fast documentation builds! Incidentally, uninstalling the docbooks-xsl package also works for FreeBSD which currently ships a too-old DocBook version. I believed until now that it couldn't build the PostgreSQL docs, so I'm very happy to discover that it can, but (1) it needs the network (2) it's using HTTP instead of HTTPS so Alice could mess with Bob's documentation. Thanks both for your help figuring this out. That's quite enough XML for one day. -- Thomas Munro http://www.enterprisedb.com
