.NET Core 3.0 Concludes the .NET Framework API Porting Project

Re:.NET Core 3.0 Concludes the .NET Framework API Porting Pr... by SamuelAdams on Tuesday October 15, 2019 @08:30AM (#21257693)

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

[ Parent | on HN ]

Re:.NET Core 3.0 Concludes the .NET Framework API Porting Pr... by UglyToad on Tuesday October 15, 2019 @08:42AM (#21257760)

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

[ Parent | on HN ]