[scribus] Long Document Preparation Workflows

[avox]

Aaron W. Hsu wrote:
> 
> 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. :-)
> 
> 

Imagine a single procedure of 2500 lines in length that is responsible for
laying out text 
and drawing any type of page item (incl. selections, framehandles and
wireframe). 
Don't imagine code comments. 
Now try to change anything related to text - no fun!



> 
>> 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.
> 
> 

Hm, signal #6 exceptions, or layout times that increase with the square or
the cube 
of the text length don't matter to you? ;-)

> 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.



That's exactly why 4 is needed: 
Otherwise there is no way to store the needed information in Scribus. And
once we have 4, 
step 5 becomes easy (= fun).

The way I want to implement 4 is that it will be possible to store texts as
external XML files 
and do style-aware round-trip editing inside and outside of Scribus.
Basically you will be able 
to use any XML+CSS tool for external editing; and Scribus will just add a
few XML attributes 
for the stuff that isn't covered by CSS. 
And yes, we wouldn't need 5 anymore, but it would be nice to have these
features for users 
that dont want external editors.

/Andreas
-- 
View this message in context: http://old.nabble.com/Long-Document-Preparation-Workflows-tp26987075p27118250.html
Sent from the Scribus New mailing list archive at Nabble.com.