Rapid OCR always fails on all kinds of PDFs - Root Cause?!?

[le-dawg]

Environment:

Google Colab with

numpy                                    2.0.2
pymongo                                  4.15.3
python-dotenv                            1.2.1
rich                                     13.7.1
tiktoken                                 0.12.0
transformers                             4.57.1
voyageai                                 0.3.5
PyMuPDF                                  1.26.6
torch                                    2.8.0+cu126
docling                                  2.61.1
rapidocr                                 3.4.2
rapidocr-onnxruntime                     1.4.4

I have reached the point of suicidiality. I followed more tutorials, all of them different, to get a simple thing to work: Extract ANY text from a TEXT only pdf generated from a DOCX by SAVING as PDF (not printing).

The result is always the same:

Processing 123.pdf Downloading RapidOCR models (English only, ONNX) [INFO] 2025-11-09 14:27:30,669 [RapidOCR] base.py:22: Using engine_name: onnxruntime [INFO] 2025-11-09 14:27:30,688 [RapidOCR] main.py:53: Using /root/.cache/huggingface/hub/models--SWHL--RapidOCR/snapshots/1cfba2e90fc938db55889873735088de210cc173/PP-OCRv4/en_PP-OCRv3_det_infer.onnx [INFO] 2025-11-09 14:27:30,943 [RapidOCR] base.py:22: Using engine_name: onnxruntime [INFO] 2025-11-09 14:27:30,953 [RapidOCR] download_file.py:60: File exists and is valid: /usr/local/lib/python3.12/dist-packages/rapidocr/models/ch_ppocr_mobile_v2.0_cls_infer.onnx [INFO] 2025-11-09 14:27:30,957 [RapidOCR] main.py:53: Using /usr/local/lib/python3.12/dist-packages/rapidocr/models/ch_ppocr_mobile_v2.0_cls_infer.onnx [INFO] 2025-11-09 14:27:31,215 [RapidOCR] base.py:22: Using engine_name: onnxruntime [INFO] 2025-11-09 14:27:31,226 [RapidOCR] main.py:53: Using /root/.cache/huggingface/hub/models--SWHL--RapidOCR/snapshots/1cfba2e90fc938db55889873735088de210cc173/PP-OCRv3/en_PP-OCRv3_rec_infer.onnx WARNING:root:RapidOCR conversion failed for /content/drive/MyDrive/SharedForColab/brn temp/Technical information - TI01 - LAB - Pressure less heater.pdf: RapidOCR produced no textual content. [WARNING] 2025-11-09 14:28:21,920 [RapidOCR] main.py:123: The text detection result is empty WARNING:docling.models.rapid_ocr_model:RapidOCR returned empty result!

calling code: try: dl_doc = convert_with_rapid(pdf_path) # pause() if not document_has_text(dl_doc): raise ValueError('RapidOCR produced no textual content.')

implementation:
`def convert_with_rapid(pdf_path: Path) -> DoclingDocument:

from docling.datamodel.document import ConversionResult
from huggingface_hub import hf_hub_download
from docling.models.rapid_ocr_model import RapidOcrOptions  # adjust import if your project exposes it elsewhere

# Minimal English-only RapidOCR assets (single-file downloads)
print("Downloading RapidOCR models (English only, ONNX)")
det_model_path = hf_hub_download(
    repo_id="SWHL/RapidOCR",
    filename="PP-OCRv4/en_PP-OCRv3_det_infer.onnx",
)  # file exists, ~2.4MB.  [oai_citation:0‡Hugging Face](https://huggingface.co/SWHL/RapidOCR/blob/main/PP-OCRv4/en_PP-OCRv3_det_infer.onnx)

rec_model_path = hf_hub_download(
    repo_id="SWHL/RapidOCR",
    filename="PP-OCRv3/en_PP-OCRv3_rec_infer.onnx",
)  # file exists, ~9.0MB.  [oai_citation:1‡Hugging Face](https://huggingface.co/SWHL/RapidOCR/blob/main/PP-OCRv3/en_PP-OCRv3_rec_infer.onnx)

rec_keys_path = hf_hub_download(
repo_id="deepghs/paddleocr",
filename="rec/en_PP-OCRv4_rec/dict.txt",
)

ocr_options = RapidOcrOptions(
    det_model_path=det_model_path,
    rec_model_path=rec_model_path,
    rec_keys_path=rec_keys_path,
    use_cls=False,  # avoid downloading the CLS model
)

pipeline_options = PdfPipelineOptions(
    generate_picture_images=True,
    generate_page_images=False,
    do_picture_description=False,
    ocr_options=ocr_options,
)
if ACCELERATOR_OPTIONS is not None:
    pipeline_options.accelerator_options = ACCELERATOR_OPTIONS

converter = DocumentConverter(
    format_options={
        InputFormat.PDF: PdfFormatOption(
            pipeline_options=pipeline_options,
        ),
    }
)

conversion_result: ConversionResult = converter.convert(source=str(pdf_path))
result = conversion_result.document
return result`


I cannot make it any more simpler. How the living ... can this still fail?!

- PDF is one line of text and two images
- using PyPdfiumDocumentBackend change d nothing
- forcing full OCR is what i want to avoid because all the pdfs are SO DAMN SIMPLE. Nothing is scanned.

[le-dawg]

