[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Faster saving
From:       David Faure <faure () kde ! org>
Date:       2004-04-13 21:53:45
Message-ID: 200404132353.46559.faure () kde ! org
[Download RAW message or body]

Hi Nicolas,

I was about to refute your arguments by using the OASIS spec,
but it turns out that you are correct. It defines that automatic styles
must come before the body. I got confused because office:document-styles
also can have automatic styles as children, but it says those are 
"for the named styles".

BTW the current draft of the OASIS standard is available at 
http://www.oasis-open.org/apps/org/workgroup/office/download.php/6032/office-spec-1.0-cd-1.sxw
(I think that URL doesn't need authentication).

OK, so automatic styles must come out before the body.

But that doesn't mean we have to write out the body first and then come back.
We can also iterate through the paragraphs, and for each (parag/character) style
we find-or-create an automatic style (and store its pointer in the KoTextFormat/KoParagLayout),
then we can write out all the automatic styles, and finally we can write out the
text contents (framesets/paragraphs), using the same automatic-styles names.

In fact this is already done for character styles, they are already "factorized"
in KoTextFormat[Collection]. We simply need to implement a similar 
"collection" for paragraph styles, which would be a very good thing to do,
to reduce mem consumption anyway.

Then we would have to assign a name or a number to each format/autostyle
in the collection, and use that both when saving the formats and when
referring to them when saving the text.

That's the difference with file-to-file export filters. In KWord (kotext) we already
have (for kotextformat at least) collections which factorize the common
formats ("automatic-styles" in OO terms).

Anyway, this doesn't solve the question about the best way to implement saving.
It's just that I think we can choose a solution which doesn't allow "going back and adding
a tag before another one". All we need is to save things in the right order; after all
everything we need to save is in memory already.

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]