When I try to open a document named "име.pdf" I get the following error: "Could not open /home/kiril/име.pdf" (see the attached screenshot). When I rename the file using only ascii symbols, everything's fine. Even though my locales are strictly en_US.UTF8, it seems like Okular doesn't respect that. Output from the command "locale": LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=en_US.UTF-8 P.S.: I'm assuming this is an issue in Okular, because everything else in cyrillic works just fine in other KDE applications (Plasma, Dolphin, Gwenview, etc.). Reproducible: Always Steps to Reproduce: 1. Open a regular .pdf document with ascii-only symbols in its name with Okular 2. Rename it by using cyrillic symbols, like "тест.pdf" for example 3. Try to open it again with Okular Actual Results: You get an error similar to "Could not open /home/.../.../ÑеÑÑ.pdf" Expected Results: Document should simply be opened, regardless of the non-ascii symbols in its name.
Created attachment 95922 [details] Could not open /home/kiril/име.pdf
After trying to get this one confirmed by other users in #kde, several folks there helped finding out that this issue occurs only when okular is invoked by other application like Dolphin, Firefox (when pdf is downloaded), KMail (when pdf file is received as an attachment), xdg-open, etc. If I use kde-open the issue is the same, but the encoding seems to be different (still not utf8, though), because the error is "Could not open /home/kiril/desktop/???.pdf". Notice the question marks, instead of ... those other funny symbols. However, if I simply execute "okular име.pdf" the file simply opens and everything's fine. So, it looks like this issue is not in Okular in particular, but it's the only place where I suffer from it.
Do you open them from the terminal or from somewhere else?
While writing the bug report I didn't think there's a difference in how I "open" documents. After I found out that this assumption is wrong, I've described that in comment #2: > After trying to get this one confirmed by other users in #kde, several folks > there helped finding out that this issue occurs only when okular is invoked > by other application like Dolphin, Firefox (when pdf is downloaded), KMail > (when pdf file is received as an attachment), xdg-open, etc. If I use > kde-open the issue is the same, but the encoding seems to be different > (still not utf8, though), because the error is "Could not open > /home/kiril/desktop/???.pdf". Notice the question marks, instead of ... > those other funny symbols. > > However, if I simply execute "okular име.pdf" the file simply opens and > everything's fine. So, it looks like this issue is not in Okular in > particular, but it's the only place where I suffer from it.
Works fine here from okular, kde-open, xdg-open and dolphin. Which dolphin and KDE Frameworks versions do you have installed?
Dolphin: 15.08.3 KDE Frameworks: 5.16
I just booted my secondary laptop that runs archlinux, updated it to the latest of everything, create a file called име.pdf and could open it just fine with dolphin. No idea what may be wrong on your side.
I think it has something to do with Regional Formats settings (System Settings -> Regional Settings -> Formats). I was using en_US, but with detailed settings (UK time settings and Bulgarian measurement units and currency). My $LANGUAGE env was set to `en_US:bg`. Even though I've tried to manually change it (in ~/.zshrc) KDE doesn't seem to respect that. For the sake of testing I've switched back to US settings for all formats, then restarted the machine and Okular is able to open files with non-ascii names again.
Not sure I understand what you mean, do you say that setting the LANGUAGE env var to en_US:bg makes okular fail opening the files?
Not sure it's only due to the changed value of LANGUAGE. These settings should only modify LANGUAGE and LC_* env vars, as far as I get it, but I may be wrong. However, I'm 100% positive that that manipulating Regional settings can cause this bug, i.e. Okular is able to open document with non-ascii filenames, depending on specific regional formats settings.
Need exact reproduction steps
I have very same problem on two machines. Both have complex locale settings. The first one runs Gentoo and the second one runs ArchLinux. Locale settings are identical: $ cat /etc/locale.conf LANG=uk_UA.UTF-8 LC_NUMERIC=C LC_COLLATE=C LC_MONETARY=en_IE.UTF-8@euro LC_MESSAGES=C LC_ADDRESS=de_DE.UTF-8 LC_TELEPHONE=de_DE.UTF-8 LC_PAPER=de_DE.UTF-8 Once I enable "Detailed Settings" in the Formats KCM, Okular is unable to open files with non ASCII characters in names. However, I do not think that this is problem of Okular, since LibreOffice shows the same problem (can't open nor via kde-open nor via its File|Open menu). The only difference is that in error messages where they inform user about the problem Libre Office shows correct file name, while Okular shows characters in encoding which I can't even guess instead of non-ASCII letters. So, I think Formats KCM does something wrong to locale settings. When I set there my settings from /etc/locale.conf, locale shows: $ locale locale: Cannot set LC_ALL to default locale: No such file or directory LANG=uk_UA.UTF-8 LC_CTYPE="uk_UA.UTF-8" LC_NUMERIC=C LC_TIME="uk_UA.UTF-8" LC_COLLATE=C LC_MONETARY=en_IE.UTF-8 LC_MESSAGES=C LC_PAPER=de_DE.UTF-8 LC_NAME="uk_UA.UTF-8" LC_ADDRESS=de_DE.UTF-8 LC_TELEPHONE=de_DE.UTF-8 LC_MEASUREMENT="uk_UA.UTF-8" LC_IDENTIFICATION="uk_UA.UTF-8" LC_ALL=
I experienced this issue after changing Collation in the Detailed Settings, now it looks to be solved by uncommenting the new locale in /etc/locale.gen and running # locale-gen as root. My current locale: LANG=en_DK.UTF-8 LC_CTYPE="en_DK.UTF-8" LC_NUMERIC=cs_CZ.UTF-8 LC_TIME="en_DK.UTF-8" LC_COLLATE=cs_CZ.UTF-8 LC_MONETARY=cs_CZ.UTF-8 LC_MESSAGES="en_DK.UTF-8" LC_PAPER="en_DK.UTF-8" LC_NAME="en_DK.UTF-8" LC_ADDRESS="en_DK.UTF-8" LC_TELEPHONE="en_DK.UTF-8" LC_MEASUREMENT="en_DK.UTF-8" LC_IDENTIFICATION="en_DK.UTF-8" LC_ALL=
Now Okular does not want to open files with spaces in path from command line. $ okular /some/directory name/file name.pdf -> does not work $ okular /some/directory_name/file name.pdf -> does not work $ okular /some/directory name/file_name.pdf -> does not work $ okular /some/directory_name/file_name.pdf -> works $ cd /some/directory name; okular file_name.pdf -> does not work $ cd /some/directory name; okular file name.pdf -> does not works In all cases File|Open in Okular works OK. Compiled from branch "frameworks"
Eugene, please do not pollute real bugs with frameworks branch bugs, if you use a unstable development branch, you don't go and comment on bugs that are for a stable version. Using the frameworks branch is totally unsupported, if you want to do it, you're free to do it, and you may even report *new* bugs and add [frameworks] to the beginning of the topic to highlight it's of a non release branch. Thank you for understanding.
OK, I'm sorry.
Under System Settings > Regional Settings > Formats you can select a Region. Note that it has a locale associated with it. In my case it is de_CH. If that locale does not exist or is built with a different charset than UTF-8 then this bug occurs. On Gentoo that means you must add that locale with UTF-8 charset to /etc/locale.gen and run locale-gen. If I do that the problem disappears.
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!
It's been three years since this bug was reported. Just tried to reproduce it on the same machine and it seems to be fixed now. Closing it with WORKSFORME, because I'm not sure when exactly this got fixed (whether intentionally or not).