Parsr VS pdf2htmlEX

I'm part of the team that build LlamaParse. It's net improvement compare to other PDF->Structured Text extractors (I build several in the past, includig https://github.com/axa-group/Parsr).

For character extraction, LlamaParse use a mixture of OCR / character extraction from the PDF (it's the only parser I'm aware of that address some of the buggy PDF font issues, check the 'text' mode to see raw document before reconstruction), use a mixture of heuristic and Machine learning models to reconstruct the document.

Once plug with a Recursive retrieval strategy, allow you to get Sota result on question answering over complexe text (see notebook: https://github.com/run-llama/llama_parse/blob/main/examples/...).

AMA

Link to the Github Repository and pre defined Docker Compose Build file for Parsr

I would check out https://github.com/Unstructured-IO/unstructured (what lang chain uses) or https://github.com/axa-group/Parsr (probably what unstructured copied to get their startup off the ground lol)

Things I still want to try: - Parsr

I personally haven't used it yet, but I heard some good things about Parsr: https://github.com/axa-group/Parsr

Parsing PDFs is very non-trivial process. Google and Amazon parses are largely based on OCRing. There are some advanced state-of-the-art NN-based OCR approaches but they are not very stable, but a stable industry standard is Tesseract, and nice all-in-one open source tools that brings a ton of tools together is https://github.com/axa-group/Parsr . hope this helps

"Free" book. Actually a really annoying (to the point of unusable) dynamic-loading paginated html page.

The PDF itself nowhere to be found.

Things I have tried: - pdf2htmlEX: Very elegant for normal conversions for users in the browser, but it is so elegant that it keeps the layout, strips tags and put them as styling (CSS) and converts tables to background images; not something useful for me - pdftohtml: Not the most pretty output, disregards tables, puts a lot of tags into the HTML.

I don’t think it’s a question of standards. It’s more that HTML and PDF are different things that solve different problems. PDF is supposed to be a static document that looks exactly the same in every compliant PDF reader. A correctly built PDF with have every glyph that it uses embedded, for example. It’s archival, in the sense that it will always look the same, in any future versions of PDF readers. HTML is markup that describes the author’s intentions to the browser. The reader can use his or her own fonts and have other preferences. The text might reflow to fit screens of various sizes. You can embed all kinds of resources from the network. One can take heroic measures¹ to force an exact rendering, but, in my opinion, that’s a dead end that hacks a markup system to do what it’s not intended to do.

PDF works great on the web; we don’t need to force HTML to replicate its abilities. It already has hyperlinks, and we can seemlessly navigate bewteen PDF and HTML pages in the browser.

[1] https://github.com/coolwanglu/pdf2htmlEX

I'm trying to download an ebook from a website. The document has been created using pdf2htmlEX (https://github.com/coolwanglu/pdf2htmlex).