PDF download not working

[gioxc88]

I am trying to download PDF but the web page becomes greyed out and unresponsive with the spinning wheels that keeps spinning

[pplonski]

Hi @gioxc88,

Thanks for reporting the issue. Do you have static notebook (looks like it is)? Are you running Mercury locally? What operating system are you using?

Have you installed Chromium? It can be done with command:

pyppeteer-install

[gioxc88]

Yes:

• static notebook
• locally
• windows 11

when I do pyppeteer-install it says that chromium is already installed

[pplonski]

Looks like a bug. Is it very urgent for you? What is your use case for Mercury?

[gioxc88]

I am using it to export pdfs at the moment but I am planning to use it as my main tool for web apps. If this doesn't work will have to find another solution to export in pdf

[gioxc88]

I have just made the notebook non static, the PDF export works, but the plotly charts are not rendered in the PDF. Any advice?

Thanks Gio

[pplonski]

Might be some issue with plotly. There is different mechanism for PDF export for static and dynamic notebook. Please create new issue for plotly rendering to PDF.

[RoyOltmans]

Hi Pplonski and Gio,

Thank you for all the hard work, great solution!

I am getting similar issues as Gio with a headless fedora server running mercury locally.

Context (beforehand) I first had to resolve some pyppeteer issues on fedora, was getting pyppeteer.errors.BrowserError: Browser closed unexpectedly.

I added the chromium-headless installer, pip chromium-installer, pyppeteer-installer. The chromium version installed via pyppeteer on fedora is not that stable, the local chromium executable in ~/.local of pyppeteer needs to be replaced with the version of the headless install of chromium /usr/lib64/chromium-browser (change the executable chrome by copying everything from the folder /usr/lib64/chromium-browser/ to the pyppeteer folder and rename the chrome executable with the version coming from lib64). This issue has basically nothing to do with mercury, but could be helpful for other users... Be aware and be careful with these actions. I solved the above issue as described.

Issue I have the same response for a simple notebook from a simple overview in jupyiter. At the moment I run the version of mercury provided via DNF on a headless fedora server python 3.11

I found the following, when running the /api/v1/export_pdf/ HTTP POST call is executed the PDF is ASYNC apps.tasks.tasks_export.export_to_pdf is received and generated. The HTTP GET /api/v1/get_pdf/ does not provide the binary stream back to the browser. The HTTP GET request (200) is in a loop as Gio described in the browser, even after manually approaching the GET the file is not provided. The pdf can still be opened manually (after or during the loop) via [host]/media/[notebook name].pdf meaning content wise there is no problem only the binary push isn't executed.

Question/Problem Bug I am not sure why the pdf file is not provided after that its generated, hope you can shed more light on this part. Somehow the chromium issues (see context) looks like tied in to the binary file stream handling. Some suggestions point to forcing to disable proxy support on the environment of the server (export no_proxy or similar)). I don't use a proxy and tried to configure this in the environment with no avail.

Thank you for all the trouble!

[pplonski]

Thanks @RoyOltmans for describing the issue. I understand that PDF is created on the server, but it is not send to the frontend.