[scribus] Scribus Limits, Present and Future

[John Jason Jordan]

On Mon, 10 Aug 2009 14:04:22 +0100
John Beardmore <John at T4sLtd.co.uk> dijo:

> John Jason Jordan wrote:
> > On Fri, 7 Aug 2009 11:45:01 -0400
> > John Morris <johnjeff at editide.us> dijo:
> 
> > This is the first long document I have done in Scribus. In the past I
> > have done textbooks in InDesign on Windows 2000, up to 550 pages.
> > InDesign ran as fast with a 550 page document open as it did with a one
> > page document open. I have also used PageMaker, QuarkXPress and Ventura
> > previously and never had an issue about slow speed when working on long
> > documents.

> It really would be good to know what makes Scribus slow 
> down in big documents and assay what various people have managed easily 
> / got away with.
> 
> I suppose until 1.3.5 is released, there isn't much point in comparing 
> experiences in detail, but maybe once 1.3.5 is out we should all 
> contribute the following information for our larger projects ?
> 
>      Processor
>      RAM
>      Document number pages
>      Page size
>      Average number of linked text frames
>      Maximum number of linked text frames
>      Numbers of characters in linked text frapmes
>      Which operations in Scribus are least responsive
> 
> This isn't an issue that's going to go away. Every new user seems to ask 
> it / be concerned about it, and the more precise the answers we can 
> give, the better prospective users can decide if Scribus does what we need.
> 
> I appreciate all of the above are rather clumsy metrics and somewhat 
> subjective, better suggestions welcome !  But they are possibly better 
> than the indicators we can generally offer at the moment, which are 
> generally "large", or on a good day, a number of pages of unspecified size.

First, I didn't mean to sound as though I am dissatisfied with Scribus.
Just the opposite - I love it. It's just that all I do are textbooks,
so speed with long documents is more important to me than it might be
for some users.

The document I am working on at the moment is 120 pages with lots of
vector graphics and text frames. But there are no text frame threads
that go more than five or six frames, and there are no bitmaps. It is
painfully slow, but I have found that learning and using keyboard
shortcuts is some help. For example, if I deselect an object by
clicking elsewhere on the canvas it takes ~15 seconds for the object to
become deselected, but if I do Ctrl-Shift-a the object is deselected
instantly. Similarly, right-clicking on a text frame to get the context
menu and then selecting Edit Text it takes 5-10 seconds for the context
menu to come up. But if I do Ctrl-y the Story Editor launches right
away (although it still takes several seconds before it is ready). Just
about every mouse action is slow, yet if I can use a keyboard shortcut
the action happens instantly. 

It would be nice if, once 1.3.5 is final, we can sit back and polish it
up before plunging forward with new feature development for the next
version. It's not just the speed issue - there are quite a few rough
edges that are not show stoppers but could stand improvement.