Converting Shapes into Image Frames (Rotated)

Previous topic - Next topic


Ok I think this might be a bug in Scribus, or just something overlooked by the developers.

In the layout I'm working on, I'm using some of the simple built-in shapes, that I will convert to an image frame. I then rotate the frame., but!, when i add the image, it is rotated with the frame as well.  either I am missing how is to be done, or this was the intent of the developers, or was missed by the developers, or truly is a bug.
I've found this 1.4.4 in linux. and 1.4.5 windows

has anyone else  noted this in Scribus?
Using Scribus 1.5.8 openSUSE 15.5
Advanced hobbyist


As far as I know rotating a frame will also rotate the contents. Both for image frames and text frames.


Nermander's right.

You can't tell Scribus to only rotate the frame/shape and not the contents, or the other way around. It's neither or both.

However, you can:
* Create the shape as you want it - rotated etc. - on a blank document.
* Export the document as an SVG.
* Import the SVG into the document where you want to use it.
* Convert the imported SVG to an image frame.
* Put the image in the new frame.

See the attached screenshot where I rotated the built-in cross shape.

(The SVG can be resized/re-coloured/filled etc. after import so you can keep a number of "standard" rotated shapes in a folder to use when needed.)

It's not pretty, and it's a bit of a pain (especially if you're experimenting), but if you're not doing it a lot then it's worth a try.

[attachment deleted by admin]


OK but I think you missed that I rotated the frame first, and then added the image. I can see if I have the image in place before the rotation that it would rotate both. But if I rotate the frame first then add the image, the image it shouldn't be rotated the same as the frame.
Using Scribus 1.5.8 openSUSE 15.5
Advanced hobbyist


I didn't miss it, I just didn't mention it specifically because that's not the way Scribus works.

An object's rotation affects both the object and its contents at the same time regardless of when you add the content in respect to when you rotate it.

It's consistent behaviour that is easy to learn. The rotation always applies to the whole thing throughout the object's life.

Having said that however, some kind of "Make the current orientation the zero degree rotation" option might be an addition but then I imagine that would have knock-on consequences.

For instance, if you create a rectangular frame, then rotate it, then add text or an image (which will be rotated), then "reset the orientation": Would the text or image be rotated back to horizontal or would it stay rotated? Different people might want different things and so you'd need two rotation attributes for each object; one for the shape and one for the contents.

And that could be more confusing than having a single rotation attribute. Would both be locked together so if you rotated the object again the contents would also rotate by that amount or would the contents be separate and stay where they were? Or would you have yet another option to lock/separate them, thus adding even more complexity?

The same would apply if the text or image is made horizontal when it is first added regardless of the objects prior rotation. You would, again, need two rotation attributes.

Or the orientation of an object could be "reset" back to zero degrees after each rotation but that would have its own conceptual problems, especially for beginners. ("Didn't I just rotate that?") And what if the rotation was - maybe accidentally - by a tiny amount that wasn't very visible initially? Rotation would show as zero but everything would look a bit "off". ("This software is broken.")

It's a tricky issue with no real common ground between the different ways of doing things.

It's a case of: One easily understood rotation for the whole thing VS. Two separate rotation attributes that can get out of line and need more user attention/control.

I can't say what the average user would find easier but my guess is the first one. (It wouldn't be the first time I was wrong though.)


Your version is far more complicated than needs be.
It need to be this simple; Create a shape, convert to image frame, add image, frame and image are locked for the rotation.
Create shape convert to image frame, rotate as needed, add image and orientation of image isnt matched to the frame's orientation.

Your version is just a parameter to add to the image tab of the properties window, you can alter the x & y position of an image, adding an independent parameter for the image rotation shouldn't be much of an addition.

Time to add this to a feature request.
Using Scribus 1.5.8 openSUSE 15.5
Advanced hobbyist


Quote from: AdmFubar on February 19, 2015, 06:35:01 AM
It need to be this simple; Create a shape, convert to image frame, add image, frame and image are locked for the rotation.
Create shape convert to image frame, rotate as needed, add image and orientation of image isnt matched to the frame's orientation.

So, if I do like in the first line, what happends if I need to replace the image?


it's not that hard to add the feature!

but i fear that, currently, your request will land at the bottom of a rather long queue of wishes...

time to go out, buy a good c++ book, and spend the next few months in the basement coding for scribus! :-)

however, i've kept track of the idea as an easy task for somebody wanting to start enhancing the scribus code... now we just have to find volunteers!