Comment by majora2007
3 months ago
There are a few non-paid PDF libraries, but that is the biggest pain point in .NET, anytime you need advanced features for PDF, you're better off paying for a license (it's just insanely expensive unless you're a large company).
Having worked on some basic parsing of metadata from PDF spec, I would rather pay than have to code something myself. PDF is such a PIA.
I've used libqpdf extensively from C++/CLI with excellent results, but since C++/CLI is deprecated-ish and Windows-only, I wouldn't disagree with PDF being a pain point, and if I get the time, a cross-platform open source .NET wrapper for libqpdf is at the top of my list of potential projects.
libqpdf also intentionally limits its scope to PDF structure, so doesn't address nontrivial content creation or manipulation (page content handling is pretty much limited to compressing/decompressing and parsing/unparsing the content stream).
AFAIK pinvoke (DllImport) works today just like it always has if you want to create FFI calls to C libraries. It's not windows only for sure.
That brings you back to managing memory though, C++/CLI having access to managed C# handles/references for GC'd objects (and finalization) would greatly simplify any memory management at the same time as having first class access to native libaries.
Granted, one could probably build some of the machinery memory management in a simple way but it'd still need to be done and probably not be coherent with other native interfaces.
3 replies →