Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

So you want to parse a PDF?

eliot-jones.com

Post reply on HN
Print view View original

111–120 of 236 posts

Re: So you want to parse a PDF?

#111

Post by kwon-young »

throwaway4496 wrote: post #93
quinnjh wrote: post #88

Earlier quoted context omitted.

I don’t think people are suggesting : Build a renderer > build an ocr pipeline > run it on pdfs I think people are suggesting : Use a readymade renderer > use readymade OCR pipelines/apis > run it on pdfs A colleague uses a document scanner to create a pdf of a document and sends it to you You must return the data represented in it retaining as much structure as possible How would you proceed? Return just the metadat…

You can use an existing readymade renderer to render into structured data instead of raster.

Just to illustrate this point, poppler [1] (which is the most popular pdf renderer in open source) has a little tool called pdf2cairo [2] which can render a pdf into a svg. This means you can delegate all pdf rendering to poppler and only work with actual graphical objects to extract semantics.

I think the reason this method is not popular is that there are still many ways to encode a semantic object graphically. A sentence can be broken down into words or letters. Table lines can be formed from multiple smaller lines, etc. But, as mentioned by the parent, rule based systems works reasonably well for reasonably focused problems. But you will never have a general purpose extractor since rules needs to be written by humans.

[1] https://poppler.freedesktop.org/ [2] https://gitlab.freedesktop.org/poppler/poppler/-/blob/master...

Re: So you want to parse a PDF?

#112

Post by jeroenhd »

anon-3988 wrote: post #53

Last weekend I was trying to convert some PDF of Upanishads which contains some Sanskrit and English word. By god its so annoying, I don't think I would be able to without the help of Claude Code with it just reiterating different libraries and methods over and over again. Can we just write things in markdown from now on? I really, really, really, don't care that the images you put is nicely aligned to the right side…

The point of PDFs is that you design them once and they look the same everywhere. I do care very much that the heading in my CV doesn't split the paragraph below it. Automatically parsing and extracting text contents from PDFs is not a main feature of the file format, it's an optional addition.

PDFs don't compete with Markdown. They're more like PNGs with optional support for screen readers and digital signatures. Maybe SVGs if you go for some of the fancier features. You can turn a PDF into a PNG quite easily with readily available tools, so an alternative file format wouldn't have saved you much work.

Re: So you want to parse a PDF?

#113

Post by constantinum »

Other PDF parsing woes include:

1. Identifying form elements like check boxes and radio buttons. 2. Badly oriented PDF scans 3. Text rendered as bezier curves 4. Images embedded in a PDF 5. Background watermarks 6. Handwritten documents

PDF parsing is hell indeed: https://unstract.com/blog/pdf-hell-and-practical-rag-applica...

Re: So you want to parse a PDF?

#114

Post by actionfromafar »

vander_elst wrote: post #81
diptanu wrote: post #15

Disclaimer - Founder of Tensorlake, we built a Document Parsing API for developers. This is exactly the reason why Computer Vision approaches for parsing PDFs works so well in the real world. Relying on metadata in files just doesn't scale across different source of PDFs. We convert PDFs to images, run a layout understanding model on them first, and then apply specialized models like text recognition and table recogn…

It might sound absurd, but on paper this should be the best way to approach the problem. My understanding is that PDFs are intended to produce an output that is consumed by humans and not by computers, the format seems to be focused on how to display some data so that a human can (hopefully) easily read them. Here it seems that we are using a technique that mimics the human approach, which would seem to make sense. I…

1. It's extra work to add an annotation or "internal data format" inside the PDF.

2. By the time the PDF is generated in a real system, the original data source and meaning may be very far off in the data pipeline. It may require incredible cross team and/or cross vendor cooperation.

3. Chicken and egg. There are very few if any machine parseable PDFs out there, so there is little demand for such.

I'm actually much more optimistic of embedding meta data "in-band" with the human readable data, such as a dense QR code or similar.

Re: So you want to parse a PDF?

#115

Post by karel-3d »

cylemons wrote: post #97
karel-3d wrote: post #69

Earlier quoted context omitted.

you can "just" enforce pdf/a ...well there is like 50 different pdf/a versions; just pick one of them :)

That and only commercial pdf libraries support PDF/A. Apperantly, it is much harder than regular PDF so open source libs dont bother.

