Pith. sign in

REVIEW 5 major objections 6 minor 8 cited by

Docling: An Efficient Open-Source Toolkit for AI-driven Document Conversion

T0 review · 5 major / 6 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Docling is an MIT-licensed, fully local document conversion toolkit that parses PDFs, Office files, images, and HTML into one structured format at sub-second page speeds.

desk verdict A solid engineering report with a useful speed benchmark, but the self-referential test set and missing quality evaluation mean the efficiency claim is only partially supported. read the letter →

arxiv 2501.17887 v1 pith:HTJ7KKLX submitted 2025-01-27 cs.CL cs.CVcs.SE

Nikolaos Livathinos , Christoph Auer , Maksym Lysak , Ahmed Nassar , Michele Dolfi , Panos Vagenas , Cesar Berrospi Ramis , Matteo Omenetti
show 9 more authors
Kasper Dinkla Yusik Kim Shubham Gupta Rafael Teixeira de Lima Valery Weber Lucas Morin Ingmar Meijer Viktor Kuropiatnyk Peter W. J. Staar
This is my paper · ORCID
classification cs.CLcs.CVcs.SE
keywords documentconversionPDFparsinglayoutanalysistablestructurerecognitionOCRretrieval-augmentedgenerationlocalinferenceunifiedrepresentation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Docling sets out to show that high-quality document conversion no longer requires a commercial cloud service or a large GPU cluster. The paper presents a single Python toolkit, released under the MIT license, that parses PDFs, scanned images, Office documents, HTML, and Markdown into a unified structure called DoclingDocument, with specialized local AI models for page layout and table recognition. Its headline evidence is a conversion-speed benchmark: median page conversion of 0.79 seconds on an x86 CPU, 0.32 seconds on an M3 Max SoC, and 114 milliseconds on an L4 GPU. The authors argue this combination of permissive licensing, fully local execution, and speed makes Docling a practical backbone for retrieval-augmented generation, fine-tuning data preparation, and information extraction.

What carries the argument

The carrying mechanism is the DoclingDocument data model, a Pydantic-based unified representation that holds text, tables, pictures, captions, section hierarchy, page provenance, and bounding boxes; every parser and pipeline writes into this one structure, which makes inspection, export, chunking, and framework integration uniform. Around it sits the StandardPdfPipeline, which chains a layout-analysis object detector derived from a real-time detection transformer and trained on DocLayNet with the TableFormer vision transformer for table structure, calling OCR only on scanned or bitmap-bearing pages. This modular separation means heavy models run only when needed and table text is matched back to existing PDF tokens instead of being re-transcribed, which keeps the pipeline fast and language-agnostic.

What would settle it

A reader could rerun the three system configurations on an independent corpus of, say, 100 business and legal PDFs never seen by DocLayNet, using default settings for all tools, and check whether Docling still achieves median sub-second page times and a CPU lead; a reversal in the ranking would show the speed claim does not generalize.

Watch

Extended reading notes

Core claim

The paper's central claim is that a modular, non-generative pipeline can deliver document conversion that is both faithful and fast enough for everyday local use. The core discovery is the architecture: parser backends ingest low-level formats (PDF, images) and markup formats, while a standard PDF pipeline applies a layout-analysis detector and the TableFormer table-structure model, engaging OCR only when bitmap content appears. Because all text comes from the PDF's programmatic tokens or from OCR rather than from a language model, the conversion cannot fabricate content. The benchmark reports that this pipeline converts a 4,008-page test set at median speeds of 0.79 sec/page on x86 CPU, 0.32 sec/page on M3 Max, and 114 ms/page on L4 GPU, and that Docling leads the compared open-source converters on CPU while running entirely locally. The paper also documents that disabling OCR and table recognition saves about 75% of runtime across all configurations.

Load-bearing premise

The benchmark's representativeness rests on the assumption that the test set, built largely from DocLayNet pages, and the chosen versions and settings for the comparison tools reflect how hard real enterprise documents are for every converter equally.

Editorial extensions