It is the same problem with easyocr, but at least there the documentation says it does not work with PDF.
Right now I am using pymupdf with custom heuristics to extract information. SO far I have wasted 12 hours to get docling to work. The documentation reallyt makes it seem like a breeze, but I have debugged more foreign code than my own.

What is the --simplest-- way to do --full text extraction-- on PDF files in docling, WITHOUT using actual OCR?

It should be possible, shouldn't it?

[dosubot[bot]]

Hi @le-dawg! I'm Dosu and I’m helping the docling team.

You're running into this because OCR tools like RapidOCR and EasyOCR are designed for scanned/image-based PDFs, not for digital PDFs that already contain selectable text. When you use OCR on a digital PDF (like one exported from Word), the OCR engine tries to find text in images, but since the text is already embedded as a text layer, it finds nothing and returns empty results—this is expected behavior for these tools [source].

Docling does not automatically detect whether a PDF is text-based or image-based. By default, it may run OCR even when it's not needed, which leads to the frustration you're seeing. To extract text from digital PDFs with Docling, you should explicitly disable OCR and use a backend that reads the text layer directly (like PyPdfiumDocumentBackend). Here’s a minimal example:

from docling.document_converter import DocumentConverter, PdfFormatOption
from docling.datamodel.base_models import InputFormat
from docling.datamodel.pipeline_options import PdfPipelineOptions
from docling.backend.pypdfium2_backend import PyPdfiumDocumentBackend

pipeline_options = PdfPipelineOptions(do_ocr=False)
converter = DocumentConverter(
    format_options={
        InputFormat.PDF: PdfFormatOption(
            pipeline_options=pipeline_options,
            backend=PyPdfiumDocumentBackend
        ),
    }
)
result = converter.convert("your_file.pdf")
doc = result.document
print(doc.export_to_markdown())

This will extract the embedded text without running OCR. If you ever need to process scanned/image-based PDFs, set do_ocr=True and make sure an OCR engine is installed [source].

The documentation could be clearer about this distinction. For now, the key is: for digital PDFs, always set do_ocr=False and use a backend like PyPdfiumDocumentBackend for reliable text extraction.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[le-dawg]

@dosu I have implementned a fallback using pymupdf:

def convert_with_pymupdf(
    pdf_path: Path,
    *,
    figure_dir: Path,
    doc_id: str,
) -> tuple[list[dict[str, Any]], dict[str, dict[str, Any]]]:
    figure_dir.mkdir(parents=True, exist_ok=True)
    doc = fitz.open(pdf_path)
    plain_chunks: list[dict[str, Any]] = []
    figure_map: dict[str, dict[str, Any]] = {}
    for page_index, page in enumerate(doc):
        page_text = page.get_text('text').strip()
        if page_text:
            plain_chunks.append({'text': page_text, 'pages': [page_index]})
        for image_index, img in enumerate(page.get_images(full=True)):
            xref = img[0]
            pix = fitz.Pixmap(doc, xref)
            if pix.n >= 4:
                pix = fitz.Pixmap(fitz.csRGB, pix)
            image_filename = 'page{page:03d}_img{idx:02d}.png'.format(
                page=page_index + 1,
                idx=image_index + 1,
            )
            image_path = figure_dir / image_filename
            pix.save(str(image_path))
            figure_id = 'p{page}_img{idx}'.format(
                page=page_index + 1,
                idx=image_index + 1,
            )
            figure_map[figure_id] = {
                'figure_id': figure_id,
                'doc_id': doc_id,
                'caption': None,
                'image_path': str(image_path.resolve()),
                'provenance': [{'page_no': page_index}],
            }
    return plain_chunks, figure_map

Am I losing any quality or Fidelity by not using the backend you proposed?

[dosubot[bot]]

For simple digital PDFs (like those exported from Word), your PyMuPDF pipeline will extract the main text and images just as well as Docling’s PyPdfiumDocumentBackend—there’s no inherent loss of fidelity for basic content. Both libraries read the embedded text layer directly, so you’re not missing out on OCR accuracy or risking garbled output in these straightforward cases.

Where Docling’s backend can add value is in more complex scenarios: it merges fragmented text cells to better preserve layout, extracts richer metadata, and supports structured outputs (like headings, tables, and semantic chunking) that integrate with Docling’s downstream features. If you need standardized document structure, consistent metadata, or plan to use Docling’s advanced features (like exporting to markdown with sections, or semantic search), the official backend is preferable. For plain text and images, PyMuPDF is totally fine and sometimes even more robust, especially if you’re already handling images and chunking yourself.

Edge cases to watch for: both backends can struggle with PDFs that use subsetted or custom fonts without proper Unicode maps, leading to garbled or missing text. Docling’s backend sometimes outputs duplicated or broken characters in these cases, and PyMuPDF can also hit similar issues. Neither is perfect for every PDF, but for simple, modern, text-based PDFs, you’re not losing quality by using PyMuPDF for extraction.

If you ever need Docling’s structure-aware features or run into PDFs with complex layouts, consider switching back to the official backend for those files. Otherwise, your current approach is solid for your described use case.

References:

• PyPdfiumDocumentBackend merges fragmented text cells for better layout fidelity
• Known issues with font mapping and garbled text in both backends
• Docling’s backend provides richer structure and metadata for advanced features

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.