Hi, On 2023-03-20 10:32:49 -0700, Andres Freund wrote: > On 2023-03-20 11:58:08 +0100, Peter Eisentraut wrote: > > Oh, this patch set grew quite quickly. ;-) > > Yep :)
Unless somebody sees a reason to wait, I am planning to commit: meson: add install-{quiet, world} targets meson: add install-{docs,doc-html,doc-man} targets meson: make install_test_files more generic, rename to install_files While I don't think we have necessarily the path forward around .css and .svg, the above are independent of that. For the .svg: I wonder if we should just inline the images in the chunked html, just like we do in the single page one. It's not like we reuse one image across a lot of pages, so there's no bandwidth saved from having the images separate... For the .css: docbook-xsl actually has support for writing the .css: [1] - but it requires the .css file be valid xml. I wonder if the cleanest approch would be to have a build step to create .css.xml - then the non-chunked build's generate.css.header would do the right thing. I'll start a new thread for docs: speed up docs build by special-casing the gentext.template VERY WIP: parallel doc generation after the feature freeze. After looking into it a tiny bit more, it seems we should use neither pandoc nor dbtoepub for epub generation. All the dbtoepub does is to invoke the docbook-xsl support for epubs and zip the result - except it doesn't use our stylesheets, so it looks randomly different and doesn't use our speedups. At the very least we should use our customizations, if we want epub support. Or we should just remove it. Pandoc unfortunately doesn't do docbook well enough to be usable for now to directly parse our docbook. Regards, Andres [1] https://docbook.sourceforge.net/release/xsl/current/doc/html/custom.css.source.html