If this is right

  • At the reported median speeds, a 100-page document converts in roughly a minute and a half on a commodity CPU, making local conversion practical on laptops and edge servers.
  • Because text is extracted programmatically or via OCR rather than generated, Docling output cannot hallucinate content the way vision-language converters can, which matters for legal and medical transcription.
  • The unified representation with per-item bounding boxes and page provenance means downstream RAG can ground answers in exact page and location metadata.
  • The MIT license and local execution allow integration into commercial products, sensitive-data workflows, and air-gapped environments without licensing fees or data leaving the premises.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The benchmark measures conversion speed only; no quality comparison against the same competitors is reported, so the paper's utility claim rests on an implicit assumption that speed parity implies similar output quality.
  • Because the test set draws heavily on DocLayNet, the dataset used to train Docling's layout model, the speed ranking could shift on document genres far from DocLayNet; an independent corpus would test this.
  • The large runtime share of OCR suggests that swapping OCR backends, or skipping OCR for born-digital PDFs, could yield near-interactive conversion for many office documents.
  • The authors list an open-source quality evaluation framework as future work; building it would let the community compare reading order, table structure, and transcription on public benchmarks, turning the speed advantage into an overall-utility claim.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 6 minor

Summary. The paper introduces Docling, an MIT-licensed open-source document conversion toolkit developed at IBM Research. It describes Docling's architecture (the DoclingDocument data model, parser backends, and the PDF/simple pipelines), its AI models (a layout analysis model retrained on DocLayNet and TableFormer for table structure recognition), and its ecosystem integrations. The central performance claim is supported by a benchmark of 89 PDF files (4008 pages) comparing Docling with Marker, MinerU, and Unstructured on three system configurations: x86 CPU, Apple M3 Max, and NVIDIA L4 GPU. The paper reports per-page conversion times for Docling (median 0.79 s on x86 CPU, 0.32 s on M3 Max, 114 ms on L4 GPU) and average per-page times for all tools, with Docling leading on CPU and M3 Max and MinerU leading on GPU. The paper also emphasizes community adoption, GitHub stars, and integrations with LangChain, LlamaIndex, and other frameworks.

Significance. If the performance and quality claims are taken at face value, Docling is a practically useful open-source asset for local, privacy-preserving document conversion, particularly for RAG and data preparation workloads. The paper's strengths include a concrete speed benchmark with per-model runtime breakdowns, three well-specified hardware configurations, a clearly described modular architecture, and publicly available code and model weights. The speed benchmark is internally consistent and not circular in the sense that conversion time does not reduce to fitting model parameters. However, the paper's broader claims of state-of-the-art quality and accuracy are not measured at all, and the cross-tool speed comparison has several fairness and reproducibility gaps. These issues are load-bearing because the paper's contribution is framed as both efficient and highly accurate; the current evidence supports only the former, and only under in-domain and partially unspecified conditions.

major comments (5)
  1. [§5.1 and §4.1] The benchmark dataset is 'based to a large extend on our DocLayNet dataset' (§5.1), while §4.1 states that the layout analysis model was 're-trained on DocLayNet'. This makes the test set in-domain for Docling's layout model but out-of-domain for Marker, MinerU, and Unstructured. Since layout detection determines which pages trigger OCR and table structure recognition, an in-domain advantage could change the distribution of model invocations and therefore wall-clock time. The paper should either use an independent benchmark set, report per-category results that separate DocLayNet-derived material from CCpdf material, or provide evidence that layout accuracy differences do not materially affect runtime. Without this, the reported speed ranking may not generalize to arbitrary enterprise documents.
  2. [§5.4] The per-page statistics reported for Docling are medians (0.79 s/page on x86 CPU, 0.32 s/page on M3 Max, 114 ms/page on L4 GPU), but the comparison with other tools in Figure 5 and the accompanying text uses average times (3.1 s/page on x86 CPU, 1.27 s/page on M3 Max, 0.49 s/page on L4 GPU). Comparing Docling's median against competitors' means is not an apples-to-apples comparison and can bias the ranking, especially for long-tailed runtime distributions. The paper should report the same summary statistic for all tools, ideally both mean and median, and should make the per-document or per-page distributions available.
  3. [§5.3 and Table 1] The benchmarking methodology states that 'non-essential functionalities were selectively disabled' but never lists which functionalities were disabled for each asset. Table 1 also shows different table-structure settings across tools: Docling uses 'TableFormer (fast)', Unstructured uses 'hi res', and MinerU uses 'rapid table'. Without a full disclosure of disabled features and without any output-quality measurements, a speed advantage could simply reflect a faster-but-less-accurate table model or a reduced feature set. The authors should either align the feature sets across tools, fully specify all disabled options, or augment the speed comparison with quality metrics that rule out a speed-quality tradeoff.
  4. [§8 and Abstract] Section 8 explicitly defers quality evaluation to future work ('we will focus on building an open-source quality evaluation framework...'), yet the abstract and Section 2 describe Docling as powered by 'state-of-the-art' models and 'highly accurate'. Since the paper's central claim includes accuracy and state-of-the-art quality, the absence of any quality measurement is a load-bearing gap. The authors should either add a quality evaluation (e.g., layout, table structure, reading order, OCR accuracy on the same or an independent benchmark) or revise the claims to be strictly about speed, efficiency, and feature availability.
  5. [§5.1 and §5.3] The 89-file benchmark dataset is not released, and the paper does not provide exact commit hashes or pinned dependency versions for the tested tools, only version numbers. This prevents independent reproduction or auditing of the central speed comparison. The authors should publish the dataset (or a reproducible sampler with seeds), the exact configuration files, and per-document timing results so that the benchmark can be independently verified.
