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

91–100 of 236 posts

Re: So you want to parse a PDF?

#91

Post by jlarocco »

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…

How ridiculous.

`mutool convert -o -F text `

Disclaimer: I work at a company that generates and works with PDFs.

Re: So you want to parse a PDF?

#92

Post by sgt »

Beefin wrote: post #50

founder of mixpeek here, we fine-tune late interaction models on pdfs based on domain https://mixpeek.com/extractors

Do you offer local or on-premise models? There are certain PDF's we cannot send to an API.

Re: So you want to parse a PDF?

#93

Post by throwaway4496 »

quinnjh wrote: post #88
throwaway4496 wrote: post #71

Earlier quoted context omitted.

But all those problems exist when rendering into a surface or rastering. I just don't understand how one thinks, this is a hard problem, let me make it harder by solving the problem into another kind of problem that is just as hard as solving it in the first place (PDF to structured data vs PDF to raster). And then solve the new problem, which is also hard. It is absurd.

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.

Re: So you want to parse a PDF?

#94

Post by troupo »

throwaway4496 wrote: post #80
nottorp wrote: post #77

Earlier quoted context omitted.

How many different PDF generators have done those millions of PDFs tho? Because you're right if you're paid to evaluate all the formats with the Mark 1 eyeball and do a custom parser for each. It sounds like it's feasible for your application. If you want a generic solution that doesn't rely on a human spending a week figuring out that those 4 absolutely positioned text fields are the invoice number together (and in…

We process invoices from around the world, so more PDF generators than I care to count. It is hard a problem for sure, but the problem is the rendering , you can't escape that by rastering it, that is rendering. So it is absurd to pretend you can solve the rendering problem by rendering it into an image instead of a structured format. By rendering it into a raster, now you have 3 problems, parsing the PDF, rendering…

Rendering is a different problem from understanding what's rendered.

If your PDF renders a part of the sentence at the beginning of the document, a part in the middle, and a part at the end, split between multiple sections, it's still rather trivial to render.

To parse and understand that this is the same sentence? A completely different matter.

Re: So you want to parse a PDF?

#95

Post by protomikron »

throwaway4496 wrote: post #72
daemonologist wrote: post #56

Earlier quoted context omitted.

Yes, but a lot of the improvement is coming from layout models and/or multimodal LLMs operating directly on the raster images, as opposed to via classical OCR. This gets better results because the PDF format does not necessarily impart reading order or semantic meaning; the only way to be confident you're reading it like a human would is to actually do so - to render it out. Another thing is that most document parsin…

Hard no. LLMs aren't going to magically do more than what your PDF rendering engine does, rastering it and OCR'ing doesn't change anything. I am amazed at how many people actually think it is a sane idea.

I think there is some kind of misunderstanding. Sure, if you get somehow structured, machine-generated PDFs parsing them might be feasible.

But what about the "scanned" document part? How do you handle that? Your PDF rendering engine probably just says: image at pos x,y with size height,width.

So as parent says you have to OCR/AI that photo anyway and it seems that's also a feasible approach for "real" pdfs.

Re: So you want to parse a PDF?

#96

Post by Muromec »

BobbyTables2 wrote: post #45
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…

Kinda funny. Printing a PDF and scanning it for an email it would normally be worthy of major ridicule. But you’re basically doing that to parse it. I get it, have heard of others doing the same. Just seems damn frustrating that such is necessary. The world sure doesn’t parse HTML that way!

If the html in question would include javascript that renders everything, including text, into a canvas -- yes, this is how you would parse it. And PDF is basically that

Re: So you want to parse a PDF?

#97

Post by cylemons »

karel-3d wrote: post #69
internetter wrote: post #13

Earlier quoted context omitted.

I think a PDF 2.0 would just be an extension of a single file HTML page with a fixed viewport

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.

Re: So you want to parse a PDF?

#98

Post by apt-apt-apt-apt »

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…

Probably for the same reason images were not readable by machines.

Except PDFs dangle hope of maybe being machine-readable because they can contain unicode text, while images don't offer this hope.

Re: So you want to parse a PDF?

#99

Post by throwaway4496 »

troupo wrote: post #94
throwaway4496 wrote: post #80

Earlier quoted context omitted.

We process invoices from around the world, so more PDF generators than I care to count. It is hard a problem for sure, but the problem is the rendering , you can't escape that by rastering it, that is rendering. So it is absurd to pretend you can solve the rendering problem by rendering it into an image instead of a structured format. By rendering it into a raster, now you have 3 problems, parsing the PDF, rendering…

Rendering is a different problem from understanding what's rendered. If your PDF renders a part of the sentence at the beginning of the document, a part in the middle, and a part at the end, split between multiple sections, it's still rather trivial to render. To parse and understand that this is the same sentence? A completely different matter.

Computers "don't understand" things. They process things, and what you're saying is called layoutinng which is a key part of PDF rendering. I do understand for someone unfamiliar with the internals of file formats, parsing, text shapping, and rendering in general, it all might seem like a blackmagic.

Re: So you want to parse a PDF?

#100

Post by throwaway4496 »

protomikron wrote: post #95
throwaway4496 wrote: post #72

Earlier quoted context omitted.

Hard no. LLMs aren't going to magically do more than what your PDF rendering engine does, rastering it and OCR'ing doesn't change anything. I am amazed at how many people actually think it is a sane idea.

I think there is some kind of misunderstanding. Sure, if you get somehow structured, machine-generated PDFs parsing them might be feasible. But what about the "scanned" document part? How do you handle that? Your PDF rendering engine probably just says: image at pos x,y with size height,width. So as parent says you have to OCR/AI that photo anyway and it seems that's also a feasible approach for "real" pdfs.

Okay, this sounds like "because some part of the road is rough, why don't we just drive in the ditch along the road way all the way, we could drive a tank, that would solve it"?
Post reply on HN