John Jason Jordan wrote: > 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.
OK - I'm not a Scribus developer, but if I were, I imagine that would give me some clues. If the problem lurks with the innards of Qt there may not be much they can do about it I guess, but at least using the keyboard short cuts can be made known as a quicker way to navigate around Scribus. Out of interest, in terms of the check list I suggested above, what are you using ? I've lurked on this list for couple of years and I think it's the first time I've seen this described. It's good to know. > 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. Not my call, but the developers seem to have a very sound approach. Cheers, J/. -- John Beardmore, MSc EDM (Open), B.A. Chem (Oxon), CMIOSH, AIEMA, MEI Managing Director, T4 Sustainability Limited. http://www.T4sLtd.co.uk/ Energy Audit, Carbon Management, Design Advice, Sustainable Energy Consultancy and Installation, Carbon Trust Standard Registered Assessor Phone: 0845 4561332 Mobile: 07785 563116 Skype: t4sustainability
