Version: (using KDE KDE 3.1) Installed from: Debian testing/unstable Packages Compiler: gcc 3.2.3 OS: Linux When saving a spreadsheet from kspread there is an option to use uncompressed XML however when naming said file, it will *always* save it to "maindoc.xml" regardless of what you've typed.
Moving to KOffice as all apps are affected
"This isn't a bug - it's a feature" :) Normally, KOffice applications save a ZIP containing: 1. the XML (maindoc.xml) 2. a preview (IIRC, preview.png) 3. a directory structure containing embedded parts (e.g. KSpread document inside a KWord document) 4. images "Uncompressed XML files" justs dumps all of the above in the current directory, regardless of the filename specified. So it's really a UI bug. I suggest moving the option out of the filedialog since the user is: a) really selecting a directory, not a filename b) saving more than 1 file in just one hit, which is unusual compared to other KDE apps Maybe it should be in the File menu as "Save as uncompressed files in directory..." (or something similar).
Bug owner was never changed despite the move from "kspread" ro "koffice."
I agree with Clarence. This is very confusing to a newbie. The option "Save as uncompressed files in directory..." in File menu can be a nice idea.
I suppose that the definitive solution for this bug will be to use the raw (un-zipped) OASIS file formats. (But it is not sure that they will already be supported for KOffice 1.4, as they are not a priority.) Have a nice day!
Nicolas' answer confused me for a second. He means the "flat XML" format, where everything fits into one XML file, and which KOffice doesn't support yet indeed. However I have a feeling that our "unzipping into a directory" solution is better for CVS usage, since e.g. pictures are in a different file. So if we keep that mode, we still need to fix this bug (by letting the user select a directory instead of a file, where to save).
On Tuesday 17 August 2004 23:03, David Faure wrote: >(...) > ------- Additional Comments From faure kde org 2004-08-17 23:03 ------- > Nicolas' answer confused me for a second. He means the "flat XML" format, > where everything fits into one XML file, and which KOffice doesn't support > yet indeed. Yes, I mean OASIS without packaging, so only as a XML file, where binary objects are coded as base64 and XML files directly integrated (as the OASIS specification allows it, as far as I understand.) > > However I have a feeling that our "unzipping into a directory" solution is > better for CVS usage, since e.g. pictures are in a different file. So if we > keep that mode, we still need to fix this bug (by letting the user select a > directory instead of a file, where to save). Well, the OASIS specification says that the packaging is optional. But in that case everything needs to be in one XML file. I suppose that having pictures outside the XML files would mean having external files in the OASIS document, but this has drawbacks. Also I do not know how much it works with embedded objects. Also I do not see much of a big problem with CVS, as binary files in CVS are a problem while a picture coded as base64 is much less. Have a nice day!
On Tuesday 17 August 2004 23:12, Nicolas Goutte wrote: > Yes, I mean OASIS without packaging, so only as a XML file, where binary > objects are coded as base64 and XML files directly integrated (as the OASIS > specification allows it, as far as I understand.) Yes - it's what OOo calls FlatXML. > > However I have a feeling that our "unzipping into a directory" solution is > > better for CVS usage, since e.g. pictures are in a different file. So if we > > keep that mode, we still need to fix this bug (by letting the user select a > > directory instead of a file, where to save). > > Well, the OASIS specification says that the packaging is optional. But in that > case everything needs to be in one XML file. Hmm, you are right on this. The OASIS spec doesn't really allow the "directory" mode that koffice has... So such "unzipped into a directory" documents would probably not be loadable inside OOo - to be tested... > I suppose that having pictures outside the XML files would mean having > external files in the OASIS document, but this has drawbacks. No, that's not what I meant (see how we do it currently). > Also I do not see much of a big problem with CVS, as binary files in CVS are a > problem while a picture coded as base64 is much less. Well when you only change the title of your presentation, you shouldn't have to check in 100MB+ of image data again. With flatxml you have to, since it's all one big file. With the unzipped-into-a-dir solution, only the XML needs to be checked in. Although... since the images will have their timestamp updated, cvs will have to diff them too, so I guess it might not make a big difference until we fix koffice to not touch unchanged images...
on images: subversion keeps local copies of all files; so diffing those images does not mean network access; and since more and more are moving to subversion (and away from cvs) I think that when KOffice 1.4 is released the 'dont update images when not saved' feature is not really that relevant. on the bug itself: We have heard at various times that a CVS kio-slave was in the works; this would naturally make this bug irrelevant (not the implementation discussed here, just the bug). Anyone have any new info on such kio-slaves?
Correct me if I am wrong, but this bug is in koffice 1.3.x. This is not a bug of cvs version only.
On Wed, 18 Aug 2004 09:20 pm, Raul Fernandes wrote: > Correct me if I am wrong, but this bug is in koffice 1.3.x. You are correct.
*** Bug 109986 has been marked as a duplicate of this bug. ***
Fixed now; will be in 1.6.2. SVN commit 625214 by dfaure: Make it more intuitive to save as uncompressed xml, i.e. as a directory. Filename typed in dialog becomes directory name, unless it ends with content.xml (e.g. when saving a document opened as uncompressed xml). M +15 -7 KoDirectoryStore.cpp