My utility's billing system sends PDFs as ViewPdfBills.aspx. This shouldn't prevent Okular from opening an otherwise valid PDF file. > Can not find a plugin which is able to handle the document being passed.
It doesn't, it actually inspects the file to see its content and uses that. Which version are you using?
Okular 1.0.3, Arch Linux. Filename "ViewPdfBills.aspx" -> error Rename to "whatever.pdf" -> opens fine
How are you opening the file?
$ okular <filename> Or via Dolphin - right click, open as, choose Okular.
(In reply to Damian Nowak from comment #4) > $ okular <filename> > > Or via Dolphin - right click, open as, choose Okular. That is weird. Here opening a pdf file works regardless of the extension (both from the commandline and clicking on it in dolphin and right-click open-as with okular). I am on Neon (based on Ubuntu 16.04), KDE Frameworks 5.33.0, Qt 5.7.1 (built against 5.7.1), Okular version 1.0.3
Works fine for me under arch http://i.imgur.com/pybTeqy.png At this point it seems it's a problem with your installation, not sure what more to ask.
nowaker@nwkr-laptop ~ % mv /tmp/test.pdf /tmp/test.aspx nowaker@nwkr-laptop ~ % okular /tmp/test.aspx org.kde.okular.core: No plugin for mimetype '"application/x-wine-extension-aspx"'. <--- !!! IMPORTANT (SNIPPED) nowaker@nwkr-laptop ~ % mv /tmp/test.aspx /tmp/test.whatever nowaker@nwkr-laptop ~ % okular /tmp/test.whatever (SNIPPED - but works fine) Console output definitely suggests Okular is looking at MIME type first. If it's a crazy MIME type like application/x-wine-extension-aspx, it won't try to open it as PDF. I can reproducible the problem on any PDF file I have on disk that I rename to *.aspx.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Requested info was provided a year and a half ago. Marking as REPORTED.
The info is not enough, because as i said, it works just fine for me. So there's something different in his setup, we can remove it from needs info if you want, but unless he can provide info so we can reproduce it, it won't get magically fixed.
In my output: org.kde.okular.core: No plugin for mimetype '"application/x-wine-extension-aspx"'. A quick search on GitHub reveals this: https://github.com/KDE/okular/blob/21836ba072b2d4189f1257af06c11f134f2edc31/core/document.cpp#L2441 Which confirms what I said: > Console output definitely suggests Okular is looking at MIME type first.
So what? I know how to use grep, but i also can prove it opens a pdf file named .aspx for me http://i.imgur.com/pybTeqy.png So stop repeating the same information and maybe give us new one.
Talking SOA#1 instead of talking source code won't get you anywhere. The summary of this bug/feature request is: > Fall back to PDF when file type cannot be inferred from extension (or mime type) Thank you for considering this feature.
You must be very smart, congratulations. We won't fail back to PDF just because you think it's a good idea.
Well, I wonder what would be the right behavior from the UX point of view? I personally would like Okular to do its best to open the files I throw at it. As for the above conversation, it seems it has gone personal. Guys ... no need to go there. It looks like Nowak provided steps to produce in the message from 2017-04-13 23:33:39 UTC Even if bug cannot be reproduced (yet) clearly it's happening to at least one user who as it appears is open to providing more data, links to the code. I suggest to re-open for future investigation and perhaps re-purpose. Let the other users find this issue .. PS. https://community.kde.org/Get_Involved/Bug_Reporting > Have a thick skin > Sometimes your bug report will get closed without the resolution you're hoping for. This feels disappointing, but it's not personal. The project is larger than any one of us.
(In reply to Damian Kaczmarek from comment #15) > Well, I wonder what would be the right behavior from the UX point of view? I > personally would like Okular to do its best to open the files I throw at it. And it does, it tries like 3 different ways of opening the file before it bails out. > As for the above conversation, it seems it has gone personal. Guys ... no > need to go there. It looks like Nowak provided steps to produce in the > message from 2017-04-13 23:33:39 UTC Have you read my answers? His steps *do not work* > Even if bug cannot be reproduced (yet) clearly it's happening to at least > one user who as it appears is open to providing more data, links to the code. Pointing to lines of code is bad, he pretends like he understands the code, which he doesn't, so it makes him less credible. So unless he can actually provide a patch that fixes the issue for him, he should stop pointing to the code and start trying to help us reproduce the issue. But anyway we'll never fall back to PDF because it makes no sense.
(In reply to Albert Astals Cid from comment #16) > Pointing to lines of code is bad, he pretends like he understands the code, > which he doesn't, so it makes him less credible. I know some user comments may be frustrating, but IMHO a reply implying bad faith ("pretends") and lack of skill ("he doesn't understand code") does more damage than good and goes against the KDE code of conduct. I'd suggest you ignore the bug if the user comments brush you the wrong way and you can't reply in a positive way (which is HARD, I admit). As far as the bug goes, I can now reproduce it. The problem seems to be that okular only looks at the contents when the etension either is not registered in the system mimetype database at all or it is registered to a mimetype which Okular has a plugin for. If it is and the extension does not correspond to the file contents, okular fails opening the file: $ okular test.pdf $ mv test.pdf test.ods $ okular test.ods $ mv test.ods test.non_registered_ext $ okular test.non_registered_ext $ mv test.non_registered_ext test.txt $ okular test.txt Only the third line fails for me (because ods is registered as an extension of mime type 'application/vnd.oasis.opendocument.spreadsheet' on my system and okular has no plugin for it) > provide a patch that fixes the issue for him, he should stop pointing to the > code and start trying to help us reproduce the issue. Actually, pointing to the code made it easier for me to go over it (I wouldn't bother without the link). It seems there really is a bug there: https://github.com/KDE/okular/blob/21836ba072b2d4189f1257af06c11f134f2edc31/core/document.cpp#L2417 should use the 'QMimeDatabase::MatchContent' mode instead of 'QMimeDatabase::MatchExtension'.
(In reply to Jonathan Verner from comment #17) > (In reply to Albert Astals Cid from comment #16) > > > Pointing to lines of code is bad, he pretends like he understands the code, > > which he doesn't, so it makes him less credible. > > I know some user comments may be frustrating, but IMHO a reply implying bad > faith ("pretends") and lack of skill ("he doesn't understand code") does > more damage than good and goes against the KDE code of conduct. Don't bring the code of conduct here, that's silly. > I'd suggest > you ignore the bug if the user comments brush you the wrong way and you > can't reply in a positive way (which is HARD, I admit). No, because the user then may then go on saying "see they're shit as i said", so if the user is ignoring my questions and comments i will call him on it. > As far as the bug goes, I can now reproduce it. The problem seems to be that > okular only looks at the contents when the etension either is not registered > in the system mimetype database at all or it is registered to a mimetype > which Okular has a plugin for. If it is and the extension does not > correspond to the file contents, okular fails opening the file: > > $ okular test.pdf > $ mv test.pdf test.ods > $ okular test.ods > $ mv test.ods test.non_registered_ext > $ okular test.non_registered_ext > $ mv test.non_registered_ext test.txt > $ okular test.txt > > Only the third line fails for me (because ods is registered as an extension > of mime type 'application/vnd.oasis.opendocument.spreadsheet' on my system > and okular has no plugin for it) > > > provide a patch that fixes the issue for him, he should stop pointing to the > > code and start trying to help us reproduce the issue. > > Actually, pointing to the code made it easier for me to go over it (I > wouldn't bother without the link). It seems there really is a bug there: > > https://github.com/KDE/okular/blob/21836ba072b2d4189f1257af06c11f134f2edc31/ > core/document.cpp#L2417 > > should use the 'QMimeDatabase::MatchContent' mode instead of > 'QMimeDatabase::MatchExtension'. Yes, that is correct, whoever ported that code make a mistake. I'll fix it. *BUT* I'm still going to close this (NOT A BUG because i can't find a better option), since we're not going to "fall back to pdf when the file type cannot be inferred" since it makes no sense.
Albert - actually I am failing to see how 'fall back to pdf when the file type cannot be inferred" makes no sense'. To me the "makes no sense part" is not obvious - could you elaborate please? Especially because it kind of works already. > cp foo.pdf foo && okular foo # THIS WORKS v> cp foo.pdf foo.mp9 && okular foo.mp9 # THIS WORKS > cp foo.pdf foo.mp3 && okular foo.mp3 # THIS FAILS From just a functional point of view it makes a lot of sense to me in the instance of some browsers/websites/applications generating PDF files with a wrong extension. This saves the user one extra step but perhaps I missed some disadvantages of this approach. Just my 2 cents, Cheers.
(In reply to Damian Kaczmarek from comment #19) > Albert - actually I am failing to see how 'fall back to pdf when the file > type cannot be inferred" makes no sense'. To me the "makes no sense part" is > not obvious - could you elaborate please? Especially because it kind of > works already. Okular is not a pdf viewer, so why would it fall back to pdf instead of djvu or ps or xps or any of the multiple document types we support?
This probably depends on the (local) contents of the MIME database. Please check what 'kmimetypefinder5' says when passing the file. On my system, it is unaware of 'application/x-wine-extension-aspx' and outputs 'application/pdf' when passing a PDF file named '.aspx'. Maybe 'wine' package adds entries to the MIME database.