'Re: WinWord and *.doc'

[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-23 16:10:12
[Download RAW message or body]

On Friday 23 February 2001 00:41, Nicolas GOUTTE wrote:
> Sorry, but I do not agree!
> 
> 1. KMimeMagic
> 
> KMimeMagic is not capable of identify patterns that are not at a fix 
> position.
> XML for example needs to verify the <!DOCTYPE. However, at the same time 
> XML does not say the exact position of where the <!DOCTYPE will be. White 
> space can be inserted nearly everywhere. So KMimeMagic is useless.
> You think I am wrong. So take an old KDE 1.2 (sic) kfm and present it a 
> XHTML file. Kfm will not like because in XHTML it is : <!DOCTYPE html 
> (upper case DOCTYPE, lower case html) (By the way, this bug is still in 
> KMimeMagic!) But as "text/html" is found through patterns in KDE 2.x, this 
> problem does not arise, as long as the extension is correct.
> And I hope for you, that the author of the HTML/XHTML file has not put an 
> empty line in front of it, if you use KMimeMagic! Nor a XML declaration ( 
> <?xml )

So what ? It's not perfect, then let's fix it, or improve it.
But at least it's a step in the right direction.
You bash the mime-magic solution, but you don't offer ANY other solution.
Where does that lead us ?

It shouldn't be too hard to add a "ignore white-spaces" flag to the magic-file
definition, nor "case-insensitive".

What else do you want to do ? You have that .xml or .doc file that you want
to know what it really is... If the extension doesn't tell you enough, and since
the filesystem doesn't have that information either (has anyone suggested
to the ext3 or reiserfs developers to add metadata support in the FS?),
all we can do for now is open the file and look into it !

> 2. Konqueror Has The Same Goal
Did I say that ?

> That is not true. Konqueror does not have the same goal than a file dialog. 
> A file dialog serves the application that has called it. This application 
> may have very different goals than Konqueror. Konqueror has the goal to 
> present the file and to be able to display it on demand. If the display is 
> a little wrong, it does not matter.
> You have an unknown XML file. For Konqueror, no problem, just display it 
> like any XML file. But in any serious application, you want to import this 
> file. And there it does matter, if this file is from KWord, is in the XML 
> version of DocBook, is a XHTML file or is a generic XML file. (But all 
> those are "application/xml".)

No. You missed the point. I meant that at the moment, KFileDialog does
a _poorer_ job than konqueror at identifying mimetypes.
And you tell me that KOffice (via the filedialog) has a BIGGER need than
konqueror, of correct mimetype-determination. I definitely agree, but if
AT LEAST kfiledialog would do as well as konqueror, wouldn't it already
be a huge step forward ?

Note that we didn't choose "*.xml" for the native KOffice files, and for a reason.
However if we want to recognize KOffice documents without enforcing an 
extension, we will have to add support for ungzipping and untarring into 
kmimemagic. Nothing impossible, since kio has gzip filter support 
(KFilterDev etc.) and tar file support (KTar).

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