Live data from Hacker News

What's so hard about PDF text extraction?

filingdb.com

311–320 of 350 posts

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

#311
post #8

The relatively small company I work for makes me fill out some forms by hand, because they receive them from vendors as a PDF. So I print it out, sign it, and return it to my company by hand. If someone could make a service that lets you upload a PDF that contains a form, and then let users fill out that form and e-sign it and collect the results, and then print them out all at once, it would be great. It's not a bil…

Coming from a documents format world (publishing), there are a lot of cases like this. In theory it sounds like it should be straightforward but it hinges so much on how well the document is structured underneath the surface. Being that these tools were primarily designed for non-technical users first the priority is in the visual and printed outcome and not the underlying structure. One document can look much the sa…

Out of curiosity, what exactly are non-technical people doing with PDF's, and why does there need to be a universal tool in the space? What would the tool do with the extracted data?

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

#312

Earlier quoted context omitted.

I've recently done this. Have scanned over 5,000 documents to PDF, then batch converted those from PDF to TIFF using Ghostscript, and then Tesseract to OCR the TIFF and combine both back into a searchable PDF. Tesseract may not be the worlds best OCR software but it's free and both it and Ghostscript are easy to automate. Now all I need is a good front end search system for my document archive.

How did you scan the documents to PDF? I use a Canon P-208 that has served me well for many many years (long may it!) and the OCR on that works well. Does the scanning system you use not do OCR? I use a Mac and Spotlight does a good job of indexing the files. I think alternatives for other OSes might be something like Apache Solr?

I have a Brother ADS-2700w[1] as my scanner which is network connected. It scans directly to a network share (SMB, but also supports FTP, nfs etc.) and outputs as PDF. The PDFs are basically 'dumb' PDFs in that each page of the PDF is an image all wrapped up inside the PDF container.

So that's where Ghostscript comes in. On a schedule I have a script that picks up new PDFs in the share, runs them through Ghostscript to create a multipage TIFF, that TIFF is then given to Tesseract (as it can't handle PDFs natively) which does the OCR and outputs a nice PDF with searchable text. All very simple.

The scanning of the pages is very fast, but the scanner takes an age sending the PDFs over the network - it's ethernet port is only 100mbit/s but to be honest I just think the CPU inside the scanner is slow. It also doesn't have enough internal buffer which means you can't scan the next document until the previous one has completed being sent to the share.

If I hooked the scanner up to USB, then the PC could run the Brother software which does use OCR - but it's not automatic, all it does is display the PDF inside Paperport once the scan is complete. For bulk scanning, it's not workable.

Regarding indexing - I've started looking at Solr, and it might suit my needs. I was hoping for a visual type search system, where you could see thumbnails of the PDFs in the results.

---

[1] https://www.brother.co.uk/scanners/ads-2700w

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

#313
post #212

Earlier quoted context omitted.

So I have a lot of experience with basically the same problem just from working on this: https://www.prettyfwd.com . As an example of the opportunity size just in the email domain, the amount of personal non-spam email sent every day is like 100x the total size of Wikipedia, but nothing is really done with any of this information because of this challenge. Basically applications are things like: - Better search engin…

I often ponder how much of the "old world" will get "digitalized" — translated in numeric form, bits. And how much will just disappear. The question might seem trivial if you think of books, but now think of architecture, language itself (as it evolves), etc. There's almost no question in my mind that most new data will endure in some form, by virtue of being digital from day 1. The endgame for such a company, imho,…

Digital data is arguably more fragile than analogue, offline, paper (or papyrus, or clay tablet) media. We have documents over 3000 years old that can still be read. Meanwhile, the proprietary software necessary to access many existing digital data formats is tied to obsolete hardware, working examples of which may no longer exist, emulators for which may not exist, and insufficient documentation may exist to even enable their creation. Just as one example, see the difficulty in enabling modern access to the BBC's 1986 Domesday Project.

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

#314
post #307
post #284

Earlier quoted context omitted.

It's pretty obviously not a personal attack.

