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

List:       koffice-devel
Subject:    Re: Saving Unknown ODF Elements
From:       Thomas Zander <zander () kde ! org>
Date:       2008-09-24 10:51:31
Message-ID: 200809241251.31839.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 24. September 2008 12:03:21 Johannes Simon wrote:
> Hi,
>
> Yesterday, there was a short discussion on IRC about document roundtrips
> between OOo and KOffice. Obviously, both office suites don't have the same
> set of features. So when we load a document saved in OOo, and it contains
> ODF elements that we have no support for, it is not always clear how and
> weather they should be saved back to ODF. This of course applies to
> documents from any other office suite, too.
>
> In KOffice 1, we had kounavail (not sure, is there such a thing in 2.0?) to
> save unknown embedded objects back to ODF, with a visual representation of
> it in the document as well, to at least remind the user that there is
> *something*. Obviously, this only works for independent "stand-alone"
> objects. Now if we have unknown objects that are more intertwined with the
> rest, this is a little more difficult. As a simple example, a z axis in a
> chart can't currently be visualized, but we sure can "just save it back to
> ODF". If we save it, we won't lose data, but if we do, we save something
> that the user might not even have been aware of in the first place, and not
> even wanted to be there.

Lets separate the issue into different ones;

a) There is a specific element or tag inside odf our software doesn't support, 
but is know to ODF. Simple example is text rotation, which is a text style 
item.
b) There is a component we don't support, a component like a 'chart' or an 
embedded image in a certain format we don't know, but is specified in ODF.
c) The input XML contains tags or elements in an unknown namespace, which 
means that this content is not in the ODF spec at all. We have no way to know 
what we do with this and ODF explicitly says we are allowed to loose these on 
load/save. (I'm not saying we should, though ;)

> I know there exist various different opinions on that matter, and I just
> wanted to see if we can agree on a certain policy here. I see 4 possible
> solutions to this as long as we don't fully support ODF:
> 1) Don't save anything back that can't be visualized
> 2) Save back as much as possible
> 3) Leave the decicion to the component that should have loaded the ODF
> element (like the chart shape in the example mentioned above).
> 4) Tell the user that there was something that couldn't be loaded (likely
> to be a list of elements, and rather something human-friendly than XML),
> and ask what to do.

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.

Cheers!
-- 
Thomas Zander

["signature.asc" (application/pgp-signature)]

_______________________________________________
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]