Live data from Hacker News

So you want to parse a PDF?

eliot-jones.com

141–150 of 236 posts

Re: So you want to parse a PDF?

#141
post #134
post #131

Earlier quoted context omitted.

"Should" is doing a lot of heavy lifting here. I think people underestimate how much use of PDF is actually adversarial; starting with using it for CVs to discourage it being edited by middlemen, then "redaction" by drawing boxes over part of the image, encoding tables in PDF rather than providing CSV to discourage analysis, and so on.

Redaction if only drawing a box over content would not be redaction, I believe that even resulted in some information leakage in the past. PDFs can be edited, unless they are just embedded images but even then it’s possible. The selling point of PDFs is “word” documents that get correctly displayed everywhere, ie they are a distribution mechanism. If you want access to the underlying data that should be provided sepa…

  > The selling point of PDFs is “word” documents that get correctly displayed everywhere
If only we had some type of Portable Document Format, that would be correctly displayed _and parsable_ everywhere.

I do believe that PDF/A (Archiveable) and PDF/UA (Universal Accessibility) do get us there. LibreOffice can export a file as a PDF that supports PDF/A, PDF/UA, and has the original .odt file embedded in it for future archiving. It is an absolutely amazing file format - native readable, parsable, accessible PDF with the source wrapped up. The file sizes are larger, but that's hardly a tradeoff unless one is emailing the files.

Re: So you want to parse a PDF?

#142

Earlier quoted context omitted.

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 m…

  > Chicken and egg. There are very few if any machine parseable PDFs out there, so there is little demand for such.
No, the egg has been laid for quite some time. There's just not enough chicken. Almost every place I've worked at has complained about the parsability of PDF files until I showed them LibreOffice's PDF export feature, that supports PDF/A (arciveable), PDF/UA (Universal Accessibility), and embedding the original .odt file in the PDF itself. That combo format has saved so many people so much headache, I don't know why it is not more widely known.

Re: So you want to parse a PDF?

#143

Yeah, PDF didn't anticipate streaming. That pesky trailer dictionary at the end means you have to wait for the file to fully load to parse it. Having said that, I believe there are "streamable" PDF's where there is enough info up front to render the first page (but only the first page). (But I have been out of the PDF loop for over a decade now so keep that in mind.)

Streaming with a footer should still be possible if your website is capable of processing range requests and sets the content length header. A streaming PDF reader can start with a HEAD request, send a second request for the last few hundred bytes to get the pointers and another request to get the tables, and then continue parsing the rest as normal.

Not great for PDFs generated at request time, but any file stored on a competent web server made after 2000 should permit streaming with only 1-2 RTT of additional overhead.

Unfortunately, nobody seems to care for file type specific streaming parsers using ranged requests, but I don't believe there's a strong technical boundary with footers.

Re: So you want to parse a PDF?

#144

Earlier quoted context omitted.

We do a lot of parsing of PDFs and basically break the structure into 'letter with font at position (box)' because the "structure" within the PDF is unreliable. We have algorithms that combines the individual letters to words, words to lines, lines to boxes all by looking at it geometrically. Obviously identify the spaces between words. We handle hidden text and problematic glyph-to-unicode tables. The output is simi…

Very interesting. How often do you encounter PDFs that are just scanned pages? I had to make heavy use of pdfsandwich last time I was accessing journal articles. > quality is higher because we don't depend on vision based text recognition This surprises me a bit; outside of an actual scan leaving the computer I’d expect PDF->image->text in a computer to be essentially lossless.

This happens -- also variants which have been processed with OCR.

So if it is scanned it contains just a single image - no text.

OCR programs will commonly create a PDF where the text/background and detected images are separate. And then the OCR program inserts transparent (no-draw) letters in place of the text it has identified, or (less frequently) place the letters behind the scanned image in the PDF (i.e. with lower z).

We can detect if something has been generated by an OCR program by looking at the "Creator data" in the PDF that describes the program use to create the PDF. So we can handle that differently (and we do handle that a little bit differently).

PDF->image->text is 100% not lossless.

