Bug 325044 - PostScript file with extension .txt are not rendered as PostScript
Summary: PostScript file with extension .txt are not rendered as PostScript
Status: RESOLVED FIXED
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: 0.19.1
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-18 09:07 UTC by Maciej J . Woloszyk
Modified: 2014-08-13 21:55 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.14.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej J . Woloszyk 2013-09-18 09:07:36 UTC
In previous versions of Okular when I opened postscript file (identified by file command as "PostScript document text conforming DSC level 2.0, Level 2") it was correctly rendered and PostScript content was displayed. After upgrading when I try to open the same file Okular shows the source (treating it as simple text file) instead correctly rendering what's inside.


Reproducible: Always

Steps to Reproduce:
1. rename PostScript file from .ps to .txt
2. open it with okular

Actual Results:  
PostScript source is displayed

Expected Results:  
PostScript content should be rendered
Comment 1 Albert Astals Cid 2013-09-21 15:45:58 UTC
I don't think this is not an okular issue, adding David Faure to see what he thinks, but the thing is kdelibs is telling okular the foo.txt file is a text file so we use the text backend to open it

tsdgeos@xps:~/okularfiles/ps$ diff 3dcolor.ps 3dcolor.txt 
tsdgeos@xps:~/okularfiles/ps$ kmimetypefinder 3dcolor.txt
text/plain
(accuracy 100)
tsdgeos@xps:~/okularfiles/ps$ kmimetypefinder 3dcolor.ps
application/postscript
(accuracy 100)

But sincerely, if you have a .ps file named .txt, you're doing something wrong.
Comment 2 Maciej J . Woloszyk 2013-09-23 06:14:44 UTC
On 21 September 2013 17:45, Albert Astals Cid <aacid@kde.org> wrote:
>
> But sincerely, if you have a .ps file named .txt, you're doing something wrong.
>

If it was simply my doing I would agree. Unfortunately this is
something I get as an output from our stupid ERP system and I can't do
anything about it. But as it worked all these years before I would
like it to work again ;)

m.
PS. And yes - it's doing it wrong. As it is doing many other things :(
Comment 3 Albert Astals Cid 2013-09-23 18:15:32 UTC
It worked because we did not support txt files, we now do, so we now open it as a txt file which is what you are telling us it is with the .txt extension, there's nothing we can do. You can remove the txt backend from your system and it'll work again.
Comment 4 Maciej J . Woloszyk 2013-09-24 06:31:43 UTC
On 23 September 2013 20:15, Albert Astals Cid <aacid@kde.org> wrote:
> It worked because we did not support txt files, we now do, so we now open it as
> a txt file which is what you are telling us it is with the .txt extension,
> there's nothing we can do. You can remove the txt backend from your system and
> it'll work again.
>

Ok. I've removed the backend and yes - it works as it should.

And IMHO decision about file content based on it's name is a huuuge
step backwards. I feel like in the old Windows days.

Thanks for the suggestion anyway.
Comment 5 Albert Astals Cid 2013-09-24 11:50:37 UTC
There is a problem with using magic to open a file, that it can fail, and once it has failed there's no way to override it from a user point of view. That's why we give precedence to the extension, it's something the user can fix if they fucked up. Except you don't seem to be able to control your extensions because of your unique broken scenario.
Comment 6 Albert Astals Cid 2013-09-24 11:54:28 UTC
Now, what we could do is, in the case that file extension and file contents magic detection disagree, show a dialog saying "Hi sir, we're confused, what do you want to do with this?"

Do you think this is an acceptable solution?
Comment 7 Maciej J . Woloszyk 2013-09-24 13:19:31 UTC
On 24 September 2013 13:54, Albert Astals Cid <aacid@kde.org> wrote:
> Now, what we could do is, in the case that file extension and file contents
> magic detection disagree, show a dialog saying "Hi sir, we're confused, what do
> you want to do with this?"
>
> Do you think this is an acceptable solution?
>

It could be especially with a checkbox for "remember this decision for
this type od diagreement" ;)

For me it would be better if I finally learn how to create Gentoo
ebuilds and just make a text backend optional at the compile time and
then simply switch it off ;) But the dialog could be more general
solution.
Comment 8 Albert Astals Cid 2014-08-13 21:55:17 UTC
Git commit fba90677fcc9ccf0e6f5efe75e7446703d669d36 by Albert Astals Cid.
Committed on 13/08/2014 at 21:51.
Pushed by aacid into branch 'KDE/4.14'.

Fine tune mime type detection used for opening files

If the argument mimetype and filepath mimetype disagree, first try to use the filepath mimetype and if that fails use the argument one. On top of that if text/plain is the first, first try with content mimetype since the text backend never fails to open a file

I can now open https://bugs.freedesktop.org/attachment.cgi?id=99508 (which is served as text/plain) and PS files with .txt extension (bug 325044)

REVIEW: 119737
FIXED-IN: 4.14.0

M  +60   -18   part.cpp
M  +2    -0    part.h

http://commits.kde.org/okular/fba90677fcc9ccf0e6f5efe75e7446703d669d36