Now that v5.x is stable, I was looking to use that (rather than v4.x).
However, PDF generation is a blocker for me. It seems that the local install of PhantomJS is no longer supported. Considering that is abandomware, in isolation that seems rather wise. However, that means that the only options now are using the online, 3rd party PhantomJS service, or installing Chrome and all it’s dependencies…
Neither of these options is currently acceptable in my scenario.
Re the PhantomJS service, the requirement for a public facing server is a problem. Plus (even if that weren’t an issue) sending sensitive documents that includes a lot of identifying info (not just mine, but other’s too) to a remote service that I have no way of auditing doesn’t seem like a good business decision. I’m not questioning their trustworthiness, but I don’t know anything about them and don’t want to have to trust them.
Re the headless Chrome approach, in theory, that is much more acceptable. But when I looked at installing it (Debian stable) it pulls in a TON of dependencies (~500MB installed)! Requiring an extra 1/2 GB to just generate PDFs seems ridiculous.
I may go the Chrome install direction if I have no other way forward (and probably see if I can trim the deps down a bit). But surely there is a better option for (local) PDF creation?!
E.g. a quick google turned up WeasyPrint - a cross platform (i.e. Windows/Mac/Linux) tool to “print” html to PDF. It’s packaged in Debian stable backports and will be in Bullseye. It does still pull in 90MB, but vs ~500MB that’s not too bad…
Even if Invoice Ninja doesn’t have plans to support that (or some other lighter weight local alternative), if the calls to Chrome are documented somewhere (or at least point to the relevant code) then perhaps I could look at writing a wrapper for WeasyPrint? (That translates the calls to headless chrome to WeasyPrint). If I go that direction, would that be of interest to the Invoice Ninja devs?
This sounds really nice, however, we use latest standards for PDF designs. Are grid and relative values/units supported? That’s breaking change for us.
@david - Thanks for the warm encouragement. Your enthusiasm and encouragement is appreciated!
@ben - Unfortunately, I’m more of a Linux system admin (bash/python) sort of guy, and am not completely up with PDF/HTML/CSS formatting standards/capabilities (most of my life is spent on the CLI…). As such I’m not completely clear on exactly what you even mean by “grid and relative values/units” (I’m guessing you mean like responsive layout?). Also, FYI I’m not at all familiar with WeasyPrint, other than that on face value, it looks like it might do the trick.
Regardless, my reading of the WeasyPrint docs suggests that there is fairly extensive (albeit incomplete) support for HTML and CSS standards and formatting features. So it seems likely to me, but without being aware of the specifics of your concern, I can’t really comment further.
It would be awesome if you guys could provide some guidance on how to generate a particularly complex InvoiceNinja PDF (i.e. one that requires the PDF generation capabilities you are most concerned about). If you have any automated PDF generation tests already in your development workflow, that would be useful to be aware of too.
If I can set up a fresh v5.x InvoiceNinja instance with some data known to test PDF generation to it’s limits, then I can compare PDFs generated by each of the 2 current options (PhantomJS online & headless chrome) and a wrapped WeazyPrint. At least initially, I was thinking of setting EXPERIMENTAL_PDF_ENGINE=true & EXPERIMENTAL_PDF_ENGINE_CHROMIUM_PATH=/path/to/my/weasyprint-wrapper. That should give us an idea if this particular path is worth perusing further.
If we use some existing example data (loaded into a fresh clean install of latest stable v5.x) for that would be ideal. Then the relevant PDFs would be reproducible (hopefully!) and could be publicly shared for comparison.
FYI, it appears that the wkhtmltopdf project had some updates in 2020 (previous updates not since 2018). I’ve used that myself before and works great with relatively simple PDFs. That is smaller again than WeasyPrint and leverages (Qt) webkit, but can be a bit hit and miss with more complex layouts in my past experience. I actually thought it was abandonware, but it seems perhaps not…?! Could be useful to put in the mix too (i.e. a 4th possible option)?
If there are any other (Linux and/or cross platform) PDF generation projects that might also be useful to consider, please don’t hesitate to share. Once I have a clear path to set up a “Invoice Ninja dev PDF generation” instance, then we can gather some more info…
As has possibly been guessed, life has got in the way of my plans to check this out. Hopefully I will circle back to this sometime soon, but my timeline has (obviously) blown out and it’s not clear when I’ll get a chance to follow up…
