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

List:       koffice-devel
Subject:    Re: koStore tweaks needed? (long)
From:       David Faure <david () mandrakesoft ! com>
Date:       2000-11-07 12:40:05
[Download RAW message or body]

On Tuesday 07 November 2000 09:42, Shaheed Haque wrote:
> Hi all,
> 
> As I get deeper into the implementation of embedding support in the msword 
> import filter, I am coming to the conclusion that koStore is not quite 
> right. This is clearly not a good conclusion, so all comments/clarifications 
> are welcome!
> 
> Background
> ==========
> 
> Following the discussion in
> 
> http://lists.kde.org/?l=koffice&m=96700836803094&w=2
> 
> I implemented a slot in the OLEfilter that allows the msword filter to 
> invoke (for example) a killustrator import filter to handle WMF files. This 
> works fine except that in the general case:
> 
> 1. The result of invoking an arbitrary filter is not a single XML file, but 
> a koStore that could itself contain a maindoc.xml and several parts - think 
> of a WMF (killustrator object) containing several bitmaps (krayon objects).
> 
> 2. There is no general solution to the multiple documentinfo problem 
> referred to in the original thread.
> 
> Object embedding - current status
> =================================
> 
> Basically, koStore handles the top level document very differently than 
> embedded objects. Thus:
> 
> - the top level document is called maindoc.xml
> 
> - the top level document can have an associated documentinfo.xml
> 
> - parts embedded at the top level are stored at the top level (e.g. as 
> part0.xml) and can have an associated directory (e.g. part0/) for second 
> level objects.
> 
> And so you end up with things like this:
> 
> maindoc.xml
> documentinfo.xml
> part0.xml
> part1.xml
> part0/part0.xml
> 
> This works fine for the OLEfilter case, where the OLEfilter infrastructure 
> creates the overall koStore from the contributions of individual 
> msword/msexcel etc. subfilters.
> 
> Now, imagine what happens when an import filter (while creating maindoc.xml) 
> decides it has to invoke another completely separate filter which creates a 
> complete koStore (with another maindoc.xml). In order to combine these two 
> koStores, all the files in the second koStore must be renamed and 
> reorganised (maindoc.mxl becomes partN.xml, and everything else has to be 
> reshuffled under partN/). And there is no obvious place for the second 
> documentinfo.xml.
> 
> This is a pain.

This naming scheme was designed to look better to the user. But from the program
point of view, you're not supposed to see such URLs. Internal urls in koffice,
for historical reasons are, for the document above,
root
tar:/0
tar:/1
tar:/0/0
That conversion is done in KoStore::toExternalNaming.

We could make "tar:/" an alias for "root" if it helps, and this way you can have a unified
naming, which should help merging things.

However I agree that "documentinfo.xml" isn't taken into account by this,
and that your proposed change makes sense. I think we opted for "part0.xml"
to avoid subdirs with a single file, but this turns out to be quite stupid indeed,
especially given that dirs take no room in a tar file.
I'm just not sure that introducing changes to the storage layout are a good idea
at this point (it would certainly discourage writers of koffice import filters for other
office suites, and it means more compatibility code in koffice), if we can avoid it. 
Does using internal names instead of external ones help ?


About pictures, I definitely prefer if they are under a subdir. For instance in a
kpresenter file, they tend to come in huge number, so better have them separated.
(Less mess when untarring a file).

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://www.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today
See http://www.kde.org/kde1-and-kde2.html for how to set up KDE 2
_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel

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