Scribus has a serious flaw, one that limits its practial 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. TeX solves this problem by storing a limited amount of specifics in memory, then processing a text file a line at a time when asked to transform the document into a final form. Of course TeX is not WYSIWYG, handles illustrations clumsily, does not use layers with any degree of handiness etc. A TeX run resembles the compilation of a program. I don't have an answer for the problem. Perhaps each page could be stored separately in a keyed database and then be called up into memory as requested. But if the processing of book length projects remains a process of extreme awkwardness I see a limited role for Scribus in my activities. Perhaps a user who successfully prepares book length documents, 100 pages or more, could write a tutorial describing his/her methods, that would help. My own current planned workaround is to process a single page or two facing pages, add page numbers manually, save that mini-document in pdf form, and then use something like pdftk to combine the pages. This will exacerbate the other serious flaw in Scribus, excessively long pdf files. As Yul Brinner said in "The King and I", "Is a puzzlement." Thoughts? -- John Culleton Wexford Press Book layout, typesetting and Indexing Free list of books for self-publishers: http://wexfordpress.net/shortlist.html
