ZeroDivisionError: float division by zero with page.apply_redactions()

[Flint-company]

Description of the bug

Issue #2943 seems still there in version 1.24.5

pip show pymupdf
Name: PyMuPDF
Version: 1.24.5
Summary: A high performance Python library for data extraction, analysis, conversion & manipulation of PDF (and other) documents.
Home-page:
Author: Artifex
Author-email: support@artifex.com
License: GNU AFFERO GPL 3.0
Requires: PyMuPDFb
Required-by: pymupdf4llm

Here's the code involved :

for attr in ContactPersonalDetails.model_fields:
    text_to_remove = getattr(contact_details, attr)
    pprint(text_to_remove)
    for page_index in range(len(doc)):
        page = doc.load_page(page_index)
        page.clean_contents()
        if isinstance(text_to_remove, str) and text_to_remove != '':
            text_instances = page.search_for(text_to_remove)
            for text_instance in text_instances:
                pprint(text_instance)
                page.add_redact_annot(text_instance, ' ')
        
        page.apply_redactions()

Am I doing something wrong maybe ?
Thanks a lot

How to reproduce the bug

Traceback (most recent call last):
  File "/Users/XXXXX/api/qwen.py", line 125, in <module>
    page.apply_redactions()
  File "/Users/XXXXX/api/venv/lib/python3.9/site-packages/pymupdf/utils.py", line 4299, in apply_redactions
    trect = center_rect(annot_rect, new_text, fname, fsize)
  File "/Users/pXXXXX/api/venv/lib/python3.9/site-packages/pymupdf/utils.py", line 4255, in center_rect
    h = math.ceil(text_width / limit) * line_height  # estimate rect height
ZeroDivisionError: float division by zero

PyMuPDF version

1.24.5

Operating system

MacOS

Python version

3.9

[JorjMcKie]

For whatever reason, some of your text_instances rectangles have a width of 0 - this causes the division by zero exception.
So you can check / ignore such rectangles yourself.
But of course the code must also be immunized against such nonsense-input.

[Flint-company]

For whatever reason, some of your text_instances rectangles have a width of 0 - this causes the division by zero exception. So you can check / ignore such rectangles yourself. But of course the code must also be immunized against such nonsense-input.

Thanks !
This leads to another question...
The search_for method returns very odd placements (Rect) of words searched for (ie not at all the place where the word is located in the pdf...).
Is there something I can do to actually search for words and return the right spots or is it too difficult ?

[JorjMcKie]

The success of text searching is dependent on that text is indeed stored in a searchable way. That may not be the case at all! Even if a page looks utterly harmless.

For a demo look at these two files, file1, file2. Both look exactly equal - and in fact, every character is positioned at the exact same place in both of them.
But ...

doc1=pymupdf.open("textmaker.pdf")
doc2=pymupdf.open("textmaker2.pdf")
page1 = doc1[0]
page2 = doc2[0]
needle = "alignment."  # some text to search for
page1.search_for(needle)
[Rect(205.07913208007812, 158.3671875, 257.65399169921875, 172.76171875),
 Rect(91.0791244506836, 158.3671875, 143.65399169921875, 172.76171875)]
page2.search_for(needle)
[]

You will never find any word in file2, however, single characters are no problem.
The solution of this riddle: for demo purposes, characters have been deliberately written on the page in some random sequence.

Text searching contains no precaution to extract single characters and sort them in "natural reading sequence" (what is that anyway?) before finally searching for something. The performance of such an approach would make it unattractive.
So when searching, you implicitly trust that a page has been created in some reasonable way, that the PDF creator has been too lazy to make it difficult.
But there are exceptions: e.g. whenever you use redaction annotations to replace text, then the new text will be an example for out-of-sequence words / characters. This is inevitable with PDF.
We have to live with it.

[Flint-company]

Ok, I got it, very clear. Thanks !

[julian-smith-artifex-com]

Fixed in 1.24.6.