webpdf's use of /tmp breaks markdown images

[ryanlovett]

If a user specificies a relative path to an image, e.g. ![myimage](images/myimage.png), the image display correctly in the jupyter app, but does not get embedded in the PDF after conversion from webpdf. If the user specifies an absolute path to the image, it does not display correctly in the jupyterap, but does get embedded in the PDF.

I suspect this is because the webpdf conversion writes out a temporary html file to /tmp/. The HTML files looks for relative paths there rather than the user's currect working directly. When I manually images to /tmp (e.g. /tmp/images/myimage.png), with my notebook in /home/jovyan and using a relative markdown path of images/myimage.png, the image is embedded in the PDF properly.

[tuncbkose]

If the user specifies an absolute path to the image, it does not display correctly in the jupyterap

This seems to be intended behavior, jupyterlab/jupyterlab#6835.

I agree that the rest should be fixed. I don't know what would be a good approach for a fix, but a possible workaround is using WebPDF.embed_images=True.

[normanius]

This is still an issue, unfortunately.

For context, this is output generated with.

jupyter nbconverter --to pdfviahtml path/to/notebook.ipynb

I generally like the output that is achieved this way (math typesetting look great, svg graphics are displayed nicely). Also, I like the custom-format, single-page PDF since too many page-breaks break readability IMHO.

However, the fact that images are excluded in Markdown cells makes it unusable for me.

[JPFrancoia]

Yes, same problem here. The solution give here kinda works: #1079 (comment) and I'm able to get images in the pdf generated with pdfviahtml. But it's a bit hackish and the code used to display the image is visible in the output

[soilstack]

This kind of kills using nbonvert to make pdfs .... Suprised it's not been fixed somehow.