get a more "general" bbox

[houda-w]

Hello,
I recently discovered the pymupdf library and I am still struggling to wrap my head around some concepts. Yesterday I tried to get the layout of my pdf page (aka bounding boxes of text) however I can't seem to get where I want. the default bbox option clearly only concerns each text line and not a text box. To explain myself better , the picture below , the green boxes, are the result of drawing rects over each "block" , however what I would like to achieve is the red boxes.
is this achievable using pymupdf ? if so how?

(the last pic is the original doc)
Thanks in advance.

[JorjMcKie]

It seems your reading of the documentation is incomplete - understandable as this is a 500 Letter pages PDF document 😉😎.
So here is some hopefully clarifying comment:

• bbox means "boundary box" and refers to a rectangle around interesting stuff like text, images or vector graphics.
• In text extraction, a lot of things have a bbox: characters, text spans, lines and blocks.
• Depending on the the variant of page.get_text(variant, ...) you are using, you will not always see all bboxes - and none at all for the "naive" extraction variant "text".
• The hierarchy of detail levels block -> line -> span -> char is a construct of MuPDF code (base library). These heuristics are fairly complex in trying to make sense out of extracted text portions.

You only included an image of some page - not the PDF page itself, so I cannot decide what we are looking at: standard text, text within images, vector graphics, a mixture of things, or what.

You can extract bboxes for all of these object types as mentioned.
When interested in the most raw bboxes for text, I recommend using above variant = "blocks". This will reflect, what MuPDF has identified as the closest to a text paragraph.

[JorjMcKie]

If - as you write - even the "block" bboxes are too granular, then there is no automatic / programmatic way to join them.
You are the one who must provide the criteria for building larger units.

[houda-w]

Hello m thanks for your reply.
My pdf document only contains text and images as data(and it's only one page, the one in the pic) , though the result rects obtained are accurate , it does represent all the text lines I have in my document I am just having trouble representing the paragraphs rather than just lines.

I used this code :

doc = fitz.open("docs_pdf/amelie1.pdf")
doc2 = fitz.open()   
page = doc[0]
page2 = doc2.new_page(width=page.rect.width , height=page.rect.height) 

blocks = page.get_text("dict")

for block in blocks["blocks"]:
    
    page2.draw_rect(block["bbox"], width=0.3, color=(0,1,0))
# doc2.save("testPDF2")

and as you can see I'm only drawing rects on the higher element of the hierarchy which is "blocks".

if I understand your last reply correctly, you're saying that there isn't a possible way to actually obtain this using this library's direct functions? I have to find a way around it .[
amelie1.pdf
](url)

[JorjMcKie]

Thanks for the file. This helps to better understand.

if I understand your last reply correctly, you're saying that there isn't a possible way to actually obtain this using this library's direct functions? I have to find a way around it.

This is correct. As mentioned, collecting text in blocks already is based on heuristics trying to make sense out of the text on the page - however with reasonable effort. For example, PDF text may be stored in any sequence - character by character even sometimes. If this sequence differs from the "natural" reading order (whatever that is supposed to mean), then the segregation into blocks will not deliver satisfying results: there is no internal sorting of text according to its position on the page.
Here is a file with rectangles wrapping the blocks and a little blue block sequence number top-left.
x.pdf
Based on this, you could join blocks 3 through 5 or 6 because they either overlap or their line-to-line distance is very small.
Same is true for block numbers 8 through 14.

But for everything else? Which criteria could that be?

[houda-w]

Thank you for the explanation. It does make sense to join the close/overlapping blocks , however this would be manual. If I have 100 more files I have to chose which blocks to join in each one of them.
However now that I think about it maybe there is a way to establish some conditions on the positions of the blocks if they're close enough join them if not keep them separated .

But for everything else? Which criteria could that be?

for the rest of the document it's a little bit more complicated (maybe?).
For example, the boxes (with the black rects as headers) should be in separate block and inside of this block I'd like to have sub-blocks (just like I drew in red in my first post) .

P.S: some context: I am trying to extract layouts from different pdf files in order to feed a generative model so it can generate more synthetic layouts ( for data augmentation)

[JorjMcKie]

I understand what you mean.
But I dare say, that these types of things will not become part of the official PyMuPDF.
At best, there will be a number of script examples which solve one or the other special situation.

A full blown solution is beyond the reach of anything less than an AI / ML machinery. And all of what already exists in this field needs to be trained, but still also regularly fails in the next special case.

So I recommend you try to identify a pattern in the documents you are facing and then develop a specialized approach for them.