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

List:       koffice
Subject:    Re: KDE does not recognice KWord docs
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2003-09-27 22:37:17
[Download RAW message or body]

On Saturday 27 September 2003 23:48, David Faure wrote:
> On Saturday 27 September 2003 20:25, Nicolas Goutte wrote:
> > It is part of KDE. KZip 3.1 will simply generate "fat"-based data, KZip
> > 3.2 will give "unx" ones.
>
> Thanks guys for this investigation. I wasn't aware of that change.
> (Holger: it seems that this change broke the magic-recognition of KOffice
> files, where the uncompressed file called "mimetype" would have its
> contents at position 38 in the ZIP file).
>
> > No, sure. I cannot remember if KOffice 1.2.x had its own KZip (named
> > KoZip) or not. So I do not know if the change has to be done if KDE 3.1.x
> > or in KOffice 1.2.x.
>
> CVS says that KoZip was part of KOffice-1.2.x indeed. But:
> > But in any case, I am really starting to ask me if for the last
> > KOffice-own file format it is useful to have again a subtle change.
> > However this would mean to force KZip 3.2 to be able to write in the
> > "fat" modus, either on command or simply for uncompressed files.
>
> Yes, I think we shouldn't do something that changes our 'magic'
> recognition: * other projects/tools/etc. might use the magic we had
> previously, this change will break it * are we sure that the new offset is
> always going to be 55? What's between position 30 and position 55? This
> looks more fragile to me.

I do not understand what "fragile" means here. It is the Unix extension. The 
only problem is that there are three kinds of Unix extensions. (The PKWARE 
one with id 0x000d, the InfoZIP old one with id 0x5855, the new one with id 
0x7855.) KZip seems to have chosen the old one and does not support the other 
two, not even at read.

But the biggest problem is the magic. Whenever you will use zip for example in 
a script, you will get other extensions depending on OS. (NTFS extension, the 
Unix ones, etc) It might also depend on other extensions like certification 
and on comments. Therefore the goal of scriptability is not met with a fixed 
magic. (Good, we have magic and we cannot really change it.)

(I am sorry that my idea of having the mimetype not as file name but as file 
content is backfiring. However with MS-DOS 8+3, we are quite limited.)

> * OpenOffice.org uses the "fat" format in ZIP files, and the whole point of
> switching to ZIP was to use the same thing as they do, and particularly
> having the same kind of magic mimetype recognition.
>
> So we need to fix KZip to give us "fat" format again. Holger: do you know
> if that's easily doable? Is there any benefit in the "unx" stuff? Should
> just move "back" to fat, or should we add a method to choose the format?

I would prefer not going back to fat only. A ZIP file produce on Unix should 
have the Unix extensions. Exceptional cases need therefore exceptional 
treatement.

I had thought of a few ways:
- not compressed means "fat" (that solve the mimetype problem only.)
- a new method to tell fat-only.
- null times means fat. (Yes, I am here again with 1970-01-01)

>
> (In case you missed the rest of the thread: zipinfo <file> shows "fat" or
> "unx"; "fat" on OOo and kdelibs-3.1-generated files, and "unx" in
> kdelibs-cvs-generated files)

The ZIP file format is document here: 
http://pkware.com/products/enterprise/white_papers/appnote.html

(Of course only the extensions supported by the original PKZIP are documented. 
INFOZIP's extension are as far as I know only documented in source.)

Have a nice day!

____________________________________
koffice mailing list
koffice@mail.kde.org
To unsubscribe please visit:
http://mail.kde.org/mailman/listinfo/koffice

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