[Leoko]

I had to deal a lot with PDF generation over the past few years and I was very unhappy with the eco-system that was available:

1. HTML-to-PDF: The web has a great layout system that works well for dynamic content. So using that seems like a good idea. BUT it is not very efficient as a lot of these libraries simply spin up a headless browser or deal with virtual doms.

2. PDF Libraries (like jsPDF): They mostly just have methods like ".text(x, y, string) which is an absolute pain to work with when building dynamic content or creating complex layouts.

This was such a pain point in various projects I worked on that I built my own library that has a component system to build dynamic layouts (like tables over multiple pages) and then computes that down to simple jsPDF commands. Giving you the best of both worlds.

Hope this makes somebody's life a bit easier: https://github.com/DevLeoko/painless-pdf

[chrisfinazzo]

Is there a reason you didn't consider something like Weasyprint?

https://weasyprint.org

Going all the way down to raw HTML is a bit verbose, but with almost anything I've thrown at it - CV's, business cards, you name it - it hasn't let me down yet.

[epgui]

I just considered weasyprint and couldn't figure out where to put my credit card or where to go to get started or to see some docs, so that was a very short-lived consideration.

[chrisfinazzo]

At least for my uses, it's entirely free.

I think you can pay for more complicated services, but I didn't need to go that far. It was more about generating a PDF from HTML without manually invoking File > Save as PDF each time.

Tl;dr I'm lazy ¯\_(ツ)_/¯

Installed w/ Homebrew, it's really nothing more than running `weasyprint input.html output.pdf`

https://doc.courtbouillon.org/weasyprint/stable/first_steps....

[epgui]

I didn't even realize that, because I couldn't find a link to any docs on the website. It looked like a dead end... ¯\_(ツ)_/¯

[Crowberry]

I'm with you..

We ended up writing a similar wrapper around https://github.com/jung-kurt/gofpdf library. We haven't open sourced it yet. But it's made it a lot easier to deal with rendering a PDF, especially over pagebreaks ect.

[aforwardslash]

A while ago I created a pdf report generation engine for Python, supporting Jinja2 template syntax, and server and client-side generation of content. Page formatting is handled by https://pagedjs.org/, and PDF generation is performed via a separate api daemon based on chrome-headless: https://zipreport.github.io/zipreport/ It is not fast, but it works quite well.

[Leoko]

Yes, page breaks are probably the most significant difference between the layout of a web page and a PDF document, and thereby a major drawback when using HTML-to-PDF. There is little to no tooling for this in the web.

If you want granular control over how your PDF will look with content that is more than one page long, you will have a hard time using html.

[Titou325]

We actually provide helpers to do that in our React library https://react.onedoclabs.com/components/shell#pagebreak

CSS actually implements the break-before property to control this https://developer.mozilla.org/en-US/docs/Web/CSS/break-befor... which is also supported by the Print to PDF dialog in modern browsers.

[pedro120]

That's what we are trying to solve at Onedoc, we want developers to be able to have full control over the PDF layout as they write content. react-print is built with the intention of creating the illusion that React was meant for PDFs.