I am currently building (as a side-project) an easy converter from PDF to PDF/A (PDF/A-3b)... a negative being that it is mostly based on Ghostscript, which is Affero GPL (mainly because Ghostscript makers also make money selling commercial licenses); and that in case of weird font, I just convert all fonts to bitmaps ( https://bugs.ghostscript.com/show_bug.cgi?id=708479 ). It's not done yet though... I am going through verapdf PDF/A testsuite ( https://github.com/veraPDF/veraPDF-corpus ) and still catching bugs

Re: So you want to parse a PDF?

#116

Post by yxhuvud »

throwaway4496 wrote: post #18
diptanu wrote: post #15

Disclaimer - Founder of Tensorlake, we built a Document Parsing API for developers. This is exactly the reason why Computer Vision approaches for parsing PDFs works so well in the real world. Relying on metadata in files just doesn't scale across different source of PDFs. We convert PDFs to images, run a layout understanding model on them first, and then apply specialized models like text recognition and table recogn…

So you parse PDFs, but also OCR images, to somehow get better results? Do you know you could just use the parsing engine that renders the PDF to get the output? I mean, why raster it, OCR it, and then use AI? Sounds creating a problem to use AI to solve it.

Well, you clearly hasn't parsed a wide variety of pdfs. Because if you had, you had been exposed to pdfs that contain only images, or those that contain embedded text, but that embedded text is utter nonsense and doesn't match what is shown on the page when rendered.

And that is before we even get into text structure, because as everyone knows, reading text is easier if things like paragraphs, columns and tables are preserved in the output. And guess what, if you just use the parsing engine for that, then what you get out is a garbled mess.

Re: So you want to parse a PDF?

#117

Post by yxhuvud »

throwaway4496 wrote: post #102
jiveturkey wrote: post #62

Earlier quoted context omitted.

Doesn't rendering to an image require proper parsing of the PDF?

Yes, and don't for a second think this approach of rastering and OCR'ing is sane, let alone a reasonable choice. It is outright absurd.

Noone has claimed getting structured data out of pdfs are sane. What you seem to be missing is that there are no sane ways to get a decent output. The reasonable choice would be to not even try, but business needs invalidate that choice. So what remain is the absurd ways to solve the problem.

Re: So you want to parse a PDF?

#118

Post by philipwhiuk »

jiveturkey wrote: post #61
gcanyon wrote: post #57

The answer seems obvious to me: 1. PDFs support arbitrary attached/included metadata in whatever format you like. 2. So everything that produces PDFs should attach the same information in a machine-friendly format. 3. Then everyone who wants to "parse" the PDF can refer to the metadata instead. From a practical standpoint: my first name is Geoff. Half the resume parsers out there interpret my name as "Geo" and "ff" s…

probably because ff is rendered as a ligature

Or could be so is treated as special.

Re: So you want to parse a PDF?

#119

Post by throwaway4496 »

kwon-young wrote: post #111
throwaway4496 wrote: post #93

Earlier quoted context omitted.

You can use an existing readymade renderer to render into structured data instead of raster.

Just to illustrate this point, poppler [1] (which is the most popular pdf renderer in open source) has a little tool called pdf2cairo [2] which can render a pdf into a svg. This means you can delegate all pdf rendering to poppler and only work with actual graphical objects to extract semantics. I think the reason this method is not popular is that there are still many ways to encode a semantic object graphically. A s…

There is also PDF to HTML, PDF to Text, MuPDF also has PDF to XML, both projects along with a bucketful of other PDF toolkits have PDF to PS, and there is many many XML, HTML, and Text outputs for PS.

Rastering and OCR'ing PDF is like using regex to parse XHTML. My eyes are starting to bleed out, I am done here.

Re: So you want to parse a PDF?

#120

Post by throwaway4496 »

yxhuvud wrote: post #117
throwaway4496 wrote: post #102

Earlier quoted context omitted.

Yes, and don't for a second think this approach of rastering and OCR'ing is sane, let alone a reasonable choice. It is outright absurd.

Noone has claimed getting structured data out of pdfs are sane. What you seem to be missing is that there are no sane ways to get a decent output. The reasonable choice would be to not even try, but business needs invalidate that choice. So what remain is the absurd ways to solve the problem.

[flagged]
Post reply on HN