PdfPig

Read and extract text and other content from PDFs in C# (port of PDFBox)

Productivity

Explore on GitHub Read Hacker News discussions

3Distinct people

12Mentions

0Explicit recommenders

2.6KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Read and extract text and other content from PDFs in C# (port of PDFBox)

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:02:05 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year12 dated mentions

Observed mentions: 2019-05-03 17:56:29 UTC to 2025-11-17 22:45:21 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	3	3
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	4	4
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	1	1
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	0	0
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	0	0
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	4	4

What Hacker News says

4 sources

UglyToad·Mar 3, 2020

The open source project I work on [0] returns the letters, their positions and other associated information. We provide support for retrieving words as well as a bunch of different algorithms for document layout analysis [1]. But like the other commenters here mention, it's an extremely difficult problem which doesn't have an easy or general solution. I was trying to build a custom library on top of the open-source library that did a bit more processing, multi-column analysis, statistical analysis of whitespace size, etc. But building something that works for the general case is difficult enough to be functionally impossible. Despite that I think the PDF format is well suited to what it is for and there are very few "implementation mistakes" in the spec itself (no up-front length for inline image data is the main one, plus accessibility o

Read the rest

bviously). It's ultimately become too successful and as a result developers are stuck handling cases where it's being used for entirely the wrong purpose but I can't see a way to another format gaining purchase for the correct purpose (perhaps it's like JavaScript in that way, it has huge adoption because it was first, not because it does all jobs well). Perhaps a content-first format which also handles presentation well could gain a foothold if it came with a shim for PDF viewers and software to use but I dread to think how much effort that would be. [0]:https://github.com/UglyToad/PdfPig [1]:https://github.com/UglyToad/PdfPig/wiki/Document-Layout-Anal...

In What's so hard about PDF text extraction?

UglyToad·Feb 3, 2020

You can buy Clean Code and it's not going to hurt, but I increasingly believe the only way to "step up" is to write code, lots of it. Things like Clean Code are a bit too dogmatic for my tastes now, there are some reasonable ideas there but it's tempting to apply them where they don't fit. What helped me was starting my own large project [0] based off porting another codebase. I started with wanting to follow Clean Code practices to the letter but now, 2/3 years later and with the benefit of hindsight I'm increasingly moving away from a lot of the Clean Code 'rules' (short methods, etc). But I also write other short lived projects which allow me to try different things out and learn from my mistakes. When you think how we learn as children a lot is based on making mistakes and I think that is what's missing from a lot of how programming i

Read the rest

s taught. [0]: https://github.com/UglyToad/PdfPig

In Ask HN: What are your best resources for writing clean code?

UglyToad·Jan 22, 2020

I'll try my best to answer but I may be misunderstanding the question. The current layout analysis algorithms don't do much normalization as far as I'm aware, the Recursive-XY Cut algorithm uses page level font-size information [0] to tune parameters but it doesn't infer a common structure or format either as an input or result. The aim of most layout analysis algorithms is to produce classifications for regions, e.g. paragraphs, titles, lists which I suppose counts as denormalizing the document? Arriving at those classifications generally relies on first splitting the document into sections or regions and then classifying those regions. So far the implemented algorithms mainly focus on the first step, splitting a document into discrete regions. An example of the second step using ML approaches to classify those regions by the same contri

Read the rest

butor can be found here [1]. With the rule based approaches I've been experimenting with you can use certain information from the common producers to normalize certain features. For example line spacing and font size have a well defined relationship, as do whitespace size and font size (though this is a fuzzier relationship and goes out the window entirely for justified text). An example where you rely on non-locality to parse a document, in this SEC filing there are both key values and a table: https://www.sec.gov/Archives/edgar/data/1428796/000110465920... For the values following the subheading "Institutional Investment Manager Filing this Report:" the left hand column are keys for the right hand values. At the bottom of the document there's a table containing the columns "Form 13F File Number" and "Name". Now you could use a couple of rules to infer the difference between the key-values and the table: 1) The keys in a key value list end in ':'. 2) The keys in a key value list have a different font/color to the values. Both of those rules hold true here but not in all or even most documents. For this reason you need to use the whole page to deduce the type of these sections, rather than immediately surrounding features/pixels as an ML algorithm might. [0]: https://github.com/UglyToad/PdfPig/blob/master/src/UglyToad.... [1]: https://github.com/BobLd/PdfPigMLNetBlockClassifier

In Table Detection and Extraction Using Deep Learning

UglyToad·Jan 22, 2020

I had to check we hadn't worked for the same company! Yeah, text extraction and layout analysis from PDFs is a super interesting challenge and still relatively underdeveloped. I'd put table detection at about the hardest challenge in that field. One of the contributors to the PDF library I'm developing has been implementing some interesting algorithms for layout analysis https://github.com/UglyToad/PdfPig/wiki/Document-Layout-Anal...

In Table Detection and Extraction Using Deep Learning