Pdf Generation with PdfGenerator

How do i generate a pdf with the elixir-pdf-generator library with a view and a template. Currently I use the view’s render function to get a string which i generate the pdf from but this fails to find the images and css files.

1 Like

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

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…

1 Like

I use inline images - using data urls that are the base 64 image data. See https://en.m.wikipedia.org/wiki/Data_URI_scheme 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 :wink:

Browser print cannot be sent via email.

Why not? My MUA can handle attachements very well. I can send and I can receive them.

I meant if you application does need to send things via email you’re most often expected to attach it as pdf instead of sending some link / (make the user log in) / tell the user to use the browsers print functionality. And no matter what – HTML templating is the most flexible (not vendored in) when it comes to pdf generation regardless if that html will be accessable within the web application itself or not.

Also I might add I’ve ditched wkhtmltopdf for weasyprint, which in my case did not mess up the css sizing.

Yeah, you may be right on this, but I didn’t see such a requirement on the OPs post.