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…
That “obvious solution” is very reminiscent of https://xkcd.com/927/ . And, as a sibling notes, it opens up the failure case of the attached data not matching the rendered PDF contents.
So you want to parse a PDF?
211–220 of 236 posts
Re: So you want to parse a PDF?
#212Earlier quoted context omitted.
No model can do better on images than structured data. I am not sure if I am on crack or you're all talking nonsense.
You are assuming structure where there is none. It's not the crack, it's the lack of experience with PDF from diverse sources. Just for instance, I had a period where I was _regularly_ working with PDF files with the letters in reverse order, each letter laid out individually (not a single complete word in the file).
Re: So you want to parse a PDF?
#213Earlier quoted context omitted.
How is it reasonable to render the PDF, rasterize it, OCR it, use AI, instead of just using the "quality implementation" to actually get structured data out? Sounds like "I don't know programming, so I will just use AI".
> How is it reasonable to render the PDF, rasterize it, OCR it, use AI, instead of just using the "quality implementation" to actually get structured data out? Because the underlying "structured data" is never checked while the visual output is checked by dozens of people. "Truth" is the stuff that the meatbags call "truth" as seen by their squishy ocular balls--what the computer sees doesn't matter.
Re: So you want to parse a PDF?
#214Earlier quoted context omitted.
[flagged]
Well, perhaps you are exposed only to special snowflakes of pdfs that are from a single source and somewhat well formed and easy to extract from. Other, like me, are working at companies that also have lots of PDFs, from many, many different sources, and there are no easy ways to extract structured data or even text in a way that always work.
Re: So you want to parse a PDF?
#215Earlier quoted context omitted.
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.
No one said it was as black magic. In the context of OCR and parsing PDFs to convert them to structured data and/or text, rendering is a completely different task from text extraction. As people have pointed out many times in the discussion: https://news.ycombinator.com/item?id=44783004 , https://news.ycombinator.com/item?id=44782930 , https://news.ycombinator.com/item?id=44789733 etc.
In fact, in majority of PDFs, a large part of rendering has to do with composing text.
Re: So you want to parse a PDF?
#216Re: So you want to parse a PDF?
#217Earlier quoted context omitted.
You are assuming structure where there is none. It's not the crack, it's the lack of experience with PDF from diverse sources. Just for instance, I had a period where I was _regularly_ working with PDF files with the letters in reverse order, each letter laid out individually (not a single complete word in the file).
You're thinking "rendering structured data" means parsing PDF as text. That is just wrong. Carefully read what I said. You render the PDF, but into structured data rather than raster. If you still get letters in reverse when you render your PDF into structured data, your rendering engine is broken.
D10
E1
H0
L2,3,9
O4,7
R8
W6
I'm sure that you could look at that and figure out how to structure it. But I highly doubt that you have a general-purpose computer program that can parse that into structured data, having never encountered such a format before. Yet, that is how many real-world PDF files are composed.Re: So you want to parse a PDF?
#218Earlier quoted context omitted.
I would hire someone who understands PDFs instead of doing the equivalent of printing a digital document and scanning it for "digital record keeping". Stop everything and hire someone who understands the basics of data processing and some PDF.
What's the economic justification? Let's assume we have a staff of 10 and they're fully allocated to committed features and deadlines, so they can't be shifted elsewhere. You're the CTO and you ask the BOD for another $150k/y (fully burdened) + equity to hire a new developer with PDF skills. The COB asks you directly: "You can get a battle-tested PDF parser off-the-shelf for little or no cost. We're not in the PDF pa…
Re: So you want to parse a PDF?
#219Earlier quoted context omitted.
Sometimes the characters aren’t even characters, just paths
Wouldn't that be very space inefficient to repeat the paths every time a letter appears in the file? Or you mean that glyph Ids don't necessarily map to Unicode?
Re: So you want to parse a PDF?
#220Earlier quoted context omitted.
You're thinking "rendering structured data" means parsing PDF as text. That is just wrong. Carefully read what I said. You render the PDF, but into structured data rather than raster. If you still get letters in reverse when you render your PDF into structured data, your rendering engine is broken.
How do you render into structured data, from disparate letters that are not structured? D10 E1 H0 L2,3,9 O4,7 R8 W6 I'm sure that you could look at that and figure out how to structure it. But I highly doubt that you have a general-purpose computer program that can parse that into structured data, having never encountered such a format before. Yet, that is how many real-world PDF files are composed.