{"id":2137,"date":"2026-09-29T08:30:39","date_gmt":"2026-09-29T08:30:39","guid":{"rendered":"https:\/\/cms.research.wpp.com\/?post_type=research_feed&p=2137"},"modified":"2026-09-29T09:52:52","modified_gmt":"2026-09-29T09:52:52","slug":"mineru-the-hard-part-isnt-the-parsing","status":"publish","type":"research_feed","link":"https:\/\/cms.research.wpp.com\/?research_feed=mineru-the-hard-part-isnt-the-parsing","title":{"rendered":"Evaluating MinerU for PDF-to-Markdown Extraction"},"content":{"rendered":"\n
\n
\n

MinerU is an open-source document parser from OpenDataLab, the open-data group at Shanghai Artificial Intelligence Laboratory [1]. It converts PDFs, images and Microsoft Office files into Markdown, a plain-text format with simple marks for headings, lists and tables. It can also produce JSON that records the page layout.<\/p>\n\n\n\n

We installed MinerU 4.0 on a laptop and ran it on five documents: an arXiv preprint in mathematics, a SIGMOD paper on data management, MinerU’s own paper, a photographed page and a typeset dictionary sample.<\/p>\n\n\n\n

Our results show that MinerU produces results that are clearly superior to simple PDF-parsing baselines, respecting much more of the underlying content and structure. This makes it a useful module for any application that relies on the accurate comprehension of unstructured data .<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n\n\n\n

Why not just extract the text?<\/h2>\n\n\n\n

We use one page throughout the article to make the problem concrete: the first page of the dictionary sample, which we call the dictionary page (Figure 1). At the top, a blue bar holds the running head, a line repeated on every page. The same phrase appears underneath as the document title. The main part of the page is a list of dictionary entries in two columns. At the bottom are a page number and a short block of CSS, the code used to style web pages. From this page we want the entries in reading order, the CSS kept as code, and no running head or page number in the text.<\/p>\n\n\n\n

\"\"
The first page of the dictionary sample.<\/figcaption><\/figure>\n\n\n\n

Our second example is the photographed page, a printed page from Google’s ML Kit documentation that was photographed with a phone and saved as a PDF (Figure 2).<\/p>\n\n\n\n

\"\"
The photographed page: Google ML Kit documentation, taken with a phone.<\/figcaption><\/figure>\n\n\n\n

As a baseline, we ran both pages through pypdfium2<\/code>, a Python library that extracts the text stored in a PDF. A PDF usually stores a page as many small pieces of text, each with its own position. pypdfium2<\/code> returns them in the order the file lists them, which is not always the order a person reads them.<\/p>\n\n\n\n

On the photographed page, pypdfium2<\/code> returned zero characters. That is expected because the PDF contains only an image and no text layer for an extractor to read. It returned an empty string with no warning and no error.<\/p>\n\n\n\n

On the dictionary page, it returned 2,707 characters, but in the wrong order. It listed 29 headwords, the words being defined, from Peace, n.<\/code> to Pedantic, a.<\/code>, before giving the first definition. Its first lines were:<\/p>\n\n\n\n

Multi-column Sample\nPeace, n.\nPeaceable, a.\nPeaceful, a.\nPeace-maker, n.\n   ... 24 more headwords ...\nPedantic, a.\nMulti-column Sample\n1. Dictionary Layout\nThe following example shows how to create a basic multi-column document\n1. Calm, repose, quiet, tran?quillity, stillness, silence.\n<\/code><\/pre>\n\n\n\n
The output has three problems:<\/p>\n\n\n\n