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

List:       kde-devel
Subject:    Re: [Bug 154698] Won't open some TIFF files
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2007-12-28 23:36:35
Message-ID: 47758883.4000000 () acm ! org
[Download RAW message or body]

Thiago Macieira wrote:
> James Richard Tyrer wrote:
>>> According to that spec
>>> (http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-in
>>> fo-spec-latest.html#id2447161) the globbing should be preferred for
>>> magics with priority below 80. Both image/jpeg and image/tiff are at
>>> level 50 in the latest database I have.
>> IIUC, an image file contains a "magic number".  This would seem to
>> indicate that there would be very little chance for a misidentification
>>from using magic.  So, I wonder why image/jpeg and image/tiff are at
>> level 50.
> 
> Because your assumption is wrong.

I appear to have presumed that you knew it was an image and that the 
only issue was to determine which type.

> You said there would be very little chance for misidentification. That's 
> not true. The database says that those entries whose priority is over 80 
> are those for which the false positives are very few. Which means those 
> for which the priority is less are actually creating false positives.
> 
> Maybe it's not misidentifying JPEG as something else, but making something 
> else be identified mistakenly as JPEG.
> 
> In any case, your beef is with the MIME Spec and with the database. Please 
> take the discussion to the appropriate mailing lists.
> 
>> IAC, in KDE3, a JPEG file called *.tif is correctly identified as JPEG 
>> and in KDE4 it is incorrectly identified as image/tiff.  Should we 
>> consider this to be a regression?
> 
> Only if that was and is the intended behaviour. Given the MIME DB right 
> now, it looks like it isn't. I can be wrong, though.

Actually, I appear to be mistaken here.  It will properly identify a 
TIFF file without an extension, but, as you said, it will probably 
identify other files as TIFFs.  We know it identifies TXT files (that 
don't have the 'txt' extension) as other things a significant part of 
the time.

>> And as I said, GwenView has no problem determining the correct image
>> type. 
> 
> And as you've been told over and over again, GwenView is not using the 
> MIME-Type detection mechanism.
> 
> Now try this use-case, please. It's using the same architectural 
> components as the Okular case and uses GwenView:
> 
> rename your JPEG file to *.txt and click on it on Dolphin/Konqueror. Does 
> GwenView correctly detect the file type? No! GwenView won't even be 
> loaded!

I think that we should limit this to the possibility of getting image 
formats mixed up.

> This is the situation we're talking about in Okular. It has to decide 
> which backend to load given the MIME type. If the file has been 
> misidentified, it can only be shown if, by chance, the backend that was 
> loaded can also understand that file format.
> 
> GwenView, on the other hand, does not have to decide which backend to 
> load. It has no backends -- or, should we say, it has only one backend. 
> And that backend *does* support both formats.

Perhaps the exact difference between back-end and library has been lost 
somewhere along the line.

You have convinced me that there is no simple solution to this problem, 
but I already suspected that, except that I do have to wonder why Okular 
  has separate backends for PNG, JPEG, & TIFF.  IIUC, it uses Qt to 
render all three of them.

-- 
JRT
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]