I read "I think the problem is in your head" as talking about the other user personally. Looking more closely, I can read it as a general statement, in which case it wasn't a personal attack. Statements of the form "So you're saying [obviously stupid thing]?" still break the site guidelines, though. https://news.ycombinator.com/newsguidelines.html

Well, firstly I don't need to place words in fermienrico's mouth, since the comment to which I was replying says: ‘"Sementic" structure is how we got responsive web soup of ugly websites with hamburger menus’. On my part I'm trying to figure out why fermienrico considers that connection to be inevitable, in the context of HTML production, as compared to PDF production—i.e. with my correspondent taking the place of an author.

Next:

> I don't think that's a problem in HTML. I think the problem is in your head.

This directly addresses fermienrico's complaint as being targeted at HTML. The ‘in your head’ part says that the problem is imaginary and that the person's reasoning and motivation in arriving at that connection is a mystery to me. So there are two meanings combined, both of which aren't ad hominems. The statement also deliberately invokes the words of the character of Preobrazhensky from Bulgakov's ‘Heart of a Dog’, on the condition of the fresh-born Soviet Union: “The Disruption isn't in the lavatories, it's in the heads”.

Let's inspect the statement more closely. The use of the second-person ‘you’ in hypothetical constructs is ubiquitous in English, instead of a third-person ‘a man’ or ‘one’, e.g.: “When you try reading PDF on a phone, you experience unspeakable horror and loss of all hope”—this doesn't imply that the addressed correspondent is the one doing this, and in fact may be directed at multiple unknown readers or listeners.

The hyperbole of ‘you're nuts’ is, to my knowledge, also a typical feature of colloquial English language, e.g.: “You must be crazy to try reading PDF on a phone”, or “What's wrong with you, that tablet is too small to display PDF adequately”. These both don't mean that the correspondent is literally mentally damaged, but that the speaking party doesn't understand their reasoning or doesn't agree with it.

My choice of words there is rather harsh, yes. Why I needed that is, I've had this same discussion before and I repeatedly failed to extract from people the reasons why they make this inference. I tried different approaches, and now came the time of directly placing the person in the shoes of an author. Still nothing so far.

On top of all this and nitpicking further, even disregarding the above I still can't quite fit the statement in a ‘personal attack’ category: as I understand it, an ‘ad hominem’ works by carrying a belief ‘the person has some bad quality A’ over to ‘the person's opinion B hence must be wrong’. In the case of ‘you must be insane/naive to have the opinion B’ no other personal qualities are involved, and the opinion B is directly stated to be wrong. Possibly uncivil and possibly unsupported yes, personal no.

P.S. Could someone please make the ‘collapse comments’ button-link larger on phones? It's even worse on a higher-PPI display, easily taking a dozen attempts to hit it—and extensions like Stylus aren't readily available on phones, what with Firefox dumping them in Preview. Just making the link a dozen characters wide would be splendid.

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

#315
post #44

PDF is, without a doubt, one of the worst file formats ever produced and should really be destroyed with fire... That said, as long as you think of PDF as an image format it's less soul destroying to deal with.

PDF is good at what it's supposed to be good. Parsing pdf to extract data is like using a rock as a hammer and a screw as a nail, if you try hard enough it'll eventually work but it was never intended to be used that way.

“PDF is good at what it's supposed to be good.”

QFT. PDF should really have been called “Print Description Format”. At heart it’s really just a long list of non-linear drawing instructions for plotting font glyphs; a sort of cut-down PostScript.

https://en.wikipedia.org/wiki/PostScript

(And, yes, I have done automated text extraction on raw PDF, via Python’s pdfminer. Even with library support, it is super nasty and brittle, and very document specific. Makes DOCX/XLSX parsing seem a walk in the park.)

What’s really annoying is that the PDF format is also extensible, which allows additional capabilities such as user-editable forms (XFDF) and Accessibility support.

https://www.adobe.com/accessibility/pdf/pdf-accessibility-ov...

Accessibility makes text content available as honest-to-goodness actual text, which is precisely what you want when doing text extraction. What’s good for disabled humans is good for machines too; who knew?

