What's so hard about PDF text extraction? • Hacker News Board

Re: What's so hard about PDF text extraction?

#161

Post by aasasd » Tue, Mar 03, 2020, 7:10 PM UTC

fermienrico wrote: post #93

aasasd wrote: post #89

What a glorious format for storing mankind's knowledge. Consider that by now displays have arbitrary sizes and a variety of proportions, and that papers are often never printed but only read from screens. To reflow text for different screen sizes, you need its ‘semantic’ structure. And meanwhile if you say on HN that HTML should be used instead of PDF for papers, people will jump on you insisting that they need PDF f…

Actually, no thanks. "Sementic" structure is how we got responsive web soup of ugly websites with hamburger menus. We need the opposite, we need a format that stays the same size, same proportions and is vectorized so you can zoom to any size - however, the relationship of space between elements remains constant. PDF is an amazing format IMO. Think of it like Docker - the designer knows exactly how its going to appea…

So you're saying that if you have HTML as a tool then you're irresistibly drawn to making a complex page with menus and ugliness? I don't think that's a problem in HTML. I think the problem is in your head.

> we need a format that stays the same size, same proportions

Please explain how this helps people read a paper on screens of different sizes and proportions. Like me on my phone.

Re: What's so hard about PDF text extraction?

#162

Post by andrewshadura » Tue, Mar 03, 2020, 7:11 PM UTC

I had to go through a fair bit of this when writing my Android receipt printer driver. Parse a PDF print job, detect tables, basic formatting, align text to grid, reformat for 58 mm paper roll width… and that's when the fun begins, since every ESC/POS printer makers supports a different dialect or a different character encoding set, or maybe just one, or maybe there are certain quirks you have to account for…

I should probably write a blog post on this.

https://salsa.debian.org/andrewsh/escpos-android

Re: What's so hard about PDF text extraction?

#163

Post by Abimelex » Tue, Mar 03, 2020, 7:12 PM UTC

used to work on pdf extraction during my bachelor thesis analyzing german law texts. The most fun part here was that the text came shipped in two columns. Sometimes the extraction worked in correct order, sometimes the two lines from two columnes where recognized as one line. I implemented at the end some kind like this algorithm: see here, from chapter 4.4. https://www.dbai.tuwien.ac.at/staff/hassan/pdf2html/final.pd...

Re: What's so hard about PDF text extraction?

#164

Post by sudhirj » Tue, Mar 03, 2020, 7:12 PM UTC

kelvin0 wrote: post #94

sudhirj wrote: post #84

Earlier quoted context omitted.

Are you open to doing more of this? Trying to do the same thing but I’d rather have an expert do it and focus on the app.

Are you building an app?

Building personal finance app to keep track of multiple bank accounts and investments, categorising spends, etc.

Parsing statement PDFs from every bank is pretty hellish.

Re: What's so hard about PDF text extraction?

#165

Post by mLuby » Tue, Mar 03, 2020, 7:14 PM UTC

aasasd wrote: post #89

What a glorious format for storing mankind's knowledge. Consider that by now displays have arbitrary sizes and a variety of proportions, and that papers are often never printed but only read from screens. To reflow text for different screen sizes, you need its ‘semantic’ structure. And meanwhile if you say on HN that HTML should be used instead of PDF for papers, people will jump on you insisting that they need PDF f…

Not everything needs to look good on every screen size. I don't expect to be able to read academic papers on my smartwatch, and a simple alarm clock app looks kind of silly when it's fullscreen across a desktop monitor. Likewise, when layout makes the difference between reader understanding or confusion, it's hard to trust automatic reflowing on unknown screen sizes.

PDF is simply better than HTML when it comes to preserving layout as the author intended.

Re: What's so hard about PDF text extraction?

#166

Post by peterburkimsher » Tue, Mar 03, 2020, 7:15 PM UTC

I had problems with copy-pasting Chinese text from PDFs before. The characters would come out as Kangxi radicals, rather than Traditional Chinese characters. They look the same, but are different code points!

https://pingtype.github.io/docs/docs.html#translateButtons

Re: What's so hard about PDF text extraction?

#167

