Display issue when modifying an object's shape or its position

Previous topic - Next topic


Hello guys,

I'm relatively new using scribus and there is an issue I face from the beginning. I could overcome it but today it's impossible.

So, when I'm moving the position of an object (by entering new coordinates, using settings after right-clicking on it), scribus display goes full on the left and I'm not able to see the page anymore. I have to zoom out and zoom in again to find my page back.
ex: I press enter after entering the new coordinates for an object, and the display is now centered at x:-700, while my page begins at 0. (but my object is well positioned on the page, this is just a problem of display)

the same thing is happening when I try to move the position of an object's point (to modify its shape). As soon as I select the point and drag it somewhere else, the display change and move to the left (like x:-150) and it becomes impossible to drop the point where I want to (unless I zoom out a lot but I loose all the precision).

Is there a possibility to "lock" the display so that it doesn't change automatically? Sorry if this question has already been answered before, but I didn't find help in the users guides or a topic on this forum that mentions this.

Many thanks,



hi zoulouzoo

i'm not able to reproduce your problems here (macOS 10.11.6/scribus 1.4.6 and 1.5.2) – but you should always mention your os and scribus version.



Hi Utnik,

Sorry my bad! I'm working on Windows 8.1 with Scribus 1.4.6.

After reading my message, I should add more info:
-It also happens when I delete an object
-It also happens when I modify objects on master pages
-At some point I moved some objects on the left side of a page (out of the page to be precise like x:-200)
-It only happens when I zoom at 80% or more (40% zoom also when it comes to drag and drop points of an object to modify its shape)
-It doesn't only happens with one document
-And cherry on the cake, sometime this issue doesn't appear haha  :-\

Thanks for your answer, also don't hesitate to ask me to provide screenshots (I can even record a short video to show the problem if necessary) or to reformulate some sentences, english isn't my native language.



My first suggestion - not really related to the issue - would be to keep the Properties Palette open all the time rather than opening it via the contextual menu (right-clicking). This saves a whole lot of time.

I tried to replicate the problems on Win 10 Scribus 1.4.6 and couldn't make it do what's happening to you. I've never seen Scribus do the things that are happening and I don't know of any "option" that could have been accidentally changed that would force it to do so.

It sounds like you might have a corrupted application. I would suggest that you uninstall Scribus, download a fresh copy from here https://www.scribus.net/downloads/stable-branch/ and try re-installing it again.

That might not work but it's an easy thing to try.


Hey GarryP,

Thanks for your answer, I will reinstall scribus and will try to replicate the problem. I will update this thread when it will be done.

Until then take care guys,



in my experience, reinstalling scribus has (almost) never solved an issue...

what could help, is resetting the user preferences (this is normally not part of reinstalling, afaik): sadly, i don't know how to do that on windows... but i'm trying to find out (does anybody around here know it?)

also, it might be that your document is somehow broken...

... but -- after having said all the worst reasons that could trigger that odd behavior -- from what you are describing i fear that i recognize what i've experienced with scribus last week...
sometimes, the frame i was working on disappeared from the visible area and i could not scroll to it. only after having zoomed in and out, i could continue my work...
is it what it's happening to you?


Reinstalling isn't usually the solution but it's cheap to do in terms of time and effort. Even with the reliability of today's storage systems there's always the chance that a random stray bit has been toggled.

For example: If there's some compiled code that boils down to a "SAL 1" instruction (essentially, multiply by two) and if one single bit in the "1" value is toggled - say bit 2 - then it could be changed to a "SAL 5" instruction instead (multiply by 32, I think). The software wouldn't know any difference but the user would definitely notice it.

As you say though, it's probably not that which is the problem but it's nice to know that the user has a good clean version of the application so you can discount that as being the problem.

I didn't think the solution would be in the preferences file as I couldn't think of a preference that would make Scribus do what the OP described. (Unless there's a "move_stuff_around_at_random=true" setting in there somewhere!)

On my machine, the prefs140.xml file is in C:\Users\<username>\AppData\Roaming\Scribus
Zoulouzoo, rename this file to force Scribus to create a fresh one (as it does when you first run it).

If a reinstall and a new preferences file doesn't work then, as you say, it could well be the document that's at fault but someone with way more experience with the XML than me will need to look at it.


QuoteReinstalling isn't usually the solution but it's cheap to do in terms of time and effort. Even with the reliability of today's storage systems there's always the chance that a random stray bit has been toggled

On the one hand, you're perfectly correct.

On the other hand, I notice that telling people to do things that are not really related to the issue, increases their feeling that the computer is a black box that does strange things.

their confidence sinks and they start getting stuck each time something unexpected happens.

there are no best practices on this, just preferences :-)


Users generally don't want to know what's gone wrong, just how to get things working and how to stop the problem from happening again. They don't want to know that, for instance, a specific attribute is not being properly updated when a certain exception is thrown (or whatever), they just want to know that they shouldn't press this button straight after selecting that menu item. It's more of a case of "I just want to use the thing" rather than wanting to know how it works.

By way of analogy (yes, I love my weird little analogies): A driver just wants to be able to drive their vehicle. If second gear is difficult to engage then they'll rev high in first and change up directly to third gear missing second altogether. They don't want to know about synchromesh or whatever, they just want to be able to drive and they'll do whatever it takes to do so.

I think it would help with problem reporting if Scribus had some kind of "core dump" function. It wouldn't need to be anything sophisticated, just something that can be called that "pings" each active class/object to generate a text dump of all attribute/variable contents. It would give the user something they could attach to a ticket that the developers could use to see the current state of the software as it is running. A developer could then scan the dump for any value that looks wrong as a quick check of the "sanity" of the application.

Something like:

  Name : untitled.sla
  UOM : Points
  Page Size : 200, 280
  etc. etc.
  Type : Rectangle
  Position: 20, 40
  Size : 100, 50
  Line Width : Hairline
  etc. etc.
  Type : Text Frame
  Position : 200000, 100
Developer: "Oh, that 200000 doesn't look right". That sort of thing. It doesn't say what the cause of the problem is but it's a pretty cheap way of finding out information that's otherwise hidden.
Anyway, it will be interesting to find out whether a clean installation or a clean preferences file actually fixes the problem. Neither would help to find out what went wrong but it would get the user back on track and, as I mentioned earlier, that's pretty much all they want.


I for one would like to see a screen vid of it, I have a hard time visualizing problems and seeing them really helps.  I also cannot duplicate it Mac OSX 10.9, Scribus 1.5.2, but I could not be understanding the problem correctly.



mnawij, the OP said that they'd be happy to supply a video so that might make things much clearer (as long as they cover the whole screen so we can see everything they can see).

So far we've had:
* Win 8.1, Scribus 1.4.6 - Problem
* Win 10, Scribus 1.4.6 - Not Able To Replicate
* OSX 10.9, Scribus 1.5.2 - Not Able To Replicate
* OSX 10.11.6, Scribus 1.4.6 - Not Able To Replicate
* OSX 10.11.6, Scribus 1.5.2 - Not Able To Replicate
* Whatever a.l.e is using - Might Have Seen Similar

No reports from Linux users yet but I've used various Scribus versions on Mac, PC and Linux and never seen what the OP is getting. It's a strange one.