Orientation of text fields and widgets differ when page rotation is 90°

[Papafelice]

Description of the bug

When inserting a text box, the bouding rectangle remains in document coordinates when rotation = 90. However, when inserting a text widget, the bounding box is as seen on the screen but the text flow remains in document coordinates. It would be convenient, if the bounding box and textflow is as seen on the screen or at least both text items should behave the same.

Steps to reproduce

Code snippet:

import fitz         
doc = fitz.open()  
doc.insertPage(0)
page = doc[0]                         

rect1 = fitz.Rect(50,  50, 300, 100)
rect2 = fitz.Rect(50, 100, 300, 150)
rect3 = fitz.Rect(50, 150, 300, 200)
rect4 = fitz.Rect(50, 200, 300, 350)

text = """The quick brown fox jumps over the lazy dog.\nSeveral times..."""
page.insertTextbox(rect1, text, align = 0)
widget = fitz.Widget()
widget.rect = rect2
widget.field_type = fitz.PDF_WIDGET_TYPE_TEXT
widget.field_name = "Text1"
widget.field_value = text
page.addWidget(widget)
page.setRotation(90)
page.insertTextbox(rect3, text, align = 0)
widget.rect = rect4
page.addWidget(widget)
doc.save("out.pdf")
doc.close()

Open the file with a PDF Viewer that can edit fields.

Expected behavior

Either both elements should remain in page coordinates or (better) they should adopt to the screen view such that when you have a graphical display of a page and you select a rectangle with the mouse, the text is inserted as seen on the screen

Configuration

OS: Suse Tumblewheed Linux 5.6.4-1-default 64bit
Python: 3.8.2 64bit
PyMuPDF 1.16.18: Python bindings for the MuPDF 1.16.0 library.
Version date: 2020-04-22 14:00:00. Built for Python 3.8 on linux (64-bit). Installed with pip

[JorjMcKie]

Thanks for spotting this.
You are right of course - this behaviour should be - at least - consistent.

[JorjMcKie]

@Papafelice - the situation is quite complicated:
Where PyMuPDF has control, coordinates are always handled as pertaining to the unrotated page.
When MuPDF inserts stuff, it uses coordinates of the rotated page. Both things coming together leads to the situation that you have observed.
There are two possible solutions:

1. Revert my PyMuPDF logic and also relate coordinates to the rotated page.
2. Try to take MuPDF under control and enforce the behavior of current PyMuPDF.

Solution 1

I think this would introduce even more complication and it also seems to exhibit MuPDF bugs. Look at the following example. Two pages with identical dimensions and identical insertion statements, the second one rotated before insertions take place. Into both of them were inserted a Caret annot, a FreeText annot and a text widget:
page 1

page 2

On page 2, e.g. the Caret annotation is placed at the rotated coordinates Point(20, 20), but the produced appearance is rotated! Similar is true for the text (freetext and text field). The text should follow a horizontal flow, if it were logical, and not being rotated. These are things controlled by MuPDF - meaning I cannot influence them (without rewriting their stuff).

Solution 2

I could set page rotation to 0 every time immediately before I call MuPDF. Then reset it to the original value. Page 2 would then look exactly like the rotated page 1.

Conclusion

I think solution 2 is the viable way. You can try it yourself by unsetting / setting the rotation.
Please let me know your reaction.

[Papafelice]

Solution 1 has the potential of endless fiddling with my code whenever something changes upstream... I agree with you, solution 2 is it.

I will see if I can get it done. The snippet I sent is actually part of a program that I write in order to learn Python: A PDF annotator and digital signer for Linux with preview and zoom. (I know PyMuPDF cannot sign yet, but hope is that by the time my skills are good enough it is there).
The challange seems to me getting the right coordinates when rotated, zoomed and panned wrt to the fixed 72DPI of muPDF.

[JorjMcKie]

I have made little utility methods to do rotation / de-rotation. They are available under the TOOLS object:
fitz.TOOLS._derotate_point(page, point), fitz.TOOLS._rotate_point(page, point), fitz.TOOLS._derotate_rect(page, rect), fitz.TOOLS._rotate_rect(page, rect).
They all deliver tuples, which you may have to convert to Point / Rect respectively (fitz.Rect(tuple) will do that).
They determine the page rotation to do the respective calculations taking the page dimension into account. Obviously returning the original if rotation is 0.

[JorjMcKie]

I know PyMuPDF cannot sign yet, but hope is that by the time my skills are good enough it is there

It is on my list 😉 but time always seems a scarce resource ...

[JorjMcKie]

... zoomed and panned wrt to the fixed 72DPI of muPDF.

Have a look at the document browser here. It supports zooming among other things. 72 dpi is no issue at all - you just have to use the right fitz.Matrix.

[Papafelice]

Thanks for the hint, that's exactly what I'm doing in order to always get the full resolution on the screen:
self.mat = fitz.Matrix(self.zoomself.scale, self.zoomself.scale)
where self.scale is the scaling of the image on the screen view

[Papafelice]

fitz.TOOLS._derotate_rect(page, rect)
That was too easy to be true: just use _derotate and pass the current rotation as rotate= to insertTextbox and everything is fine.

Now how do I rotate the widgets as there is no rotate= parameter?

[JorjMcKie]

Well, you are just lucky because FreeText annots are the only type with a rotation parameter.
Other types and widgets will continue to misbehave, even if it is not always noticable ...

Again my recommendation: as per now use the following circumvention (or hack if you prefer):

old_rotation = page.rotation
# add your annotations, widgets, images, whatever here:
...
# when done with everything, do this:
if old_rotation:
    page.setRotation(old_rotation)

This is what I am currently implementing for the next version.

[JorjMcKie]

New v1.17.0 is uploaded.

I modified annotation handling according to what we discussed. So your hacks should no longer be required - but don't do any harm either.

I hope I didn't forget some corner case ...