[Feature]: and support PaddlePaddle OCR in the backend

[MyButtermilk]

Describe the proposed feature

There is a new really strong ocr model which should be supported out of thr box: https://github.com/PaddlePaddle/PaddleOCR

[clefru]

I started to work on a plugin for PaddleOCR.
https://github.com/clefru/ocrmypdf-paddleocr
It kinda works, but the packaging for NixOS for PaddleOCR is a bit messy, so I couldn't use the latest version. Feel free to clone/steal.

[jbarlow83]

Looks great.

Please add a license file (eg MIT License) because otherwise it's not actually free for others to use, or for me to include any portion in ocrmypdf.

[clefru]

I added the MPL 2.0 as license to fit with the license of OCRmyPDF.

Maybe think about what version of PaddleOCR you want to target. I think that in the 3.2 PaddleOCR API, you can have much more precise bounding boxes, which would make a lot of the guessing inside my current implementation obsolete.

What's noteworthy is that the PaddleOCR plugin must unset the environment variable OMP_THREAD_LIMIT set by the Tesseract plugin, otherwise it won't work.

[MyButtermilk]

@jbarlow83 : any update on the implementation of PaddleOCR?

[jbarlow83]

It's coming along - I borrowed ideas from the plugin, migrated to PaddleOCR 3.2, and am hoping to give it mainline support, initially as an optional extra.

Unfortunately even 3.2 doesn't seem to resolve individual word bounding boxes which is holding it back.

[MyButtermilk]

@jbarlow83 : PaddleOCR 3.3.0 was recently released. Here the changelog:

Model Introduction:

PaddleOCR-VL is a SOTA and resource-efficient model tailored for document parsing. Its core component is PaddleOCR-VL-0.9B, a compact yet powerful vision-language model (VLM) that integrates a NaViT-style dynamic resolution visual encoder with the ERNIE-4.5-0.3B language model to enable accurate element recognition. This innovative model efficiently supports 109 languages and excels in recognizing complex elements (e.g., text, tables, formulas, and charts), while maintaining minimal resource consumption. Through comprehensive evaluations on widely used public benchmarks and in-house benchmarks, PaddleOCR-VL achieves SOTA performance in both page-level document parsing and element-level recognition. It significantly outperforms existing solutions, exhibits strong competitiveness against top-tier VLMs, and delivers fast inference speeds. These strengths make it highly suitable for practical deployment in real-world scenarios. The model has been released on HuggingFace. Everyone is welcome to download and use it! More introduction infomation can be found in PaddleOCR-VL.
Core Features:

Compact yet Powerful VLM Architecture: We present a novel vision-language model that is specifically designed for resource-efficient inference, achieving outstanding performance in element recognition. By integrating a NaViT-style dynamic high-resolution visual encoder with the lightweight ERNIE-4.5-0.3B language model, we significantly enhance the model’s recognition capabilities and decoding efficiency. This integration maintains high accuracy while reducing computational demands, making it well-suited for efficient and practical document processing applications.
SOTA Performance on Document Parsing: PaddleOCR-VL achieves state-of-the-art performance in both page-level document parsing and element-level recognition. It significantly outperforms existing pipeline-based solutions and exhibiting strong competitiveness against leading vision-language models (VLMs) in document parsing. Moreover, it excels in recognizing complex document elements, such as text, tables, formulas, and charts, making it suitable for a wide range of challenging content types, including handwritten text and historical documents. This makes it highly versatile and suitable for a wide range of document types and scenarios.

[MyButtermilk]

@jbarlow83 : Oh, actually it word bounding boxes are supported by a flag:

If you want word-level bounding boxes (boxes per word instead of per text line) from PaddleOCR, the key lever in the newer pipeline is the parameter return_word_box=True on the PaddleOCR 3.x pipeline predict call.

1) PaddleOCR 3.x: output word-level boxes directly (recommended)

In the General OCR pipeline of PaddleOCR 3.x, you can set return_word_box=True when calling predict.

from paddleocr import PaddleOCR

ocr = PaddleOCR(
    lang="de",
    use_doc_orientation_classify=False,
    use_doc_unwarping=False,
    use_textline_orientation=False,
)

results = ocr.predict("page.png", return_word_box=True)

# For each input you get result objects; easiest is to inspect JSON
r = results[0].json  # dict

# Check keys first because the exact structure can vary slightly by version
print(r.keys())

# In several 3.x builds, enabling return_word_box adds extra fields, e.g.:
# - "text_word": word tokens per line
# - "text_word_region": word-level boxes/regions per line

You will still get the standard line-level outputs (for example, recognized text and line polygons/boxes). The word-level data is added on top when return_word_box=True.

2) What exactly comes back?

From real-world usage and issues, people report that with word boxes enabled you may see fields such as text_word and text_word_region, aligned with the line-level indices.

Typical mapping idea:

rec_texts[i] is the full recognized line

text_word[i] is the list of tokens (words, spaces, sometimes split characters)

text_word_region[i] is the list of corresponding word regions/boxes

3) Two common pitfalls (and how to handle them)
A) Tokenization can split things unexpectedly (umlauts, emails, punctuation)

There are reports of German words (or email addresses) being split into multiple tokens when word boxes are enabled.
If you need “clean” words, you often add a small merge step:

Split words based on explicit whitespace tokens

Merge punctuation/diacritics back into the surrounding token

Compute the final word box as the union of the sub-boxes

B) Blank pages/images can trigger errors

There is a known issue where return_word_box=True can fail on empty images (no text), for example due to missing word-region fields.
To make your pipeline robust:

Check for presence of keys like text_word_region before accessing them

Or wrap access in try/except and return “no words found”