With the older PDF export process, it was possible to got to a direct URL and the response would be the exported PDF content. Is that possible with the new client-side export?
Given that it’s a two-step process, I’m guessing that’s not possible OOB, but before looking for custom-rolled solutions, I wanted to check and see if I missed something.
-Lane
In the new PDF export the PDF is generated by a web browser. This can be your own web browser or a (remote) web browser running on the sever-side (e.g. in a Docker container). You can configure this in the dedicated administration section. When using your own web browser you can’t have a direct link to the generated PDF because you can’t bypass the print preview modal. When using a remote web browser it’s possible to obtain a direct link but there’s a catch. The process of generating the PDF is asynchronous: rendering each of the selected wiki pages, aggregating the output, calling the remote web browser (HTTP) happens in a low-priority background (daemon) thread. In order to get a direct URL that triggers the PDF export and also returns the PDF output you need to make the request blocking (i.e. wait until the background thread finishes the PDF generation). This could be acceptable when exporting a single wiki page, but for multi-page export it can cause problems:
- it blocks a request thread and if multiple users do this at the same time then your site will become unresponsive
- if the export takes too long the browser may time out
In any case, if you want to do this you can follow https://extensions.xwiki.org/xwiki/bin/view/Extension/PDF%20Export%20Application/#HScriptService . The important part is:
#set ($discard = $pdfExportJob.join())
which blocks the request thread until the PDF export thread finishes its work.
Hope this helps,
Marius
Thanks @mflorea, that’s the confirmation we needed! -Lane