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

PDF to Text, a challenging problem

marginalia.nu

Post reply on HN
Print view View original

161–170 of 206 posts

Re: PDF to Text, a challenging problem

#161

Post by Timwi »

numpad0 wrote: post #160
theamk wrote: post #137

Earlier quoted context omitted.

When we get an alternative that can: (1) be stored in a single file (2) Allow tables, images and anything else that can be shown on a piece paper (3) Won't have animation, fold-out text, or anything that cannot be be shown on a piece of paper (4) won't require Javascript or access to external sites that means never.. We've got lucky we at least got PDF before "web designers" made (3) impossible, and marketers made (4…

(-1) be vector format that never gets pixelated (0) that reproduce everywhere on any OS perfectly (0.5) that supports (everything) any typographical engineers ever wanted past and future Bitmap formats are out from clause -1, Office file formats disqualify from clause 0, Markdown doesn't satisfy clause 0.5. Otherwise a Word .doc format covers most of clauses 1-4.

> (0) that reproduce everywhere on any OS perfectly

Can somebody explain why this isn't the case for HTML? I'm frequently in a situation where a website that mimics printed pages fails to render the same between Firefox and Chrome. I wish to understand the primary culprit here. I thought all of the CSS units are completely defined?

Re: PDF to Text, a challenging problem

#162

Post by drfuchs »

coderatlarge wrote: post #139
theamk wrote: post #137

Earlier quoted context omitted.

When we get an alternative that can: (1) be stored in a single file (2) Allow tables, images and anything else that can be shown on a piece paper (3) Won't have animation, fold-out text, or anything that cannot be be shown on a piece of paper (4) won't require Javascript or access to external sites that means never.. We've got lucky we at least got PDF before "web designers" made (3) impossible, and marketers made (4…

dvi ? https://en.m.wikipedia.org/wiki/Device_independent_file_form...

DVI isn’t suitable as you’d still have to intuit where the paragraph- and even word-breaks are; what’s body text vs. headers/footers, sidebars, captions, etc; never mind what math expression a particular jumble of characters and rules came from.

Re: PDF to Text, a challenging problem

#163

Post by cess11 »

noosphr wrote: post #95

I've worked on this in my day job: extracting _all_ relevant information from a financial services PDF for a bert based search engine. The only way to solve that is with a segmentation model followed by a regular OCR model and whatever other specialized models you need to extract other types of data. VLM aren't ready for prime time and won't be for a decade on more. What worked was using doclaynet trained YOLO models…

That looks like a pretty good starting point, thanks. I've been dabbling in vision models but need a much higher degree of accuracy than they seem able to provide, opting instead for more traditional techniques and handling errors manually.

Re: PDF to Text, a challenging problem

#164

Post by lewtun »

> The absolute best way of doing this is these days is likely through a vision based machine learning model, but that is an approach that is very far away from scaling to processing hundreds of gigabytes of PDF files off a single server with no GPU.

SmolDocling is pretty fast and the ONNX weights can be scaled to many CPUs: https://huggingface.co/ds4sd/SmolDocling-256M-preview

Not sure what time scale the author had in mind for processing GBs of PDFs, but the future might be closer than “very far away”

Re: PDF to Text, a challenging problem

#165

Post by noosphr »

cess11 wrote: post #163
noosphr wrote: post #95

I've worked on this in my day job: extracting _all_ relevant information from a financial services PDF for a bert based search engine. The only way to solve that is with a segmentation model followed by a regular OCR model and whatever other specialized models you need to extract other types of data. VLM aren't ready for prime time and won't be for a decade on more. What worked was using doclaynet trained YOLO models…

That looks like a pretty good starting point, thanks. I've been dabbling in vision models but need a much higher degree of accuracy than they seem able to provide, opting instead for more traditional techniques and handling errors manually.

For non-table documents a fine tuned yolov8 + tesseract with _good_ image pre-processing has basically a zero percent error rate on monolingual texts. I say basically because the training data has worse labels than what the multi-model system gives out in the cases that I double checked manually.

But no one reads the manual on tesseract and everyone ends up feeding it garbage, with predictable results.

Tables are an open research problem.

We started training a custom version of this model: https://arxiv.org/pdf/2309.14962 but there wasn't the business case since the bert search model dealt well enough with the word soup that came out of easy ocr. If you're interested drop a line. I'd love to get a model like that trained since it's very low hanging fruit that no one has done right.

Re: PDF to Text, a challenging problem

#166

Post by bartread »

remram wrote: post #128

I built a simple OSS tool for qualitative data analysis, which needs to turn uploaded documents into text (stripped HTML). PDFs have been a huge problem from day one. I have investigated many tools, but two-column layouts and footers etc often still mess up the content. It's hard to convince my (often non-technical) users that this is a difficult problem.

Try Poppler’s pdftohtml command line tool. For me that seems to do a good job of spitting out multi-column text in the right order. Then you have the much easier task of extracting the text from the HTML.

