PdfPig

Yeah, pretty much exactly what you said. Since PDF is focused on presentation rather than content it can write text content in any order, and the rules for converting the byte values to unicode values are extremely complex, supporting many different font formats. Some fonts (type 3) don't even include mappings to unicode in some scenarios, instead just encoding the appearance of glyphs and not their meaning. Assuming you have a reasonable PDF file you have to parse the entire page content stream which includes things like colors, lines, Bezier curves, etc, extract the text showing operations and then stitch the letters back in to words and then words back into reading order, as best you can. Many sensible PDF producers encode letters and whitespaces reasonably thereby preserving reading order, but this is far from universal. For an idea o

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

I've been working on an open source PDF library for C# [1] and its given me an immense appreciation for the PDF format. Sure it's horribly long, complex, comes with vulnerabilities and different consumers have different behaviour. But given the constraints of machines at the time it was created and the wide range of requirements and usages it's pretty damn good and has stood the test of time. [1]: https://github.com/UglyToad/PdfPig