i.e. PDF format already offers the solution you seek. Yet you could probably count on the fingers of one hand the PDF generators that write Accessible PDF as standard.

(As for who’s to blame for that, I leave others to join up the dots.)

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

#317

Earlier quoted context omitted.

Almost any business that has physical suppliers or business customers. PDF is de-facto standard for any invoicing, POs, quotes, etc. If you solve the problem you can effectively programmatically deal with invoicing/payments/ large parts of ordering/dispensing. It's a no brainer to add it on to almost any financial/procurement software that deals with inter business stuff. Any small-medium physical business can probab…

Starting November 2020 in the EU machine-readable invoices will be mandatory in the public sector ( https://eur-lex.europa.eu/eli/dir/2014/55/oj ). As far as I understand there are at least two standards (I know of in Germany): XRechnung and ZUGFeRD/Factur-X (which is PDF A/3 with embedded XML). http://fnfe-mpe.org/factur-x/factur-x_en/

seems to be only for the electronic invoicing in public procurement

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

#318
post #311

Earlier quoted context omitted.

Coming from a documents format world (publishing), there are a lot of cases like this. In theory it sounds like it should be straightforward but it hinges so much on how well the document is structured underneath the surface. Being that these tools were primarily designed for non-technical users first the priority is in the visual and printed outcome and not the underlying structure. One document can look much the sa…

Out of curiosity, what exactly are non-technical people doing with PDF's, and why does there need to be a universal tool in the space? What would the tool do with the extracted data?

All kinds of things. PDF is the unifying data exchange format for a lot of businesses who use computers at some end to manage things and need to exchange documents of any kind without relying on the old "can you open Word files?" type problems.

There is a wide world outside of consumers of SaaS products for every little niche problem.

Sometimes they are baked in processes that still use PDF's to share information, sometimes they're old forms of any kind, sometimes even old scanned docs that are still in use but shared digitally. A lot of the businesses that carry on that way are of the mind that "if it's not broke, don't fix it" which is quite rational for their problem areas and existing knowledge base. They might be a potential market at some point for a new solution, but good luck selling them on a web-based subscription SaaS solution when a simple form has been serving their needs for 30+ years.

OP's problem of the PDF being the go-between to digital endpoints is more common than you might think.

The universality I was referring to was the wide range of possibilities for how a given form might be laid out. And old documents contain a lot of noise when they've been added to or manipulated. Look inside an old PDF form from some small-medium sized business sometime. Now imagine 1000 variations of that form one standard problem. Then multiple that by the number of potential problem areas the forms are managing.

Also like OP said—it's not sexy, but it's very real and having an intelligent PDF form reader and consumer would be a time-saver for those businesses who aren't geared to completely alter their workflow.

The tool could do anything with the extracted data. If it allowed you to connect to any of your in house services (like payroll or accounting) either with a quick config/API or a custom patch, or Google Drive, or whatever without complications like online-required and web accounts especially. No whole solution like that exists to my knowledge. At least nothing accessible to the wider market.

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

#319
post #241

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…

> double-tap to zoom Why wouldn't you just zoom with the center point being where the tap occurred?

Where to center to is only one vector, the other is how much to zoom: ideally it’s such that the text block fits on the screen. But again, that requires knowing the bounds of the text block. Zooming by a constant wherever you tap is a much less useful feature for text (vs. a map for instance), but I think it’s what we defaulted to (can’t remember if it was that of just nothing).

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

#320

Earlier quoted context omitted.

For accuracy and speed. The market SOTA Abbyy is far from being accurate.

> The market SOTA Abbyy is far from being accurate. While Abbyy is likely the best, it's also incredibly expensive. Roughly on the order of $0.01/page or maybe at best a tenth of that in high volume. For comparison, I run a bunch of OCR servers using the open source tesseract library. The machine-time on one of the major cloud providers works out to roughly $0.01 for 100-1000 pages.

OCR.space charges only $10 for 100,000 conversions. The quality is good, but not as good as Abbyy.
Post reply on HN