Recent posts

#1
General Discussion / Re: May 2026 - Mid July 2026
Last post by AdmFubar - July 23, 2026, 09:54:55 PM
it's like getting a whole new program!
the developers certainly have been busy.
#2
General Discussion / Re: Hello!
Last post by a.l.e - July 23, 2026, 07:52:43 PM
Good luck with Scribus!

If you need help, don't hesitate to ask.

And, when you're done with the issues (or give up with Scribus), please share with us, how your experience was!
And, if possible, some screenshots of the results.
#3
General Discussion / Re: May 2026 - Mid July 2026
Last post by a.l.e - July 23, 2026, 07:42:59 PM
This post contains commits up to July 22.

It already happened since the last post:

  • ...

Open tickets with pending patches:


Tickets with "simple" tasks:

Scripts to be created
#4
General Discussion / May 2026 - Mid July 2026
Last post by a.l.e - July 23, 2026, 07:41:06 PM
Things are happening in Scribus!

First, there were multiple advances in the support of RTL languages!

The big news is that Scribus now supports RTL page binding:

rtl-binding.png

On top of it:

  • Tabs and margins now work correctly for RTL paragraphs.
  • Drop caps also work for RTL text.
  • The same for lists.

I would dare to affirm, that now Scribus starts to be usable for RTL documents.

Much progress (and effort!) has also happened for the tables: they are much better now!
Personally, I'm not sure that they are ready for prime time, but they are now at least usable.

I think that Scribus could profit from some real world use cases to check how well the features that have been implemented up to now cover the users needs.
It would be wonderful if Scribus users could post examples of tables they need or want to achieve with Scribus!

In brief:

  • The tables handling has been modified to be more similar to LibreOffice.
  • Many (many!) features have been improved or added, and small bugs have been fixed
  • It's also possible to copy paste tables from LibreOffice Writer and Microsoft Word (you need to paste the table inside of an existing Scribus table).

A "work in progress" is worth being mentioned (because you might see it, when you start your new version of Scribus)

A new "First start" dialog has been created.

first-start.png

It's not (100%) working yet, but it will allow the user to go through the most common setup steps, when first starting Scribus.

Some smaller changes:

- In the render frames, the docDir allows to set the target folder for the document.
- It's now possible to select all the frames in a linked text frames chain.
- A new Scripter command has been added for checking the result of the Preflight Verifier.
- In the Scripter, two new commands allow long running Python commands while keeping the UI responsive: invokeLater() and processEvents().
- The rendering of Drop Shadows is much faster now (more improvements might come later)

Enjoy your summer!
#5
Beginner Talk / Re: Help me understand the doc...
Last post by AdmFubar - July 23, 2026, 06:18:29 PM
Dunno if the panning should be infinite. There was a user with a problem .sla here a few weeks ago that i tracked down to a an object that was located way off the page. The object co-ordinates were rewritten from damage to the .sla (most likely)  this type of issue needs to be addressed to mitigate problems with a document. an option to limit panning and object placement.

Maybe to pan infinitely, limit the placement of objects off the page to a reasonable distance, a definable scratch space, or better yet the scratch space  as a window that you can drag object to or from.
#6
General Discussion / Hello!
Last post by F6EEQ - July 23, 2026, 11:19:49 AM
Hello from a former MS Publisher user trying to switch towards Scribus.
I'm editor of a small ham radio magazine and my goal is to get the new issue (october or november) entirely made with Scribus.

Have a nice day
Gerard
#7
Beginner Talk / Re: Help me understand the doc...
Last post by a.l.e - July 23, 2026, 09:33:49 AM
For some reasons, we don't have infinite panning in Scribus.

I have no idea on why it is so, but it might have technical reasons.

From a usability perspective, I'm not against limiting the panning area.
In Inkscape it already happened to me, to have landed in an "infinite" spot and it's a pain to get back to my work.
I guess that there must be a shortcut to make the content fill the monitor, it's probably a simple one like 0, 1 or = ... but in the stress situation of being nowhere, I never had the idea to look for it (or try out one of the most obvious keys).

