Moving Text/Rects in a PDF?

[Tomblarom]

What I want to achieve is rather simple: I want to move the position of certain text rects. These texts are always on the same position on each page, but have different texts. They need to be moved on each page.

My first approach was to get the text by using the rough coordinates of the rect and try to find it by page.get_textbox(fitz.Rect(x0, y0, x1, y1)). However I wasn't able to get the text, without having the exact coordinates, which I'd normally correctly retrieve by page.search_for("text").

The second approach was to use page.read_contents() and iterate over all lines (like here).

Is there a better approach to solve this task?

[JorjMcKie]

If the text "always has the same position", does that mean you have the rect coordinates?
Assuming yes:
Extract the text inside that rect. Then make a redaction annotation and apply it. This will remove the original text.
Then do page.insert_textbox(new_rect, text, ...). This has the problem that you need to have the right font and there still is a fat chance to not looking exactly the same as before.

Going into the mud and modifying the /Contents might work - if you exactly know how to do that ...

[Tomblarom]

For x0 and y0 yes, but the width differs and leads to page.get_textbox(fitz.Rect(x0, y0, x1, y1)) not delivering the String.. However I was able to move the text piece using your examples given in similar questions.

[JorjMcKie]

felicitaciones 😎!

[Tomblarom]

I figured that the text I wanted to move is always at the same x position and that there are no other objects on this value. I took @JorjMcKie code from #1640 (comment) and rewrote it, so that it alters the positions:

import fitz

doc = fitz.open("pdf_in.pdf")
for page in doc:
    page.clean_contents()
    xref = page.get_contents()[0]
    lines = page.read_contents().splitlines()
    imgs = doc.get_page_images(page.number)
    
    for i in range(len(lines)):
        # Find images
        if lines[i].endswith(b"Do"): # OR if b"/Im" in lines[i]:
            for img in imgs:
                if lines[i].decode()[1:4] in img:
                    print(img)
        
        # Move text element
        if lines[i].startswith(b"1 0 0 1 342"):
            parts = lines[i].split()
            parts[4] = str(float(parts[4].decode()) - 50).encode() # X
            parts[5] = str(float(parts[5].decode()) - 40).encode() # Y
            lines[i] = b" ".join(parts)
        
        # Remove text element
        elif lines[i].startswith(b"1 0 0 1 387"):
            for k in range(i-1, i+6):
                lines[k] = b""
            
    doc.update_stream(xref, b"\n".join(lines))

doc.save("pdf_out.pdf")
doc.close()

@JorjMcKie I'd be glad if you could leave some feedback! Especially regarding the byte --> string --> float --> string --> byte conversion, which I'd like to avoid 😂

[Tomblarom]

All right, thanks for the clearification! Totally understandable :) Is there a way to split by line again, without using an old version of PyMuPDF?

[JorjMcKie]

With some effort: yes, indirectly!

[JorjMcKie]

The combination of pretty=True, clean=True does the trick. Obviously, this approach changes all contents of all pages (at least: didn't check the contents of annotations and Form XObjects yet, but presumably those also).

[Tomblarom]

Thanks for the snippet! I was able to implement your workaround, as I wanted to keep using the existing program logic (looping over all lines of a page), instead of rewriting the logic.

And I discovered, that strings that have german umlauts, are presented as b'<[hex]>Tj'. Strings, that have no umlauts are presented as b'([plain])Tj'. My PDF debugger displays them as iso-8859-1 encoded: (4 S\374d) Tj = 4 Süd

[JorjMcKie]

Thanks for the snippet! I was able to implement your workaround, as I wanted to keep using the existing program logic (looping over all lines of a page), instead of rewriting the logic.

And I discovered, that strings that have german umlauts, are presented as b'<[hex]>Tj'. Strings, that have no umlauts are presented as b'([plain])Tj'.

Correct.
And even when looking at those hex characters, you would be able to recover the characters in readable form.
This is thanks to you used a "simple" font: one that supports the direct use of character Unicode values as glyph number.
Advanced fonts do not do that: there is an internal translation from a character's Unicode value to the so-called "glyph number". A glyph is a small vector graphics program that draws the character's visual appearance. Looking at the contents stream in such cases will not allow you to recover the original text.