sadly .net core still lacks a good pdf library that is not priced over the top. (and at least supports building pdfs and creating pdf/a 3's.)
The current generation API for my library is extremely limited because I've never needed one but you are the perfect market research participant. It's an API I'm actively looking to improve.
PDF/A compliance is probably quite a way off though.
[0]: https://github.com/UglyToad/PdfPig [1]: https://github.com/UglyToad/PdfPig#document-creation
basically we don't need a lot, mostly switch fonts/text sizes/images (generated barcodes, logos) and of course pdf/a-3(a/b/u) for invoice. so apis that translate the html into the layouting of pdf is the bigger problem.
Yeah HTML to PDF is a tricky one, presumably wkhtmltopdf/pechkin doesn't work out because of licensing / interop issues? Other than that the only other one I'm aware of is Aspose which is expensive as you say.
Images (along with font subsetting and fixing the gzip implementation) are the next thing I plan to implement so it's helpful to know its a real requirement.
btw. itext is a really great library, unfortunatly itext has a problematic licensing and I tought they were jocking after they gave me prices.
[0]: https://github.com/AngleSharp/AngleSharp [1]: https://html-agility-pack.net/
So we created a "bulk print" option. They tick a bunch of checkboxes for the Foo items, then click the Print button.
Internally we merge all those PDF's together and send one print job to the printer's queue. We used DevExpress [1] to accomplish this, and it worked very well. The only problem: it's expensive.
Multi-billion dollar companies don't mind paying the price tag, but smaller shops sometimes think twice. If a free or near-free alternative existed, that would be fantastic.
[1]: https://github.com/DevExpress-Examples/how-to-merge-document...
It's useful to know that this is a real use case too, I always assumed it was implemented 'just because' but the scenario you describe makes sense.
[0]: https://pdfbox.apache.org/docs/2.0.1/javadocs/org/apache/pdf...
Edit: another option is this pdfium wrapper for NET Core though it merges one pair at a time: https://github.com/GowenGit/docnet
That version has a few unfixed bugs, e.g. merged table cells are sometimes broken, but the code quality is OK on average, relatively easy to fix them if you need to.
[1]https://skia.org/user/sample/pdf [2]https://github.com/mono/SkiaSharp/
https://www.reportlab.com/dev/opensource/
This is a Python implemented API/framework. However, you could use IronPython (compiles to CLR and .NET) and import Reportlab. I've never used it that way, but it's worth the try!
Hope this helps.
I've successfully used it both in .net 4.7 and .net core 2.2 to generate complex pdf structures, and it has been a great experience.
While selling those tools under AGPL certainly would be both Free and open source (but not gratis!) - the only real impact of the AGPL would be on our client - in that they'd be guaranteed the four freedoms (but they generally specify that in the contract anyway - they want the possibility to continue development in house, or with a possible new partner down the road).
However, the products are proprietary in the sense that our client only ever use then in-house and don't distribute them or expose them as public facing services. So no redistribution.
So you're technically correct (the best kind of correct!) - I just think the distinction is important, as you certainly could sell software with AGPL components.