4 ms·

At the moment, the combo of pagedjs with a headless browser is my first recommendation when you need something to output pdf automatically. Weasyprint looks ni

At the moment, the combo of pagedjs with a headless browser is my first recommendation when you need something to output pdf automatically. Weasyprint looks nice, I have yet to use it. It probably has the advantage of not using an actual browser document (with all the relayouting problems), and may use fewer resources in terms of time and memory (I'd have to check though). The disadvantage is also it's not an actual browser document, meaning you need to render the html and css in some form before passing it to weasyprint. Using a headless browser makes it easier in general to do some fancy stuff like music sheets or embed js chart libraries and so on.

yojo 4y ago
> meaning you need to render the html and css in some form before passing it to weasyprint I'm not sure I understand this part. WeasyPrint is a rendering engine; it takes an HTML file as input and outputs a PDF. I can't speak to resource usage, since this was very ad-hoc. For my needs, it was very simple to set up, and worked on the first try. I was testing with about five pages of content, and on my M1 MBP it rendered out the PDF pretty close to instantaneously, which was nice for the edit/refresh cycle. Preview on MacOS actually live reloaded when the PDF changed, which was a pleasant surprise.
- bayesian_horse 4y ago
  With "render" I meant you need to first create the html and css before handing it over to weasyprint. You can't use browser-based chart libraries unless you convert their output to svg or other image formats first. With a headless browser you can use for example react to generate the document, you can just insert any chart library and so on. And regarding resource usage I had scenarios of "pdf as a service" in mind, where you need to generate pdfs dynamically. Reporting, invoices, what have you.
  - yojo 4y ago
    Ah, gotcha. I was focused on my use case of static text. If your charting library runs server-side and outputs HTML/CSS, then it'd work fine, but most of that stuff requires javascript, and yeah, WeasyPrint doesn't have an interpreter. Once you're already paying the overhead of a browser, you're probably better off using a JS polyfill than piping through another tool, unless paged.js is an insane resource hog (which seems unlikely).

yojo 4y ago

> meaning you need to render the html and css in some form before passing it to weasyprint I'm not sure I understand this part. WeasyPrint is a rendering engine; it takes an HTML file as input and outputs a PDF. I can't speak to resource usage, since this was very ad-hoc. For my needs, it was very simple to set up, and worked on the first try. I was testing with about five pages of content, and on my M1 MBP it rendered out the PDF pretty close to instantaneously, which was nice for the edit/refresh cycle. Preview on MacOS actually live reloaded when the PDF changed, which was a pleasant surprise.

bayesian_horse 4y ago
With "render" I meant you need to first create the html and css before handing it over to weasyprint. You can't use browser-based chart libraries unless you convert their output to svg or other image formats first. With a headless browser you can use for example react to generate the document, you can just insert any chart library and so on. And regarding resource usage I had scenarios of "pdf as a service" in mind, where you need to generate pdfs dynamically. Reporting, invoices, what have you.
- yojo 4y ago
  Ah, gotcha. I was focused on my use case of static text. If your charting library runs server-side and outputs HTML/CSS, then it'd work fine, but most of that stuff requires javascript, and yeah, WeasyPrint doesn't have an interpreter. Once you're already paying the overhead of a browser, you're probably better off using a JS polyfill than piping through another tool, unless paged.js is an insane resource hog (which seems unlikely).