> Date: Fri, 12 Jun 2015 08:22:15 -0400
> From: John at wexfordpress.com
> To: scribus at lists.scribus.net
> Subject: [scribus] Scribus and long documents.
>
> Scribus has a serious flaw, one that
> limits its practical utility to short documents.
> This is not a flaw susceptible of a quick fix, or
> even a slow fix.
>
> A book length document of 100 pages or more
> slows the program down to a point that is not
> tolerable. If one breaks down the document into
> ten page segments then problems occur in page
> numbering, the TOC, indexing and so on.
Could you post a sample document?
It might be possible to build a version of Scribus with gcc -pg profiling to
have an idea of what is happening.
If you double the number of pages, is the slowness predictable? Does it get
twice as slow or four times as slow?
Are the 100 pages all linked text frames so that any change to the first page
requires recalculating everything through to the last page?
Is the book divisible into short chapters so that the text frame on the last
page of one chapter does not have to be linked to the text frame on the first
page of the next chapter?
I'm not a Scribus developer, but the solution might be changing the display to
recalculate only currently visible pages. Many laptops and PCs now come with
16GB of RAM, so memory should not be a problem. It might be possible to store
the starting layout state of each page as the page is processed, and then when
you modify a page, the recalculation could run from the page that you changed
forward to the last visible page on the screen and mark the remaining pages as
currently uncalculated (or queue them for recalculation on a low priority
thread).
Regards,William
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.scribus.net/pipermail/scribus/attachments/20150612/884bc4a7/attachment.html>
