[scribus] Long Document Preparation Workflows

[Aaron W. Hsu]

On Sun, 10 Jan 2010 08:56:25 -0500, avox  
<avox at arcor.de> wrote:

> what keeps us from changing it is lack of time and the scope of the  
> needed
> changes:

Looking at the list below is indeed daunting. I wonder, however, whether  
all this is really required.

> 1 implement character styles (done)

Yes, this is pretty important, and you have it now.

> 2 separate the drawing logic from the layout logic (done, but will get a
> rework)

I don't know what exactly this means, but I guess if you say so. :-)

> 3 change the way characters, styles and layout information are stored  
> within
> Scribus (currently it's all stored per character, and each story has a  
> very
> long list of characters)

This isn't really important for managing the book, but mostly for making  
the performance of Scribus good enough to handle the entire book as a  
single file. This does not matter to me as much.

> 4 implement some XML-like structure for text which will allow to store
> elements for chapters, references, index markup etc.
> 5 implement index, TOC, references in Scribus
>
> Tasks 1-4 involve a major refactoring of the Scribus code base, so it's
> nothing you can do in a weekend.

Well, now here I wonder whether this is actually required or not. We do  
already have tools, either via word processor or the like, that are able  
to automatically track these things, and produce "marked up" text from  
them. Assuming that the word processor uses paragraph and character styles  
to mark up the TOC and such, then we can use an external tool to manage  
these things. In fact, if you only do this once, and don't change anything  
outside of Scribus once the pieces have been added, then you can do big  
books using just these tools.

However, the problems comes in when you want to modify the text. Because  
you can't re-import in a non-destructive manner a revision of the text,  
you can't use those automated external tools to handle your ToC if the  
revision alters too much. Additionally, the character styles and paragraph  
styles are not retained upon a re-import. This is, IMO, the bigger issue.  
If, instead, you were able to simply revise the text from an external  
source (track its modifications, as it were), then you wouldn't need to do  
either 4 or 5, I think.

This would require being able to import styled documents either from a  
word processor or a text editor that could keep track of the styles,  
including Character styles.

> About priorities: Scribus is mainly a layout program, not a content
> production program. So the main priority is to combine images and text  
> from
> external sources and produce a printable PDF from it. Text editing
> capabilities will always be more limited than in a word processor, just  
> as
> Scribus doesnt have the image editing or vector editing capabilities of  
> Gimp
> or Inkscape.

I am all for Scribus staying focused on what is its purpose. That's why I  
think something like the above would be more suited to Scribus, since,  
indeed, there is no reason why Scribus needs to do everything that a word  
processor can do.

	Aaron W. Hsu

-- 
A professor is one who talks in someone else's sleep.