Generating a custom PDF is just such a pain. You don't know it before you tried to do it. I've seen Anvil (a YC co) is building a product dedicated to this challenge, check it out!
I recall using cups to print to a pdf in the past.
Generating PDF invoices using Lago
51–56 of 56 posts
Re: Generating PDF invoices using Lago
#52Generating a custom PDF is just such a pain. You don't know it before you tried to do it. I've seen Anvil (a YC co) is building a product dedicated to this challenge, check it out!
I just use headless chromium to "print" a generated HTML page as a PDF, works great.
AFAIK uses wkhtmltopdf underneath. Saw a post suggesting Chrome browser developers would prefer not to be offering thin cli support -- presumably for such use cases to use wkhtmltopdf directly.
Re: Generating PDF invoices using Lago
#5312 years ago, I was working on a contract for an aircraft spares supplier. One of the hard requirements: all sales invoices, purchase orders, quotations, invoices, and so on, had to be printed AND available as PDF. The solution was to use JasperReports. The business could design their templates in a iReport Designer, test with dummy data, put the jrxml templates in a dedicated storage, and a simple http call would me…
> The solution was to use JasperReports.
Ran into it in a legacy project a few years ago, it was a total mess.
The way the templates were written wasn't clear in regards to how the fields will be filled out, conditions and scripts for the visibility of certain sections were problematic (no proper linting/syntax checks outside of runtime), there were problems with system fonts, there were problems with selecting data for filling out the templates, there were problems with the template files looking broken in different versions of the GUI software, there were problems with getting like 50 warnings after opening the template and moving any element a few pixels broke the entire template.
If possible, I'll avoid the technology, especially after trying to migrate the project to JDK 11 broke because of incompatibilities of that version of the library. Personally, I think that HTML output that then can be rendered to PDF is the only decent option in this space, which will save you many headaches.
Re: Generating PDF invoices using Lago
#54Earlier quoted context omitted.
> When billing is complex (lots of fees, different billing cycles, usage based consumption) So does Lago have a template for all these use cases? What happens when a new unique case comes up? Is Lago flexible enough to handle all the cases? Current and future ones? How is that different than having a flexible template? What actually is the problem with that?
We make the whole fee calculation easy to do. If you have a paying feature, the charge related to it can be implemented in few minutes. We handle automatically the upgrades, downgrades, invoices, subscription dates and boundaries, and a lot of prebuilt charge model (graduated pricing, percentage pricing, package pricing…). We adapt to any pricing use case easily!
Invoices contain VAT and even more complex taxes and charges. How much of your calculations is tied to specific cases like a USA company billing another USA company? What's your story for international customers and/or international operations?
Re: Generating PDF invoices using Lago
#55Earlier quoted context omitted.
I just use headless chromium to "print" a generated HTML page as a PDF, works great.
AFAIK uses wkhtmltopdf underneath. Saw a post suggesting Chrome browser developers would prefer not to be offering thin cli support -- presumably for such use cases to use wkhtmltopdf directly.
It doesn't, and AFAIK they reversed that decision.
Re: Generating PDF invoices using Lago
#5612 years ago, I was working on a contract for an aircraft spares supplier. One of the hard requirements: all sales invoices, purchase orders, quotations, invoices, and so on, had to be printed AND available as PDF. The solution was to use JasperReports. The business could design their templates in a iReport Designer, test with dummy data, put the jrxml templates in a dedicated storage, and a simple http call would me…
> The solution was to use JasperReports. Ran into it in a legacy project a few years ago, it was a total mess. The way the templates were written wasn't clear in regards to how the fields will be filled out, conditions and scripts for the visibility of certain sections were problematic (no proper linting/syntax checks outside of runtime), there were problems with system fonts, there were problems with selecting data…
I’ve never used Jaspersoft, only seen the marketing pages of recent years on Tibco’s site. But much of that developer experience sounds like my 4-ish years with BIRT: differing versions of the designer GUI in Eclipse breaking things; debugging a report required starting up our entire monolith app.
How much better is SSRS in these aspects than the aforementioned Java-based solutions? Or I guess “paginated reports” in Power BI nowadays.