I'm currently building an open source (not copyleft) PDF library for.NET standard [0] and I'd be interested to hear more what you need on the document generation side.

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

In the past I have frequently needed to merge several existing PDF's together. The idea is this: we have a list of objects Foo in a grid that is available to an end user. Each Foo item has a PDF that can be printed - some of our users really like to just look at the paper print out of everything.

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...

A large chunk of PdfPig started as a port of PdfBox (Java) , so it might be worth considering containerising or in some other way wrapping the PdfBox functionality to get Apache 2 licensed PDF merging [0] if this works for your scenario.

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

wow that looks really nice. actually we mostly do html to pdf, but maybe I can look into your project and try to add it (if there is a nice html/dom library like java has with jsoup).

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.

For html/dom parsing, I would recommend looking at either AngleSharp[0] or HtmlAgilityPack[1], as they tend to be the most popular in the community.

[0]: https://github.com/AngleSharp/AngleSharp [1]: https://html-agility-pack.net/

Thank you for the response.

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.

actually wkhtmltopdf/pechkin both won't support pdf/a-3 and have a not so nice output. aspose is actually really cheap, compared to others, unfortunatly their support is trash: https://forum.aspose.com/t/html-to-pdf-pdf-net-fonts-error-o... i.e. pdf/a-3 does not work on mac (didn't tried linux, but I guess it has similar problems)

btw. itext is a really great library, unfortunatly itext has a problematic licensing and I tought they were jocking after they gave me prices.

I have a .NET Core web app that needs PDF creation abilities. Can I be your market research participant as well?

Of course. Most of the current API focuses on data extraction because that was my area of work when I started the project but I think creation is the more common problem so its good to hear as many use cases as possible.

I’ve just built iTextSharp LGPL for .NET Core 2.2: https://github.com/schourode/iTextSharp-LGPL It only needed a single dependency to build on.NET core, System.Drawing.Common from nuget, for Image and Matrix classes.

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.

btw. we are using it to read pdf's unfortunatly no pdf/a-3 creation support

I'm going to need this very soon (not PDF/A 3 specifically, just PDF). A few months ago I did some research and I figure Skia[1](Sharp)[2] would end up being the base for any .NET core PDF libs. At the time, I was easily able to make a basic functioning demo for a project that ended up dying. Anyone using it in production?

[1]https://skia.org/user/sample/pdf [2]https://github.com/mono/SkiaSharp/

Well we've used Reportlab for most our PDF generation needs. There is also an open-source version of the tool/framework.

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.

Have you tried itextsharp? https://www.nuget.org/packages/iTextSharp/5.5.13.1

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.

AGPL or over 4000€ per server.

DinkToPDF works well to render the HTML produced by Views into PDFs

I've extensively used itext with no issues on core

itext is extremly overpriced. btw. you can't use the AGPL version in any closed source project.

This is one of those cases where distribution really matters; for quite a lot of the work we do, AGPL would probably be fine (to-order in-house business tools;client pays for development, gets source anyway).

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.

I never said that I can't sell AGPL software. just that I can't use AGPL in a closed source project.

I didn't mean to imply you did, just that this distinction is particularly important here, as I've seen quite a few "closed" projects that do need a pdf library, and would be fine with the AGPL.