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

List:       koffice-devel
Subject:    Re: Saving Unknown ODF Elements
From:       Johannes Simon <johannes.simon () gmail ! com>
Date:       2008-09-24 12:04:46
Message-ID: 200809241404.47206.johannes.simon () gmail ! com
[Download RAW message or body]

Hi,

On Wednesday 24 September 2008 12:51:31 Thomas Zander wrote:
> I think we will have different solutions for different problems. Each of
> the 3 issues (a, b and c) I pointed out will require different code paths
> to solve it and especially point (a) will require a solution in each of the
> major modules. Like text, paths, etc.
>
> In the text module what I designed is that we have all of the properties
> ODf knows about and we load *all* of them into memory using hash-maps. This
> means we don't loose anything on load/save as long as we implement
> everything there.
> A completely separate issue is actually providing support for the features
> which in a lot of cases we don't do yet.
> So, the not-so-long term goal of kotext is to have no loss of features on a
> roundtrip.  (note that OOo doesn't manage this by a longshot).
>
> This covers just one module and is about issue (a). I would like to see
> similar solutions for all the other modules.
> For issue (b) I think we should go for your solution 2. Which implies we
> would need a kounavail like shape that just stores the xml that is would
> save out later.  But this can wait till 2.1
>
> In my humble opinion issue (c) would be answered with '1'. Unknown items
> simply should be ignored. Especially since ODF 1.2 introduces meta data
> which makes it just sloppy to use those for anything else than just one or
> two attributes that are specific to one office app.

I agree with you on issues (b) and (c). For (a) however, not losing data on a 
roundtrip is not necessarily a good thing. The original author of the document 
saved in OOo is not always the one opening it again in KOffice. It might simply 
be a template from kde-files.org, or a similar resource. In that case, it does 
not make sense to preserve ODF elements that we have no support for, because 
the user is not even aware of them. The text rotation example you mentioned 
would have a tremendous effect on the resulting document, as it will completely 
change the visual appearance of it when it is opened again in OOo. On the 
other hand, if the author is the same and aware of these ODF items (or rather, 
their effect on the document) because he is the one who added them in OpenOffice, 
it *does* make sense in most cases to save them back. That is why, in my 
opinion, your solution to (a) should only be applied in conjunction with the 
users agreement.

- Johannes

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic