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

List:       koffice-devel
Subject:    Re: WinWord and *.doc
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-02-24 0:00:01
[Download RAW message or body]

On Friday 23 February 2001 22:22, Nicolas GOUTTE wrote:
> The Extended Attribute interface for Linux does not seem to be for near 
> future, at least if you look at the recent discussion on linux-fsdevel 
> mailing list. Then it has to be implemented in each Linux file system that 
> wants to support it. (I suppose the HPFS (OS/2) file system would be the 
> first one!) And all this would only be for Linux.

Yup, but it would be the "real" solution to this problem :(

> To be constructive about KMimeMagic, I have this idea: use external 
> programs to specify the exact type after KMimeMagic has made a rough 
> identification.
> 
> For examples, KMimeMagic has found that the file was tarred and gzipped. 
> Call a special external program that can analyse it further.
> 
> One way to implement it is also to have "filters" for certain mime types.
> 
> For example, KMimeMagic analyses a file as being application/x-gzip. The 
> new part of KMimeMagic would notice that this mime type must be analysed 
> further and calls an external program for gzipped files. The external 
> program would give back the definitive mime type for that file.

That's not very flexible in fact. It looked flexible at first sight, but.... many
things can be gzipped, and you would either have only one program that
would have to know about all sorts of gzipped files, or you would have to
call all the "external programs or modules" that know about gzipped files
one after the other (huh).
But IMHO there is a simpler solution to this problem, more consistent with
the current way: adding another file known to kmimemagic, with a
format like

UNTAR maindoc.xml 40 <DOC\ editor=\"KWord\" application/x-kword

Which would mean: if the document appears to be gzipped (we already detect
that just fine), then start the gunzip filter, then extract the beginning of
maindoc.xml out of the tar storage, and look for that string at position 40.

Actually, the automatic gunzipping is something that kmimemagic should
do in general, not only in this context (in order to recognized gzipped
text files, postscript files... anything gzipped).

A more flexible solution would be that each of those document-type-specific
line is in the desktop file of the mimetype, but this is another matter
(it should already be done even for the current stuff, so it's unrelated).

> The advantages of those "filters" would be that the current magic file 
> format do not need to be changed and that the "filters" can do it by other 
> methods, which would be more specific to what they should analyse.

Same advantage with another file, called for gzipped documents,
without having to call 10 "external programs"...

> Note: please take the term "external program" widely. May be it could be a 
> KDE library if it suits better. Or even something else.

IMHO this makes much code for nothing (dlopening a library etc.),
at least if we can always describe file formats with something like
the above.

> >No. You missed the point. I meant that at the moment, KFileDialog does
> >a _poorer_ job than konqueror at identifying mimetypes.
> 
> Sorry, I had never noticed that KFileDialog had another way to identify 
> mime types than Konqueror!

Stephan and Carsten, listening ? :-))

> >Note that we didn't choose "*.xml" for the native KOffice files, and for a 
> reason.
> 
> I meant the uncompressed maindoc.xml document (alone and raw, no tar, no 
> gzip). KWord loads it without problem, but wants it named into the *.kwd 
> pattern.

That's for compatibility reasons only. There's not much point in building
any solution around that. It is much easier for everyone (especially filter
writers) if KOffice documents are always gzipped tar files.

> As I was writing this message, I noticed that all this discussion is about 
> loading files but how do you determine in which exact file format you save 
> to a (new) file? In this case, you cannot use KMimeMagic, as there is no 
> file to check!

From the mimetype chosen in KFileDialog's combobox !

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today
_______________________________________________
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]