minor comments (6)
  1. [§5.1] There is a typo: 'based to a large extend' should be 'based to a large extent'.
  2. [Figure 5 and Table 1] The name 'Mineru' is used in Figure 5 and Table 1 while the text uses 'MinerU'; the capitalization should be consistent.
  3. [§5.2] The vendor name is inconsistently spelled as 'Nvidia' in the text and 'NVIDIA' in the CUDA description; please standardize.
  4. [References] The LlamaIndex reference contains a space inside the URL ('https://github.com/jerryjliu/llama index'), which should be corrected.
  5. [§4.1] The phrase 'docling-ibm models' appears without proper formatting; it should be rendered as a package name, e.g., 'docling-ibm-models'.
  6. [Abstract] The claim that 'the open-source community has fully engaged' is subjective and not supported by evidence in the paper; consider reporting concrete contribution metrics instead.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's central quantitative claim is a measured speed benchmark, not a derived prediction, and its self-citations to DocLayNet and TableFormer are prior published results that do not make the efficiency claim true by construction.

full rationale

The paper makes no closed-form derivation or predictive claim whose output is equivalent to its input. The central result is an empirical wall-clock speed benchmark on three hardware configurations, comparing Docling against Marker, MinerU, and Unstructured. Conversion time is measured, not fitted or predicted from any parameter, so the speed ranking does not reduce to a fit by construction. The benchmark corpus is 'based to a large extend on our DocLayNet dataset' (Section 5.1) and Docling's layout model was 're-trained on DocLayNet' (Section 4.1), creating a legitimate concern about in-domain representativeness and competitive fairness; however, the reported times are real measurements on that corpus, so the overlap is a validity/generalizability issue, not circularity. The 'state-of-the-art' quality characterization of the AI models relies on self-citations to prior publications, but those papers are externally published and contain their own benchmarks, so they are independent support rather than a self-referential proof. Section 8 explicitly defers transparent quality evaluation to future work, and Section 5.3 notes that 'non-essential functionalities' were 'selectively disabled' without listing them; these are reporting limitations that affect confidence in the comparison, but neither constitutes a step in which a result is defined as its own input. No equation equates an output with an input, no fitted parameter is renamed as a prediction, and no uniqueness theorem is imported from the authors to force a choice. Therefore the circularity score is 0.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The central speed claim rests on assumptions about benchmark representativeness, fair competitor configuration, and comparable output quality. No free parameters are fitted to data. No new physical or conceptual entities are introduced; the DoclingDocument is a software data model, not a postulated entity.

assumptions (3)
  • domain assumption The 89-file benchmark set is representative of real-world documents.
    Section 5.1 states the set is based largely on the authors' own DocLayNet dataset plus CCpdf. Generalizability beyond those distributions is assumed.
  • domain assumption Competing tools were configured to a comparable feature set and their reported speed is representative.
    Section 5.3 and Table 1 describe settings chosen by the authors. MinerU did not finish on the Mac, and selectively disabling features may favor different tools.
  • domain assumption Conversion quality across tools is roughly comparable, so speed alone is a fair basis for comparison.
    No quality evaluation is reported. The speed comparison is meaningful only if the outputs of the tools are of similar fidelity, which is not demonstrated.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Docling: An Efficient Open-Source Toolkit for AI-driven Document Conversion." pith.science (2026). https://pith.science/paper/HTJ7KKLX

