Issues in Scribus

Previous topic - Next topic


Hello everybody,

I had the first opportunity to prepare a booklet in Scribus, appreciate that this software is available for free and would like to share a few comments about issues Scribus has, which prevents him to be usable for any more "serious" work:

  • It is not possible to align objects by snapping them to other objects.
  • It is not possible to use any straightforward captions for images (just like in LibreOffice Writer) nor automatic numbering of them.
  • Undo function is very impractical because there is no list of actions which can be undone nor the undone operation is anyhow highlighted. Moreover, the undo function does not work in the text editor.
  • Grabbing nodes (i.e. at setting a frame for an image) often leads to random movement of the nodes during grabbing, even if the mouse does not move.
  • It is not possible to anchor image frames to text.


Hello minimax.

You make some good points and I'd like to reply to some of your comments.

Object snapping would be a very good addition to Scribus. It's a layout application so more assistance in this area would improve it a lot.

While there's no specific "captioning" capability is Scribus you can group text and image frames together, save them to a Scrapbook, then drag them onto a page when needed and edit either without ungrouping by ALT-clicking. Granted it's not very sophisticated, but it's usable.

I agree that the Undo fucnction isn't very good. It simply doesn't work in quite a few circumstances and needs to be implemented in a more robust way.

I've never noticed nodes moving during grabbing. Would you be able to provide a reproducable work-flow that would show the problem you're getting?

You can "anchor" image and text frames by grouping them but, again, it's not very sophisticated. Could you describe what you think an "anchor" should do that grouping objects does not? I'm curious about what you would want the anchor to do under differing circumstances.

As for Scribus not being usable for more "serious" work, have you looked at ? Plenty of people have made some really good stuf with Scribus. Having a browse around the various projects might change your mind. (And this project is looking very nice too:,1365.0.html )

Anyway, I hope you continue to use Scribus and find it more usable as you get more into it.


Anchoring means that for example a frame is anchored to a line in an adjacent text frame. If the line in the text frame is moved (due to text edits) the anchored frame also moves. Very useful for things like margin notes or when you have a column with text with accompanying illustrations next to it.

I think it's common to refer to the feature as "relative positioning".


Thanks for the definition Nermander.

Personally I'd prefer the term "relative positioning". For example, when you anchor a boat you expect the boat to stay where it is - allowing for tides etc. - so I'd expect that "anchoring" an image frame (or whatever) would keep it where it was, which is the default in Scribus. This might just be me being a bit too pedantic.

However, I'm still interested in what minimax would expect from such a feature. It feels like an inline image frame might be good enough, even though I don't really like the idea of them as they seem like a bit of a tacked-on thing and they aren't well documented. (I can't remember, off-hand, how to make one at the moment and I'd have to experiment.)

(This wiki article has some discussion about this sort of thing but I don't know if anything has been done about it.)

There are also other issues such as how does the image frame "follow" the text. See attached PDF for two basic problem examples.

Problem 1 shows where the text goes off the page as it tries to keep with the text before it. (And how could the image follow text frames in a chain? I imagine that would be difficult to code.) Problem 2 shows the same thing but the image is positioned relative before the text.

Obviously I'm being deliberately awkward but it's only to show the difficulties inherent with this sort of feature. I'd agree that such a feature might be useful but it's got to be implemented properly, otherwise Scribus would look bad. (Better to make what's already there rock-solid rather than introduce more stuff that doesn't quite work well enough.)

[attachment deleted by admin]


The point is that if you anchor a frame to a line in a text, the anchor moves if the text moves. And the boat should follow the anchor:)


I'm not sure I'd like to be on a boat that followed its anchor, but I get your point. (It's just me being too pedantic.)

Oh, and on the snapping to objects idea - in the original minimax post - see this other topic,1539.0.html which looks promising.

P.S. Apologies to all for the large size of the PDF I attached earlier. The image I used was way too big for what I needed. (It was a quick knock-up and I didn't check.)


I have used anchoring a lot in MS Word, so I know it's possible to make it work. (And in Word the anchor point is called anchor, and the icon used for it is an anchor:).


I've used anchoring myself in MS Word - and I believe the same thing exists in Libre/OpenOffice too - but I was trying to understand the concept of anchoring as applied to Scribus.

In MS Word the text is the "base" of the document and images are inserted into it. Essentially, the text in Word is the document and everything else moves around it. But in Scribus the "base" of the document is nothing, just a placeholder to add stuff to, so an anchor would have to be in a text frame - which can be chained - and I wasn't sure that the same concept would work properly.

It might work fine, I just think it needs a bit of thinking about first. That's why I asked minimax what they would expect from the feature. For instance, what would happen if you anchored an image to a bit of text and then changed the number of columns in a frame? Or what about when the text moves to a different frame? There are a lot of possible issues to check. It's not a trivial function by any stretch of the imagination.

Personally I think the feature would be a nice addition if it worked well but I like to position things myself so I have full control and don't overlook some automatically-made problem. Having said that, I don't work on large documents so it's easy for me to rearrange things manually but I can see the advantages of automatic/dynamic layouts for large documents.


Thanks for your very exhaustive replies. I had not been automatically notified about them, so I did not get back until now.

You got the points very well. Regarding anchors I really used the same terminology being used in the office software. I mean relative positioning of pictures within the text if the text -spreads over more text frames, -is edited, and -some particular image belongs distinctly to some particular part of the text.

Regarding captions I would like to remind the absenting numbering. To my knowledge it is not possible to use automatic numbering for anything else but pages.

The "swerving" points: It happens if a node is close to an object, for which snapping is activated. I think that snapping should get activated only after a deliberate movement of the mouse, not immediately after clicking on the spot.

One more point I think is important: I did not found the paragraph functionality which is common for the office software: keeping lines together (preventing only one line to perform on a page end) and keeping with next (binding chapter heading with the text of the paragraph).

Kind regards!


Quote from: GarryP on November 11, 2014, 02:31:35 PM
In MS Word the text is the "base" of the document and images are inserted into it. Essentially, the text in Word is the document and everything else moves around it. But in Scribus the "base" of the document is nothing, just a placeholder to add stuff to, so an anchor would have to be in a text frame - which can be chained - and I wasn't sure that the same concept would work properly.
Even MS Word has text frames (though most people don't use them, I'm not sure they can be linked), you can anchor a frame to text in another frame.

The feature is useful for example for situations like those I mentioned:

- Margin notes
- Screen captures (in "how to" texts for software)

If course there will be situations where the placement will become wrong, for example if text frames of different width are linked. But in most cases I think the feature will be used with same width frames.

The anchor should be a "point" (not a line). In Word I think that when it's inserted into a text it behaves as a zero width glyph (and the logical "point" would be on the text baseline for the line where that glyph is located).