[scribus] Long Document Preparation Workflows
avox at arcor.de
Mon Jan 11 22:39:41 CET 2010
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
> 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
> 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
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
>> Scribus (currently it's all stored per character, and each story has a
>> 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
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.
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.
More information about the scribus