Also, if it does come out in the wrong order for any pages you can analyse element coordinates to figure out which column each chunk of text belongs in.

(Note that you may have to deal with sub-columns if tables are present in any columns. I’ve never had this in my data but you may also find blocks that span across more than one column, either in whole or in part.)

They also have a pdftotext tool that may do the job for you if you disable its layout option. If you run it with the layout option enabled you’ll find it generates multi-column text in the output, as it tries to closely match the layout of the input PDF.

I think the pdftohtml tool is probably the way to go just because the extra metadata on each element is probably going to be helpful in determining how to treat that element, and it’s obviously relatively straightforward to strip out the HTML tags to extract plain text.

Re: PDF to Text, a challenging problem

#167

Post by imtringued »

theamk wrote: post #146
protocolture wrote: post #144

Earlier quoted context omitted.

Behold a Bitmap. But for real, thats a pretty easy set of hurdles. Really the barrier is the psychological fallacy that PDF's are immutable.

Should have added "looks good on screen and on paper", "stores text compactly" and "multiple pages supported" :) And yes, that's a pretty easy set of hurdles. I wish we'd standardized on DjVu instead. Re "PDF's are immutable." - that's not a psychological fallacy, that's a primary advantage of PDFs. If I wanted mutable format, I'd take an odt (or rtf or a doc). "Output only" format allows one to use the very latest v…

PDFs are not really immutable. I use Okular all the time to write my "notes" (it's just text that you can place anywhere) on top of a PDF form and then print out a new completely filled out PDF. The only thing I do by hand is sign the physical paper.

Re: PDF to Text, a challenging problem

#168

Post by harshreality »

theamk wrote: post #146
protocolture wrote: post #144

Earlier quoted context omitted.

Behold a Bitmap. But for real, thats a pretty easy set of hurdles. Really the barrier is the psychological fallacy that PDF's are immutable.

Should have added "looks good on screen and on paper", "stores text compactly" and "multiple pages supported" :) And yes, that's a pretty easy set of hurdles. I wish we'd standardized on DjVu instead. Re "PDF's are immutable." - that's not a psychological fallacy, that's a primary advantage of PDFs. If I wanted mutable format, I'd take an odt (or rtf or a doc). "Output only" format allows one to use the very latest v…

What's immutable, without tools to decompress and possibly perform further de-obfuscation of text streams, is the typical way publishing software encodes text into streams inside PDFs.

It remains possible to have a pdf with text that is easily mutable with any text editor.

Even if text inside a pdf is annoyingly encoded, you can always just replace the appropriate object/text streams... if you can identify the right one(s). You can extract and edit and re-insert, or simply replace, embedded images as well.

I don't think "this format promotes, as the norm, so much obfuscation of basic text objects that it becomes impractical to edit them in situ without wholesale replacement" is the win you think it is.

"Looks good on paper" has to do with the rendering engine (largely high-DPI and good font handling/spacing/kerning), not PDF as a content layout/presentation format. A high-quality software rasterizer (for postscript or PDF, often embedded in the printer)—not the PDF file format—has been the magic sauce.

Today, some large portion of end-user interaction with PDFs is via rendering into a web browser DOM via javascript. Text in PDFs is rendered as text in the browser. Perhaps nothing else demonstrates more clearly that the "PDF is superior" argument is invalid.

Re: PDF to Text, a challenging problem

#169

Post by djxfade »

Timwi wrote: post #161
numpad0 wrote: post #160

Earlier quoted context omitted.

(-1) be vector format that never gets pixelated (0) that reproduce everywhere on any OS perfectly (0.5) that supports (everything) any typographical engineers ever wanted past and future Bitmap formats are out from clause -1, Office file formats disqualify from clause 0, Markdown doesn't satisfy clause 0.5. Otherwise a Word .doc format covers most of clauses 1-4.

> (0) that reproduce everywhere on any OS perfectly Can somebody explain why this isn't the case for HTML? I'm frequently in a situation where a website that mimics printed pages fails to render the same between Firefox and Chrome. I wish to understand the primary culprit here. I thought all of the CSS units are completely defined?

Probably due to different font rendering in the OS.

Re: PDF to Text, a challenging problem

#170

Post by ninalanyon »

theamk wrote: post #137
hallman76 wrote: post #136

Earlier quoted context omitted.

We will never get back the collective man-decades of time that has been burned by this format. When will the madness stop?

When we get an alternative that can: (1) be stored in a single file (2) Allow tables, images and anything else that can be shown on a piece paper (3) Won't have animation, fold-out text, or anything that cannot be be shown on a piece of paper (4) won't require Javascript or access to external sites that means never.. We've got lucky we at least got PDF before "web designers" made (3) impossible, and marketers made (4…

A subset of HTML and CSS surely does that to a large degree. Data urls solve the single file problem.
Post reply on HN