1.25.3 regression: Generates bbox with negative values

[EdmundsEcho]

Description of the bug

I'm getting bbox value with negative entry values. This seems wrong (and is breaking my logic):

{
      "number": 4,
      "type": 0,
      "bbox": [
         2147483520.0,
         2147483520.0,
         -2147483648.0,
         -2147483648.0
      ],
      "lines": []
   }

from the following snippet where I'm calling get_text on pymupdf.Page:

        text_blocks = list(filter(
            lambda block: block.get("type") == 0, # type 0 is text vs image
            self._page.get_text("rawdict").get("blocks", []) 
        ))

How to reproduce the bug

If I extract a page from the pdf, I can get the parser to work. When I parse all 8 or so pages, I get the negative values.

Finally, if I replace the parser with v1.25.2 I get the expected positive only values.

PyMuPDF version

1.25.3

Operating system

MacOS

Python version

3.11

[JorjMcKie]

This is not a bug!

1. Negative coordinates are always possible in general
2. In your case, these boxes are just the pymupdf.EMPTY_RECT() which indicates nothing was found.

[EdmundsEcho]

@JorjMcKie Thank you for your speedy reply. I updated the issue when I was able to get the code to operate as expected when I changed to version 1.25.2. Does that help?

Also, if I'm getting pymupdf.EMPTY_RECT(), it is preventing the parser from completing the task. I say that because I'm not able to extract information where using the same pdf, I can extract what I expect using the older version.

[JorjMcKie]

Not sure what you mean, but you always need to check for empty bboxes for "blocks", "dict" and "rawdict" variants. These may especially occur when using the clip parameter.
Negative coordinate values can also occur when the bbox is not empty.

[EdmundsEcho]

What is confusing is that the same pdf works with version 1.25.2. Whatever is going on in .3 is preventing my ability to parse the content of the file.

The data structure is a tree representation of a document. What I believe is going on is somehow a parent node gets "confused"/generates a negative bbox preventing leaf node formation. Note: lines is empty. This node is a parent node.

[JorjMcKie]

Let's no longer talk past each other: please provide the file you are having issues with and I'll have a look.

[EdmundsEcho]

Great! Here are the files. The single page worked, but failed in context of the full pdf. Let me know if you can replicate the issue with these files. I had to decrypt and mask personal information so may have changed things in a way that is relevant to what I'm describing.
BMO-layout-1-page-3-decrypted.pdf
BMO-layout-1-decrypted.pdf

Thank you!

[JorjMcKie]

Here is a Jupyter Notebook which extracts all blocks (text & images from all pages as pymupdf.IRect rectangle, just to avoid all those details after the decimal point.
Current PyMuPDF version 1.25.3.
I see no problem at all.
test.zip

[EdmundsEcho]

My only next question: did you try it with python 3.11? (I'm stuck using 3.11 for now)

[JorjMcKie]

Yes, same result.

[EdmundsEcho]

@JorjMcKie Thank you. We did our best to replicate the issue. I greatly appreciate your time and effort. For now I'll freeze my version until I get a better understanding of what could be going on at my end.

[bkonic]

sample_text.pdf
@EdmundsEcho : Just found this discussion while having the same problem: I wrote a text in Libre Office Writer and exported it to pdf. Using pymupdf 1.25.3 and page.get_text("rawdict") I received an empty block with no lines and weird dimensions (and no text). But using get_text() returned the text.
According to your suggestion, I downgraded to 1.25.2 and it works now perfectly.
test_pymupdf.zip

[bkonic]

@JorjMcKie : I also checked version 1.25.4 and 1.25.5 (current). The last version where it works is 1.25.2..

[JorjMcKie]

The reason is a change in MuPDF: how it handles font property overrides made in the PDF's object definitions. In your case, the font (LiberationSerif) definition contains overrides of its ascender / descender values:

<<
  /Type /FontDescriptor
  /FontName /BAAAAA+LiberationSerif
  /Flags 4
  /FontBBox [ -543 -303 1277 981 ]
  /ItalicAngle 0
  /Ascent 0  # <== !!! NONSENSE !!!
  /Descent 0  # <== !!! NONSENSE !!!
  /CapHeight 981
  /StemV 80
  /FontFile2 10 0 R
>>

The current version accepts these nonsense values unquestioningly. And because both values are used to compute the boundary boxes ... the result here are empty boundary boxes, which are consequently ignored.

We will soon (this or next week) publish the next PyMuPDF version, which is based on MuPDF 1.26.0 which handles this situation more thoughtfully.

[bkonic]

@JorjMcKie Thank you very much for the very fast reply. This sounds great! I will check out the new version.