Is there inverse for Page.remove_rotation()

[rashboldb]

Hi!
Let's say I've applied page.remove_rotation() for a page in a PDF. After I'm done with my business staff (i.e. text extraction, annotation etc) is there a way I can return the original rotation while still preserving visual appearance & content?
Thanks!

[JorjMcKie]

No, there is not.
Technically, this method doesn't do much: (1) exchange the values for page width and height (2) prepend a matrix to the page's /Contents which cause the magic.

But all of that only happens in memory and is thus temporary as long as you do not save.

[rashboldb]

@JorjMcKie ok, so there's no build-in method for this. But is the operation invertible at all? I.e. can't I swap width & height once more if needed, remove the matrix (idk if that makes any sense) from the /Contents?

If the answer is still no, then could you help to understand what would be the diff between these two versions of same PDF (besides rotation) for a PDF consumer? Maybe you can point me to some additional reading on the topic.

Thank you.

[JorjMcKie]

A method like this makes no sense at all: you never could be sure that the page had previously been de-rotated in this way. The effort to fight your way through the jungle of all things that might go wrong is unreasonably high: The method is being used for a reason after all - often enough to simplify insertion of stuff.
So the page may have changed in unforeseeable ways - unrecognizably blurring the fact that that method was ever executed.

For the end user there is / should be no difference.

What might be possible is a method that rotates again in a similar way.

But help me understand your motivation to want this please.

[rashboldb]

Sure, here's the context.
We have PDFs with some architectural drawings. We use YOLO for CV to find some objects of interest there. To do that we take a pic representation of page. The results are the coordinates of the found objects, but they're such if the PDF had 0 rotation. That's not an issue at all, I can just multiply each by derotation matrix.

Then we have to extract some text from the detections we got, and the problem here is that we heavily rely on the orientation of page, i.e. what's top and what's bottom, because we expected some text to be in certain parts of a detection. So this is not the issue as well, we already wrote some code that resolves this for us based on page.rotation prop.

And so on. There're quite a few places where we have to deal with rotation angles & matrices.

And after all this I found that pretty remove_rotation() method which makes all the above steps unnecessary. So it speeds up the total processing time & simplifies the code. And the only problem I worry is if the output PDF is indeed like it was before except its rotation.

[JorjMcKie]

Ok, thanks.
Your comments underpin my previous suggestion: simply don't save the PDF - you seem to only read content anyway.
But even if you save: there is nothing lost.

I was a bit imprecise before though: there is a third action executed by the method. It also modifies any annotation rectangles accordingly. This object type (technically also comprising links and fields) is not part of the page's /Contents and thus will not notice the de-rotation maneuvers.

[rashboldb]

Thank you.