Oh man, .NET needed this. Did some PDF work for a .NET project last year and found the ecosystem to be somewhat light on PDF support. There's a few commercial options, but they're pricey.
its basically a wrapper for wkhtmltopdf but I develop an app that has probably generated a million +/- invoices/statements over the past 5 years with it, and its been rock solid for me. Was a bit of a bear to get it working the first time (not a ton of documentation that I could find at the time), but once working, was easy to add/change new documents/layouts.
As it uses wkhtmltopdf under to covers, it is a HTML->PDF tool, but I prefer that, at least for my use case.
Not sure there is a dotnet-core version, so that might be a problem for some.
I've been using Rotativa[1] for URL to PDF generation which is also a wrapper for wkhtmltopdf. They have a dotnet-core[2] version and also a SaaS[3] but it's worth mentioning that Azure PaaS supports wkhtmltopdf[4] so I just self-host.
Looking at QuestPDF's API docs, it doesn't look like they support URL / HTML to PDF generation. I think this would be a great addition especially given the age and issues with Rotativa and TuesPechkin on their public repos.
The various wkhtmltopdf wrappers (there are many for .NET) work, but note wkhtmltopdf itself (based on Qt 4/5) is abandoned and the general response for issues was always 'just hack the HTML until it sorta works'.
We're using Puppeteer with Chrome. It's easy to test, as basically it runs Chrome's Print to PDF. Difficult to work with headers and footers and page breaks can be tricky, but it could work for a lot of layouts.
its basically a wrapper for wkhtmltopdf but I develop an app that has probably generated a million +/- invoices/statements over the past 5 years with it, and its been rock solid for me. Was a bit of a bear to get it working the first time (not a ton of documentation that I could find at the time), but once working, was easy to add/change new documents/layouts.
As it uses wkhtmltopdf under to covers, it is a HTML->PDF tool, but I prefer that, at least for my use case.
Not sure there is a dotnet-core version, so that might be a problem for some.