On the Scribus side, the current panning limits are... very limiting and I use the same workaround of putting some fake objects in the far outer area (but never thought of first massively zooming out: I will try to recall the trick, the next time I need it).

One thing for sure: the current limits are very often in the way and should be relaxed.

Not sure I'd want to have an infinite panning.
One simple rule that might be good enough for me: it should be possible to pan the item on the "opposite side" until it almost disappears.
In other words: the limit for panning on the left side of the window would be the right side of the right most item in the page, in the document, or in the current viewport (using the document as a reference might be the easiest to implement; referencing the viewport might be the most natural for the user).

Any comments?
Better suggestions?

My final suggestion is to add the result of this thread to this existing ticket:

https://bugs.scribus.net/view.php?id=13336
013336: Scratch space should be dynamic instead of being a setting / preference - dynamic scratch space not restored on file open
#8
Beginner Talk / Re: Help me understand the doc...
Last post by Plop - July 20, 2026, 11:33:43 PM
You're absolutely on to something : adding two "forced bounds" objects (at the far upper left and far lower right) definitely unlocks to the panning limits in both directions. Very interesting, and that certainly answers part of my initial question about understanding the current behavior. Scribus feels all smooth and modern now :D


Now of course this is just a workaround/proof of concept for a more free pan behavior, as I suppose that keeping such out of bounds objects in a work file isn't the greatest idea. This thread wasn't meant to be taken as a request anyways, as I understand that these things are far from trivial.

Now all that said, the issue of getting the document view stuck off-center after using scroll zoom to cursor remains. Sure enough this must be affecting other users as well.
#9
Beginner Talk / Re: Help me understand the doc...
Last post by AdmFubar - July 20, 2026, 11:09:21 PM
i think i figured it out just now, there might be a "limit" as there isnt any object off the page., add an object and drag it to the left or right, drag it past the bounds of the view window.with the object sitting past the window view, pan the view, you should see the space for the slider extend  as the object is dragged past the view. (will be noticeable when dragging off to the right) does scribus now pan when you move the slider?
#10
Beginner Talk / Re: Help me understand the doc...
Last post by Plop - July 20, 2026, 10:11:40 PM
Hello ! Thank you both for chiming in, this is appreciated.

@AdmFubar my current values for Preferences > Operator > Zoom are :
minimum : 1%
maximum : 500%
Stepping : 15%

Zooming itself is not the issue as the software lets me zoom in and out just fine (using a combination of the two zooming methods available). The issue I am running into relates to the panning of the resulting document view, as I am constantly hitting some unexpected and seemingly arbitrary bounding edges on the left and right side.

Here is some more footage clearly showing the issue. If you look at the mouse cursor (hand) you'll notice that the panning stops even though I keep dragging. This is consistent with the representation of the horizontal scroll bar at the bottom of the screen of course.


Therefore, a different way for me to formulate the issue would be : how does one edit the range of the horizontal scrollbar of a given document ? This has to be defined somewhere. Also you'll notice that in the footage above I somehow ended up with the document stuck off center.

Now if this panning range isn't defined by some value, one would then assume that it relies on math to adjust/normalize things dynamically. If so, my guess would be that the current implementation of zoom scroll to cursor is probably the culprit here, since zoom-scrolling to cursor is specifically the one mean through which one can get "out of bounds" of the scratch space, so to speak.

@MrB This is case of personal preference of course, as nearly all design software allow for either a very wide or even infinite range of the document view panning - be it Photoshop, Inkscape, Krita, MOI3D, Autocad, FreeCAD, and so on.

Now if I were to attempt to justify this personal preference I'd say that being able to have the most free, unrestricted birds eye view on one's work and the ability to pan around a complex document freely allows to spot things to change or fix very easily. It's a review tool.

BTW I should probably mention that I am on Win10 x64, using Scribus 1.6.6.