Image rotation support

[masac]

https://drive.google.com/file/d/1l94pBaPIhii599Tk5xJOKxAgqzah5Z79/view?usp=sharing
I'm a math teacher. I'm trying to use the ruler and the protractor in Xournal++ adding two images. How do I rotate the image of the ruler around the top left corner and the image of the protractor around his center to measure the angle? Thanks!

[andreasb242]

Rotating images is currently not supported.

[andreasb242]

@masac Just to be sure: This is an image, right?

[masac]

Yes, png image. http://www.easychalk.eu/ measure tools-add ruler/add protactor
Such tools it would be extraordinary for Xournal ++.

[andreasb242]

I'll think about this, currently we have nothing like this. KiCad has also something like this, but it measures only temporary, it is not saved.

[rolandlo]

The open source project openboard has such tools (ruler, triangle, protractor, compass) as well, see http://openboard.ch/. Moreover openoard is written in c++, hence it may be easier to make use of it.
Personally I would find such tools very desirable in xournal++.

[Technius]

Two main problems blocking this feature:

• Images are represented by src/model/Image.cpp and are stored internally as a cairo_surface_t. There's no easy way to "rotate" a surface without doing a lot of unnecessary work. So we can't easily rotate an image in its rotate method.
• We can try rotating the image in DocumentView::drawImage with cairo_rotate, so the original surface will not be touched. But this would require us to know the rotation angle, which means that we need to store the angle in Image--a breaking change!

Either way, we cannot implement image rotation until the next major release (1.1.0). However, if we choose to do so, we should

• add a rotation field to Element, so that every element can be rotated;
• unify rotation handling code in DocumentView::drawElement.

[Febbe]

We also should consider to make a XournalSelection derive from Element. So a user can do the same translations to the Selection

[JJones780]

We can try rotating the image in DocumentView::drawImage with cairo_rotate, so the original surface will not be touched. But this would require us to know the rotation angle, which means that we need to store the angle in Image--a breaking change!

Yes, the way to do this is to do the transform when drawing the image. I'd suggest not just for image but to eventually be used for non-destructive transforms for all types of Elements.

• I would suggest adding a transform_matrix field to Element instead of just a rotation field ( to allow all transformations, but specifically allow rotation about an arbitrary point ).

• Migrate scaling to use this matrix as well.

• We could still load files produced by older versions but not vice-versa.

I don't believe this would involve a lot of work... but I could be wrong ;)
The current scaling of a rotated element is a bit broken but this might make it easier to fix as well.

[Cris70]

Any news on this? Image rotation is very much needed :-)

[rolandlo]

Unfortunately that's not something we have been working on. Thanks for the reminder.

[vyi]

Rotation and flipping are immensely useful operations. Please make it happen!

[jsgepc]

+1
My potential use case: electronic lab notebook.

I often take photos of various setups, test devices, etc, and want to put them in the notebook and annotate them, in between analyses, writeups, etc. Not being able to rotate them makes xournal++ unusable for that purpose, for the following reason:

While I could rotate photos in my phone, which is what I usually use to take the photos, I often do not know ahead of time how I want to rotate, crop, etc. So fixing pictures means interrupting my note-taking, getting my phone, finding the photo, rotating it, and reloading it into xournal++. Since I do this a lot when working in the lab, the time cost is prohibitive. Often, the phone makes it worse because it auto-rotates things and I can never be sure of it's true orientation.

Please give this another look, thanks!

[elpablitoyolo]

I use Xounal on a tablet-pc and sometimes make screenshots on landscape because it's easier and then need it on a portrait written page. Rotation could be VERY usefull :D

[RichardScharf]

Currently rotating images by pasting them into Inkscape, rotating them there, copying them again to paste them into GIMP just to copy them immediately again so I can paste them into Xournal++

I wonder why neither rotating directly (nor pasting from Inkscape directly) works.

[Febbe]

Tldr: no one has contributed it yet.

Xournalpp is developed by the community and we never had anyone who is paying us. Therefore we only can spend time at weekends or if we neglect our obligations. Even then it is hard to spend time on the project. Currently we are pretty occupied by all those PRS we have to review that we barely can improve a feature by ourselves. We also have to modernize the code, that we can port to gtk4. So that the project can be kept alive when the gtk3 support is ditched.

[SaVoAMP]

Thanks for your work and dedication to this project.

Although I still think it's strange that this seemingly default and mundane functionality hasn't been implemented in over 4 years whereas more sophisticated nice tools like the set square and precise pdf text highlighting have been implemented recently.

I also miss the functionality of a context menu allowing to put images in the background quickly (without resorting to layers) and thus just opened an issue -> #4950.
As well as multiselect, which is (finally) just waiting to be merged -> #4895

Lack of such mundane quality of life things can add up to be quite annoying in day to day use.

[rolandlo]

While you are right that rotating images is more basic than a set square or pdf text highlighting, there are two reasons that the latter got implemented first:

1. someone with the technical skills cared about it enough
2. it didn't touch the file format and backwards compatibility

[Badhunter0303]

Oh man, this would have been really useful for something I am doing right now

[rolandlo]

Rotating images by 90 degrees is now supported in the test plugin from PR #4884 It only works on Linux though and you will have to install the right versions of luaffifb and lua-vips as described here to use the plugin.

[rolandlo]

@Badhunter0303 You're talking about rotating strokes. That was always possible. The plugin is about rotating images.

[Badhunter0303]

@rolandlo oh
Edit: I deleted what I wrote before, my bad
Edit 2: I am noticing now, you can't also rotate text

[gomarcus]

Any progress on this?
Image + Text rotation is such an important basic/useful functionality and so often needed.
PS: ability to change the z-index of elements, like @SaVoAMP pointed out, is needed too.

[KronosTheLate]

Not to pile on, but I also just want to show interest in this feature. Would be very useful.

[Febbe]

It's a feature we also would like to see, but it seems that currently no one in the core team has much time to spare. What I can offer is, that I or the other ones in the team help someone to implement this.

[Febbe]

I may upload a draft PR at the end of Eastern, to enable general rotation support. But there has still a lot of work to be done:

• Drawing of elements must be fixed
• strokes may require a new implementation for line thickness computation, when the original thickness should be preserved.
• There is currently no export to the translation.
• no way to export this without breaking the current fileformat
  -We need a way, to draw rotated/ transformed elements onto a surface/PDF to export it for older versions

Possible benefits:

• Maybe faster drawing
• less CPU usage
• elements should be scalable / rotatable in general.
• uses linear algebra math instead of posx,y width, height, rotation, to represent a transformation of an object.

[bhennion]

@Febbe, if it helps, I worked a bit on refactoring the EditSelection business here: https://github.com/bhennion/xournalpp/tree/pr/Sel2
It includes a Position class encoding the position of a rectangle (rotated/rescaled/translated/ and geometric transformations. In particular, I spent some time figure out the formulas (the current code on master is overly complicated for those things).
Some of it could be used for this.

[Febbe]

Yes, we actually had a similar approach for different things, I also introduced a transformation matrix here: https://github.com/Febbe/xournalpp/tree/transformable_elements

[disabati]

Can't express enough how much we all appreciate your talent and volunteer work and wanted to add my vote for the Xournal++ IMAGE ROTATION feature. Having a rotation handle and/or a 360 degree rotational dial allowing for fine tuning would be so welcome. LibreOffice Draw is an option but it many times clobbers the PDF content in the process, making it a bad alternative. Thanks for the consideration!