When you rasterize the PDF, you losing information because you are going from a resolution independent format to a specific resolution: • Text must be rasterized into letters at the target resolution • Images must be resampled at the target resolution • Vector paths must be rasterized to the target resolution

So for example the target resolution must be high enough that small text is legible.

If you perform OCR, you depend on the ability of the OCR program to accurately identify the letters based on the rasterized form.

OCR is not 100% accurate, because it is computer vision recognition problem, and • there are hundrends of thousands of fonts in the wild each with different details and appearances. • two letters can look the same; simple example where trivial OCR/recognition fails is capital letter "I" and lower case "l". These are both vertical lines, so you need the context (letters nearby). Same with "O" and zero. • OCR is also pretty hopeless with e.g. headlines/text written on top of images because it is hard to distinguish letters from the background. But even regular black on white text fails sometimes. • OCR will also commonly identify "ghost" letters in images that are not really there. I.e. pick up a bunch of pixels that have been detected as a letter, but really is just some pixel structure part of the image (not even necessarily text on the image) -- A form of hallucination.

Re: So you want to parse a PDF?

#145

Earlier quoted context omitted.

Seems like a fairly reasonable decision given all the high quality implementations out there.

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".

  > just using the "quality implementation"?
What is the quality implementation?

Re: So you want to parse a PDF?

#146
I've been pondering for a while that we need to move away from layout-based written communication. As in, the need to make things look professionally laid out is an anachronism, and is (very) rarely related to comprehension of the actual content.

For example, submissions to regulatory agencies are huge documents; we spend lots of time in (typically) Microsoft Word creating documents that follow a layout tradition. Aside from this time spent (wasted), the downside is that to guarantee that layout for the recipient, the file must be submitted in DOCX or PDF. These formats are then unfriendly if you want to do anything programatically with them, extract raw data, etc. And of course, while LLMs can read such files, there's likely a significant computational overhead vs. a file in a simple machine-readable format (e.g. text, markdown, XML, JSON).

---

An alternative approach would be to adopt a very simple 'machine first', or 'content first' format - for example, based on JSON, XML, even HTML - with minimum metadata to support strurcture, intra-document links, and embedding of images. For human comsumption, a simple viewer app would reconstitute the file into something more readable; for machine consumption, the content is already directly available. I'm well aware that such formats already exist - HTML/browsers, or EPUB/readers, for example - the issue is to take the rational step towards adopting such a format in place of the legacy alternatives.

I'm hoping that the LLM revolutoion will drive us in just this direction, and that in time, expensive parsing of PDFs is a thing of the past.

Re: So you want to parse a PDF?

#147

PDF is a format for preserving layouts across different platforms when viewing and printing. It is not intended for data processing and so on. I don't see why a structured document format can't exist that simplifies processing and increases accessibility while still preserving the layouts.

What about open office docs? (ODF – OpenDocument Format, like .odt, .ods, .odp)

JavaScript in particular is actively hostile to stability and determinism.

Re: So you want to parse a PDF?

#148
post #139

Earlier quoted context omitted.

Nutrient.io Co-Founder here: We’ve been doing PDF for over 10y. PDF Viewers like Web browsers have to be liberal in what they accept, because PDF has been around for so long, and like with HTML ppl generating files often just iterate until they have something that displays correctly in the one viewer they are testing with. That’s why we built our AI Document Processing SDK (for PDF files) - basically a REST API servi…

Looks super interesting, except for there's no pricing on the page that I could find except for contact sales - totally understand wanting to do a higher touch sales process, but that's going to bounce some % of eng types who want to try things out but have been bamboozled before.

I know - we're working on adding Self-Serve sign up for non-enterprise deals.

But regarding our pricing - I can point you at an actual testimonial https://www.g2.com/products/pspdfkit-sdk/reviews/pspdfkit-sd...

> These pricing structures can be complex and NEED to be understood fully before moving forward with purchase. However, out of all of the solutions that I reviewed, [Nutrient] was the one that walked me through their pricing the best and didn't make me feel like I was going to get fleeced.

Re: So you want to parse a PDF?

#150

Earlier quoted context omitted.

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]

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.
Post reply on HN