@misc{pith2026250117887,
  author       = {Pith},
  title        = {Pith review of: Docling: An Efficient Open-Source Toolkit for AI-driven Document Conversion},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/HTJ7KKLX}},
  note         = {Machine review of arXiv:2501.17887}
}
read the original abstract

We introduce Docling, an easy-to-use, self-contained, MIT-licensed, open-source toolkit for document conversion, that can parse several types of popular document formats into a unified, richly structured representation. It is powered by state-of-the-art specialized AI models for layout analysis (DocLayNet) and table structure recognition (TableFormer), and runs efficiently on commodity hardware in a small resource budget. Docling is released as a Python package and can be used as a Python API or as a CLI tool. Docling's modular architecture and efficient document representation make it easy to implement extensions, new features, models, and customizations. Docling has been already integrated in other popular open-source frameworks (e.g., LangChain, LlamaIndex, spaCy), making it a natural fit for the processing of documents and the development of high-end applications. The open-source community has fully engaged in using, promoting, and developing for Docling, which gathered 10k stars on GitHub in less than a month and was reported as the No. 1 trending repository in GitHub worldwide in November 2024.

Figures

Figures reproduced from arXiv: 2501.17887 by the authors.

Figure 1
Figure 1. Sketch of Docling’s pipelines and usage model. Both PDF pipeline and simple pipeline build up a [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 3
Figure 3. Distribution of conversion times for all documents, [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figure 4
Figure 4. Contributions of PDF backend and AI models to the conversion time of a page (in seconds per page). Lower is better. [PITH_FULL_IMAGE:figures/full_fig_p007_4.png] view at source ↗
Figures from the paper (2 more)
Figure 6
Figure 6. Figure 6: Ecosystem of Docling integrations contributed by [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 5
Figure 5. Figure 5: Conversion time in seconds per page on our dataset [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 8 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. GUIDE: Governed Unified Intelligence for Document-to-Artifact Generation in Enterprise Settings

    cs.AI 2026-08 conditional novelty 6.0 of 10

    GUIDE is a governed multi-agent pipeline that converts enterprise guideline documents into validated rules and deployment artifacts, claiming 96% document success and 40 to 125 minute turnaround on 120 confidential documents.

  2. HSD: Training-Free Acceleration for Document Parsing Vision-Language Models with Hierarchical Speculative Decoding

    cs.CV 2026-02 conditional novelty 6.0 of 10

    A training-free, two-stage speculative decoding scheme accelerates VLM document parsers by ~2.8x end-to-end (up to 7x) while keeping parsing accuracy essentially unchanged.

  3. The Hidden Threat in Plain Text: Attacking RAG Data Loaders

    cs.CR 2025-07 conditional novelty 6.0 of 10

    Invisible characters and formatting tricks in ingested documents survive popular RAG data loaders and can manipulate end-to-end RAG outputs.

  4. Granite Vision: a lightweight, open-source multimodal model for enterprise Intelligence

    cs.CV 2025-02 conditional novelty 6.0 of 10

    Granite Vision is a ~3B parameter open-weights vision-language model that reaches state-of-the-art scores on document understanding benchmarks despite its small size.

  5. Youtu-Parsing: Perception, Structuring and Recognition via High-Parallelism Decoding

    cs.CV 2026-01 conditional novelty 5.0 of 10

    A 2.5B vision-language model parses documents into text, formulas, tables, charts, seals, and hierarchy, reporting 5-11x speedups via token-parallel decoding and SOTA OmniDocBench scores.

  6. Advancing Subsurface Discovery and Geothermal Monitoring with an Agentic Artificial Intelligence Framework

    physics.geo-ph 2025-11 reject novelty 5.0 of 10

    GAIA couples an LLM planning agent with retrieval-augmented search and standard seismological tools to automate geothermal monitoring, but no quantitative evaluation is reported.

  7. Automated Evidence Extraction and Scoring for Corporate Climate Policy Engagement: A Multilingual RAG Approach

    cs.CL 2025-09 conditional novelty 5.0 of 10

    A multilingual RAG pipeline combining layout-aware parsing, Nomic embeddings, and few-shot prompting extracts and stance-classifies corporate climate lobbying evidence nearly as accurately as gold human snippets.

  8. Vision-Guided Chunking Is All You Need: Enhancing RAG with Multimodal Document Understanding

    cs.LG 2025-06 conditional novelty 5.0 of 10

    Using a multimodal model to chunk PDF pages in batches with cross-page context raised RAG answer accuracy from 0.78 to 0.89 on the authors' private benchmark.

Reference graph

Works this paper leans on

31 extracted references · 22 canonical work pages · cited by 8 Pith papers

  1. [1]

    , " * write output.state after.block = add.period write newline

    ENTRY address archivePrefix author booktitle chapter edition editor eid eprint howpublished institution isbn journal key month note number organization pages publisher school series title type volume year label extra.label sort.label short.list INTEGERS output.state before.all mid.sentence after.sentence after.block FUNCTION init.state.consts #0 'before.a...

  2. [2]

    write newline

    " write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 global.max substring 't := if while FUNCTION word.in bbl.in capitalize " " * FUNCT...

  3. [3]

    EasyOCR: Ready-to-use OCR with 80+ supported languages

    2024. EasyOCR: Ready-to-use OCR with 80+ supported languages. https://github.com/JaidedAI/EasyOCR

    work page 2024

  4. [4]

    2024. PyMuPDF . https://github.com/pymupdf/PyMuPDF

    work page 2024

  5. [5]

    Ansel, J.; Yang, E.; He, H.; et al. 2024. PyTorch 2: Faster Machine Learning Through Dynamic Python Bytecode Transformation and Graph Compilation. In Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2 (ASPLOS '24). ACM

    work page 2024

  6. [6]

    B.; and Staar, P

    Auer, C.; Dolfi, M.; Carvalho, A.; Ramis, C. B.; and Staar, P. W. 2022. Delivering Document Conversion as a Cloud Service with High Throughput and Responsiveness. In 2022 IEEE 15th International Conference on Cloud Computing (CLOUD), 363--373. IEEE

    work page 2022

  7. [7]

    Berkenbilt, J. 2024. QPDF: A Content-Preserving PDF Document Transformer. https://github.com/qpdf/qpdf

    work page 2024

  8. [8]

    2013--2024 a

    Canny, S.; and contributors. 2013--2024 a . python-docx: Create and update Microsoft Word .docx files with Python. https://python-docx.readthedocs.io/

    work page 2013

Show all 31 references
  1. [9]

    2013--2024 b

    Canny, S.; and contributors. 2013--2024 b . python-pptx: Python library for creating and updating PowerPoint (.pptx) files. https://python-pptx.readthedocs.io/

    2013

  2. [10]

    Chase, H. 2022. LangChain . https://github.com/langchain-ai/langchain

    2022

  3. [11]

    Eric Gazoni, C. C. 2010--2024. openpyxl: A Python library to read/write Excel 2010 xlsx/xlsm files. https://openpyxl.readthedocs.io/

    2010

  4. [12]

    IBM Research . 2024. Bee Agent Framework . https://github.com/i-am-bee/bee-agent-framework

    2024

  5. [13]

    Liu, J. 2022. LlamaIndex . https://github.com/jerryjliu/llama_index

    2022

  6. [14]

    Livathinos, N.; Berrospi, C.; Lysak, M.; Kuropiatnyk, V.; Nassar, A.; Carvalho, A.; Dolfi, M.; Auer, C.; Dinkla, K.; and Staar, P. 2021. Robust PDF Document Conversion using Recurrent Neural Networks. Proceedings of the AAAI Conference on Artificial Intelligence, 35(17): 15137--15145

    2021

  7. [15]

    Lysak, M.; Nassar, A.; Livathinos, N.; Auer, C.; and Staar, P. 2023. Optimized Table Tokenization for Table Structure Recognition . In Document Analysis and Recognition - ICDAR 2023: 17th International Conference , San José , CA , USA , August 21–26, 2023, Proceedings , Part I...

    2023

  8. [16]

    2019--2024

    Ming, F. 2019--2024. Marko: A markdown parser with high extensibility. https://github.com/frostming/marko

    2019

  9. [17]

    Nassar, A.; Livathinos, N.; Lysak, M.; and Staar, P. 2022. Tableformer: Table structure understanding with transformers. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, 4614--4623

    2022

  10. [18]

    Ouyang, L.; Qu, Y.; Zhou, H.; Zhu, J.; Zhang, R.; Lin, Q.; Wang, B.; Zhao, Z.; Jiang, M.; Zhao, X.; Shi, J.; Wu, F.; Chu, P.; Liu, M.; Li, Z.; Xu, C.; Zhang, B.; Shi, B.; Tu, Z.; and He, C. 2024. OmniDocBench: Benchmarking Diverse PDF Document Parsing with Comprehensive Annota...

    2024 arXiv

  11. [19]

    Paruchuri, V. 2024. Marker: Convert PDF to Markdown Quickly with High Accuracy. https://github.com/VikParuchuri/marker

    2024

  12. [20]

    S.; and Staar, P

    Pfitzmann, B.; Auer, C.; Dolfi, M.; Nassar, A. S.; and Staar, P. 2022. DocLayNet: a large human-annotated dataset for document-layout segmentation. 3743--3751

    2022

  13. [21]

    pypdf Maintainers . 2024. pypdf: A Pure-Python PDF Library . https://github.com/py-pdf/pypdf

    2024

  14. [22]

    PyPDFium Team . 2024. PyPDFium2: Python bindings for PDFium . https://github.com/pypdfium2-team/pypdfium2

    2024

  15. [23]

    2004--2024

    Richardson, L. 2004--2024. Beautiful Soup: A Python library for parsing HTML and XML. https://www.crummy.com/software/BeautifulSoup/

    2004

  16. [24]

    D.; and Srivastava, A

    Sudalairaj, S.; Bhandwaldar, A.; Pareja, A.; Xu, K.; Cox, D. D.; and Srivastava, A. 2024. LAB: Large-Scale Alignment for ChatBots. arXiv:2403.01081

    2024 arXiv

  17. [25]

    Turski, M.; Stanis awek, T.; Kaczmarek, K.; Dyda, P.; and Grali \' n ski, F. 2023. CCpdf: Building a High Quality Corpus for Visually Rich Documents from Web Crawl Data. In Fink, G. A.; Jain, R.; Kise, K.; and Zanibbi, R., eds., Document Analysis and Recognition - ICDAR 2023, ...

    2023

  18. [26]

    Unstructured.io Team . 2024. Unstructured.io: Open-Source Pre-Processing Tools for Unstructured Data. https://unstructured.io. Accessed: 2024-11-19

    2024

  19. [27]

    Wang, B.; Xu, C.; Zhao, X.; Ouyang, L.; Wu, F.; Zhao, Z.; Xu, R.; Liu, K.; Qu, Y.; Shang, F.; Zhang, B.; Wei, L.; Sui, Z.; Li, W.; Shi, B.; Qiao, Y.; Lin, D.; and He, C. 2024. MinerU: An Open-Source Solution for Precise Document Content Extraction. arXiv:2409.18839

    2024 arXiv

  20. [28]

    L.; Gugger, S.; Drame, M.; Lhoest, Q.; and Rush, A

    Wolf, T.; Debut, L.; Sanh, V.; Chaumond, J.; Delangue, C.; Moi, A.; Cistac, P.; Rault, T.; Louf, R.; Funtowicz, M.; Davison, J.; Shleifer, S.; von Platen, P.; Ma, C.; Jernite, Y.; Plu, J.; Xu, C.; Scao, T. L.; Gugger, S.; Drame, M.; Lhoest, Q.; and Rush, A. M. 2020. HuggingFac...

    2020 arXiv

  21. [29]

    Wood, D.; Lublinsky, B.; Roytman, A.; Singh, S.; Adam, C.; Adebayo, A.; An, S.; Chang, Y. C.; Dang, X.-H.; Desai, N.; Dolfi, M.; Emami-Gohari, H.; Eres, R.; Goto, T.; Joshi, D.; Koyfman, Y.; Nassar, M.; Patel, H.; Selvam, P.; Shah, Y.; Surendran, S.; Tsuzuku, D.; Zerfos, P.; a...

    2024 arXiv

  22. [30]

    Zhao, Y.; Lv, W.; Xu, S.; Wei, J.; Wang, G.; Dang, Q.; Liu, Y.; and Chen, J. 2023. DETRs Beat YOLOs on Real-time Object Detection. arXiv:2304.08069

    2023 arXiv

  23. [31]

    Zhong, X. 2020. Image-based table recognition: data, model, and evaluation. arXiv:1911.10683

    2020 arXiv

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.