Version: (using KDE Devel) Installed from: Compiled sources Compiler: GCC 4.2.2 OS: Linux I found a TIFF file that opens fine in GwenView but won't open in Okular. All that I get is a box with an error message: Could not open file: <path>/<file>
Created attachment 22703 [details] TIFF file that doesn't open
Gwenview opens it fine... because the file is a JPEG! Opening with the okular TIFF backend, I get this message in the console: br154698.tiff: Not a TIFF or MDI file, bad magic number 55551 (0xd8ff). And, $ file br154698.tiff br154698.tiff: JPEG image data, JFIF standard 1.01 thus: $ cp br154698.tiff br154698.jpeg then both gwenview and okular (using the image backend) are able to open the image.
Created attachment 22704 [details] TIFF file that does open I opened the file in The GIMP and saved it with the same type of TIFF format and now it opens.
Re: Comment #2 Please see second attachment. It is possible that this is a magic number issue, perhaps it even has the wrong extension (and that does appear to be the case). However other apps, including GwenView, Kview, KwickShow, The GIMP, Krita-1.6.3, ImagicMagick(display), etc. KDE-3.5.x does thumbnails. So, there is a bug even if it is not as stated. Before modifying the bug, we need to know if the problem in Okular occurs in Okular or is caused by KDE libraries or base functions.
The problem is not in Okular. Okular just uses what KMimeTypes reports to be the mimetype of the file, and then uses the backend responsible for handling that mimetype. If the backend receives something it cannot read, it's not its fault. To the TIFF issue: both the Qt TIFF plugin AND the okular TIFF backend use libtiff, so in case that file is really a TIFF, the problem is there.
Re: Comment #6 You seem to fail to understand what CONFIRMED means. It means that the reported behavior can be reproduced by another person. Are you claiming that you can NOT reproduce the behavior which I reported which is that the first attachment won't open in Okular and the second attachment will? > Okular just uses what KMimeTypes reports to be the mimetype of the > file, and then uses the backend responsible for handling that > mimetype. If the backend receives something it cannot read, it's not > its fault. That is not actually the case. KDE is using the MIME type of the file to determine which Okular backend to call. So, this problem might be caused by Okular's architecture. Gwenview, OTOH, is directly presented with the file and has no problem reading it. > To the TIFF issue: both the Qt TIFF plugin AND the okular TIFF > backend use libtiff, so in case that file is really a TIFF, the > problem is there. You are trying to talk down this bug rather than trying to find out exactly what the problem is and correct it. Modification to the KDE MIME type system might be sufficient to fix this bug, but I don't know if it is necessary. Still, there does seem to be a bug there since the extension 'tif' overrides the Magic while if the file has no extension it is correctly identified as JPEG.
> > Okular just uses what KMimeTypes reports to be the mimetype of the > > file, and then uses the backend responsible for handling that > > mimetype. If the backend receives something it cannot read, it's not > > its fault. > > That is not actually the case. It's nice to see how you reject the explanation of the developers of that architecture. > KDE is using the MIME type of the file > to determine which Okular backend to call. > So, this problem might be caused by Okular's architecture. No. Okular asks KMimeType to determine the mimetype of the file, then it chooses which backend to call acording to what KMimeType reports. Okular just trusts what KMimeType reports as results. No less and no more. > Gwenview, OTOH, is directly presented with the file and has no problem > reading it. ... just because both TIFF and JPEG are image formats supported by gwenview. If you do kfile --dialog <image> where <image> is the first attachment, you see (Preview tab) it fails to generate the preview; while if you do that after renaming it to .jpg, the preview is rendered correctly. Thus, I'm reassigning the problem to kdelibs (where KMimeType is), as should be KMimeType to report us the correct mimetype for it.
Re: Comment #8 IIUC, if the KDE4 MIME system identifies the JPEG file as JPEG then Okular should open it. Sorry, but I made some modifications to the MIME data (no file extensions for JPEG, PNG, & TIFF. And, it still doesn't work. So, there is a n issue somewhere in Okular. Probably not an important one, but still an issue.
Created attachment 22744 [details] Properties This clearly shows that the file which I have renamed: "not-tiff.tif" is correctly identified as a JPEG file (which it is).
Created attachment 22745 [details] Okular with ERROR Note that the ERROR says that it can't open the file: "not-tiff.tif" which the KDE4 MIME type system correctly identified as a JPEG file.
Since KDE Libs correctly interperts the MIME type data provided, it isn't a KDE Libs bug.
Not important enough to worry about.
Can you please post all the console output of your last attempt?