SUMMARY I have what I believe is a valid PDF document (at any rate, `gs` can show it just fine). When I open it in Okular, I get an error dialog box that says "Could not open file:///path/to/document.pdf." (obviously with the actual path in it), and no hints as to what might have gone wrong. STEPS TO REPRODUCE 1. Open a certain PDF. (I *think* the problem is something to do with it having a digital signature; it’s a PDF I downloaded from DocuSign and that’s the error I got from another program I tried opening it with.) OBSERVED RESULT "Could not open file:///path/to/document.pdf." The only output when opened in a terminal is: Unable to open QuickAnnotatingTools XML definition which also appears when I open a PDF that works fine, so I don’t think it’s related. EXPECTED RESULT The PDF opens, or, barring that, some information on what could be wrong. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon 5.23, on Ubuntu 20.04 Focal KDE Plasma Version: 5.23.1 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION Possibly related: Bug 321483, from 2013, regarding a similarly unhelpful message when opening a PPT file (except that has output on stderr).
The pdf is broken as far as we understand it, obviously we cna't give more details because if it was not broken we would understand and open it. Besides you attaching the PDF I don't think this can be solved in any way.
Yes, I understand that there’s not much you can do about fixing the PDF problem without a copy of the file (unfortunately it’s got a bunch of personal information in it). I filed this bug with the intent that it was more about the general un-informativeness of the error message. You say “The pdf is broken as far as we understand it“, but even that extremely broad explanation is not obvious from the error message; in fact my first thought when I saw the dialog box was that my flash drive had come unmounted, or possibly some strange permission problem. Ideally this dialog would have a way of giving more technical details about what went wrong (“missing header section Foo” or whatever); but barring that it would at least be useful to know that the problem occurred while trying to understand the PDF rather than being an I/O error or whatever. Maybe change it to something like “Invalid or corrupt PDF found while reading {file}.”?
(On second thought, “Unknown, invalid, or corrupt PDF” might be more accurate, since this PDF at least was neither invalid nor corrupt even though Okular didn’t know what to do with it.)
I have exactly the same issue with a PDF coming from Docusign. The PDF renders correctly inside GMail and can be "printed to file from there". Indeed the oKular message does. I will try to obtain a document that can be attached here.
Created attachment 144098 [details] example file that comes out of Docusign This file can't be opened by oKular.
Created attachment 144099 [details] how GMail previews the document
Attached problematic file. It opens correctly on the Firefox builtin PDF viewer and on the GMail PDF preview function.
Opens perfectly in okular, which poppler version are you using?
Hi Albert, I am using the latest from Kubuntu 20.04: * okular 4:19.12.3-2ubuntu1 * poppler-data 0.4.9-2 * libpoppler97:amd64, poppler-utils (and others) 0.86.1-0ubuntu1
That's an ancient poppler, don't use that if you're serious about PDF usage. @Wolfgang can you confirm you're also on poppler 0.86.1 ?
Meanwhile you can use https://flathub.org/apps/details/org.kde.okular which ships more modern versions of both okular and poppler.
Thank you. What would be the versions of Poppler and oKular recommended for an LTS release like 20.04? If the existing ones are so ancient, perhaps some kind of backport can be done.
The recommended releases of poppler and Okular are always the latest ones.
Yes, I can confirm that KDE Neon seems to use the same version of Poppler, 0.86.1, and I can reproduce the issue with Gustavo's attachment. I've taken the liberty of filing https://bugs.kde.org/show_bug.cgi?id=446309 to see about getting this updated. (Gustavo, once that bug gets taken care of you'll probably be able to manually install the Neon-packaged libpoppler on your system, since Neon is also built on 20.04 LTS.) I'm glad to hear we have a probable cause for this particular case (thanks Gustavo for producing that test PDF!), but I still think the error message needs to be updated to make it clear what's going on when this sort of thing happens. Even if this particular problem is no longer an issue, it's inevitable that some PDFs will be unreadable and the current error message is not at all clear about the problem.
I did a bit of poking around in the Okular source code to see if I could improve this error message, and discovered that it's coming from this line (https://invent.kde.org/graphics/okular/-/blob/9144211ba26fed471e2e493ca1febead253edfe6/part/part.cpp#L1775): QString errorMessage = i18n("Could not open %1. %2", url.toDisplayString(), QStringLiteral("\n%1").arg(m_document->openError())); which actually *does* have a parameter for additional error details, but I couldn't work out where they were supposed to come from. Seems like maybe the problem is just that something forgot to set this string before returning the error?
There are two ways to set this message: QMetaObject::Connection errorToOpenErrorConnection = QObject::connect(m_generator, &Generator::error, m_parent, [this](const QString &message) { m_openError = message; }); (in DocumentPrivate::openDocumentInternal()) d->m_openError = i18n("Can not find a plugin which is able to handle the document being passed."); (in Document::openDocument()) But the Poppler generator does not seem to emit the Generator::error signal. The DVI generator emits a lot more error messages.
That seems entirely plausible. I see that Poppler has way to get error codes and also some kind of callback mechanism that can use actual error strings? Whereas I guess right now that Generator is just returning Okular::Document::OpenError whenever it notices something has gone wrong, without trying to work out exactly what. But I can't work out what's going on well enough to have an idea of what would need to change.
Worth noting that KDE Neon 22.04 now has a much newer version of Poppler (22.09.0-0xneon+22.04+jammy+release+build3) and I can now open both the PDF I was having trouble with and the example that Gustavo provided; so the specific circumstances that prompted this bug report appear to have been resolved. I haven't checked the Okular source to see if similar problems would still result in an equally unhelpful error message, though.