Post by peterburkimsher » Tue, Mar 03, 2020, 7:17 PM UTC

squaresmile wrote: post #17

kbouck wrote: post #14

On a personal project, I had a good experience extracting PDF text using Tabula[1]. You specify the bounding boxes where desired data is, and it spits out the content it finds. It still hits the issues mentioned in this article (surprise spaces appearing in middle of words, etc) [1] https://tabula.technology/

There's also camelot in Python [1]. Discovered it on HN [2]. Still a decent amount of manual work afterwards though but it's probably unreasonable to expect otherwise. [1] https://camelot-py.readthedocs.io/en/master/ [2] https://news.ycombinator.com/item?id=18199708

I've had a good experience with Camelot extracting table-based data!

Re: What's so hard about PDF text extraction?

#168

Post by omar_a1 » Tue, Mar 03, 2020, 7:19 PM UTC

Quarrelsome wrote: post #46

daniel-levin wrote: post #25

I’m a contractor. One of my gigs involved writing parsers for 20-something different kinds of pdf bank statements. It’s a dark art. Once you’ve done it 20 times it becomes a lot easier. Now we simply POST a pdf to my service and it gets parsed and the data it contains gets chucked into a database. You can go extremely far with naive parsers. That is, regex combined with positionally-aware fixed-length formatting rule…

Any tricks for decimal points versus noise? Its a terrifying outcome and all I've got is doing statistical analysis on the data you've already got and highlighting "outliers".

For something like bank statements, I'd use the rigidly-defined formatting (both number formatting and field position) to inform how to interpret OCR misfires. My larger concern then would be missing a leading 1 (1500.00 v 500.00), but checking for dark pixels immediately preceding the number will flag those errors. And I suppose looking for dark pixels between numbers could help with missed decimals too.

Re: What's so hard about PDF text extraction?

#169

Post by tolmasky » Tue, Mar 03, 2020, 7:22 PM UTC

This is why iPhone didn't initially ship with double-tap to zoom for PDF paragraphs (like it had for blocks on web pages). I know because I was assigned the feature, and I went over to the PDF guy to ask how I would determine on an arbitrary PDF what was probably a "block" (paragraph), and I got a huge explanation on how hard it would be. I relayed this to my manager and the bug was punted.

Edit: To add a little more color, given that none of us was (or at least certainly I wasn't) an expert on the PDF format, we had so far treated the bug like a bug of probably at-most moderate complexity (just have to read up on PDF and figure out what the base unit is or whatever). After discovering what this article talks about, it became evident that any solution we cobbled together in the time we had left would really just be signing up for an endless stream of it-doesn't-work-quite-right bugs. So, a feature that would become a bug emitter. I remember in particular considering one of the main use cases: scientific articles that are usually in two columns, AND also used justified text. A lot of times the spaces between words could be as large as the spaces between columns, so the statistical "grouping" of characters to try to identify the "macro rectangle" shape could get tricky without severely special-casing for this. All this being said, as the story should make clear, I put about one day of thought into this before the decision was made to avoid it for 1.0, so far all I know there are actually really good solutions to this. Even writing this now I am starting to think of fun ways to deal with this, but at the time, it was one of a huge list of things that needed to get done and had been underestimated in complexity.

Re: What's so hard about PDF text extraction?

#170

Post by anthk » Tue, Mar 03, 2020, 7:29 PM UTC

degski wrote: post #151

anthk wrote: post #86

Earlier quoted context omitted.

MuPDF and XPDF can do that by selecting the text with the right mouse buttom.

xpdf seems to have started to respect the not-copyable-flags, while in days yonder, it didn't. So now, even something like a manual of some command-line tools or a text book on C++ or Rust, you still have to re-type the text (wtf). Time to remove and search for something better, something that does not need a 0.5GB update every 3 days (on Windows). (yes, exaggerating slightly)

Maybe it's the new QT version, OpenBSD still has the Motif one, and it works great. For Windows you have SumatraPDF which is pretty good and it's libre.

Also, muPDF for Windows: https://www.mupdf.com/downloads/archive/mupdf-1.16.0-windows... unzip in a folder and run mupdf.exe