I can’t find such a package on hex. Can you please elaborate which package you are using?

elixir-pdf-generator
https://github.com/gutschilla/elixir-pdf-generator

I’ve only skimmed the package and its dependencies.

My suggestions:

If your src-attributes contain relative or absolute pathes to the pictures you will probably need to save them on appropriate places relative to the workingdir of wkhtmltopdf, but I can’t tell you were that will be.

Another possibility might be to use fully qualified src-pathes, including schema and host. Then wkhtml should do HTTP(S) requests to your server and fetch files as necessary. But these are blind guesses, I do not use that library (or any PDF generator as well).

Also please take a look at gutschilla/elixir-pdf-generator#19 and gutschilla/elixir-pdf-generator#20, both could give some lights on this, even though 20 seems to be still untouched after 8 months…

I use inline images - using data urls that are the base 64 image data. See data URI scheme - Wikipedia if you are not familiar with them.
It avoids having the images served from somewhere and network latency when you invoke wkhtmltopdf. Just use an onlooker be resource to convert an image to base 64 as a data url. And then insert that into the html content (as in paste into your source content).

But inline images aren’t supported by all browsers, also they blow up the transfer size of your HTML because the innefficiencies of the transfer encoding (usually Base64 encoded or worse…

True, but since the question is about generating pdfs and you mentioned wkhtmltopdf I figured it is a pdf that is being provisioned to end users (browsers), so provided the data urls work on the host environment when generating the pdf using wkhtmltopdf then it should be fine.

So you meant to do inline encoding when preparing for wk but serve regularly when responding to requests? That could work but also would increase complexity of the views.

If preparing for wkhtmltopdf, yes. Normal requests, well no not normally as you bypass the usual methods of optimising the delivery of static assets, and run the risk ( though minimally these days) of the browser not rendering, and yes make more work for yourself by requiring two implementations. I understood the question to be about the purposes of PDF generation only. Forgive me if that’s not the case. I’m still a relatively newcomer to this forum in terms of posting and really appreciate the resource it is along with folk like yourself.

I understand this a service that is able to either deliver HTML or PDF, depending on what the client asks for.

But to be honest… If it is just wkhtmltopdf, point your clients to their browsers “save as pdf” feature… Works much better for most clients and does not produce any load at the server

Browser print cannot be sent via email.