[Scribus] The layout of books or large documents with Scribus --Workarounds!

[Craig Bradney]

> ----- Original Message -----
> Subject: Re: [Scribus] The layout of books or large documents with Scribus
--Workarounds!
> From: Axel Bojer <axelb at skolelinux.no>
> To: scribus at nashi.altmuehlnet.de
> Date: 24-01-2007 11:45
> 
> 
> Axel Bojer skrev:
> > Axel Bojer skrev:
> >> Hello!
> >>
> >> I am currently struggeling with a book theh I am trying to set up
nicely 
> >> with Scribus. After having made the switch to Scribus for Broschures
and 
> >>   a magazine I am now experiencing all kinds of drawbacks with the book

> >> I am working on. In the hope of getting some good tips I am now making 
> >> this summary. Perhaps it could be used in the online manual or as a 
> >> separate tip page, I have not seen one that goes in depth about this.
At 
> >> least it would be welcomed if users experiencing--or working--with
other 
> >> big documents in Scribus could share their experiences.
> (...)
> > Here are some issues I found:
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> (...snip a lot of errors, see former post or the shortened list at the 
> end of this post)
> 
> > Is there an easy way to collect two or more finished documents into one?

> > Hopefully without having to edit the resulting file afterwards :-)
> > If yes I may give it a try ...
> 
> I have tried the import page-function, but the links are no tkept, which 
> makes it cumbersome, pratically nearly impossible, to change the text 
> afterwards. I also tried to copy the content of one frame over to the 
> other, but then the stylees are not kept. The only thing working is:
> * Keep only the first frame (unlik between the first frame and the second)
> * Send to clip board
> * Paste somewhere else
> 
> Of course I then have to redo my linking, too, but at least I don't have 
> several unlinked frames with parts of the same text in it.
> 
> Concerning the lack of performance:
> I have (through literally *days) reworked the whole 150 page document 
> the following way:
> All articles are kept as seperat chained links. That means not in one 
> unbroken chain all the way thrpugh the 150 pages, but perhaps the first 
> then (article 1), then the next 12 (article 2) etc. I have also split it 
> in two part, one 100 pages long, the other 50 pages long.
> 
> This has improved the speed so radically that I want to make this a tip 
> for other struggling with the same problem. Before I could have to wait 
> half an hour or more just for the document to open, now it opens in 5 
> minutes (still not lightning fast, but usable).
> When the text in a linked frame is smaller the Story editor also works 
> normal--normally no delay, with some exceptions:
> * Applying styles can still take 1--5 minutes to finish (depending on 
> the length of the applied paragraph I think)
> * Copy and pasting of even short text part into a frame chain with much 
> text in it already also takes about 2--5 minutes to complete. In empty 
> frames or frame chains with little content in them, this works without 
> delay.
> 
> This is still not ideally, but with this method I can live with it and 
> do my work, some waiting is still necessary, and big style changes or 
> copying/pasting many times is unpractical still. I you use 
> OpenOffice.org to do the styling and import the finished document, this 
> should not be an issue though. It could even be faster to rework the 
> changes in OOo and then import anew. Of course manual cerning or other 
> tweaks will still have to be redone, but this is fast enough to do to be 
> manageable. Sadly the import function for OOo is not perfect either, so 
> some formatting may be lost, I discoverd italics disappearing at least. 
> And the styles may be diversed (not all text snippets may keep their 
> style, even if you choose not to merge styles). But mostly this works.
> 
> When I have all my present delayed work finished I may make a wikipage 
> on the use of big documents (or someone else may use this as a starter 
> for one). I think I have the main things covered here now :-)
> And hopefully most, or all, og these bugs will be fixed in 1.3.4, I am 
> waiting eagerly for a production version of it to appear, maybe later 
> this year?

You should see a beta release in the next week or so for 1.3.4. 1.3.4 will
not solve all of the speed issues however the first stage of the new text
engine is in and has made a large difference in some areas for text.

Regards
Craig