Hello KDE developers,

I believe I have found a small bug; or, if it is not a bug, then at the least it is
behaviour that is ... a bit confusing to me.

I should note that I have tried to open a specific .pdf file, and this failed; I will
explain soon how this happened, but allow me to mention very early on that the .pdf
file viewer called "evince", works under the very same situation. Okular on the other
hand, does not work.

Now - I believe the issue is partially related to Encoding. In particular I am not
using any Unicode/UTF* encoding, but instead I use the ISO encoding 8859-1.

I have a directory structure such as the following:

    /Users/x/STUDIUM/TU_WIEN/166.212_Einführung_in_die_Biotechnologie_und_Bioverfahrenstechnik/2019/

Don't mind this so much; this is mostly a german lecture, thus "umlauts" are part
of this. I do not rename these directories because they are automatically created,
and the schemata for the script that does so, is to start with the LVA ID of the
lecture at hand; and then the name of the lecture. So in this case, an umlaut 
must be part.

I am using the KDE konsole and I am in the directory that I just mentioned.

In this directory there is a single .pdf file, which has been merged of all
local .pdf files, and the name that I gave to this file was:

    Alle_Folien_2019.pdf

Now - using "evince Alle_Folien_2019.pdf" works fine, the files are displayed
via evince. There are some warnings/errors on the commandline, due to encoding
issues (also within the .pdf itself), but it still opens fine and I can work
with it.

IF, however had, I use okular like this:

    okular Alle_Folien_2019.pdf

Then okular shows this error message:

    Could not open file:///Users/x/STUDIUM/TU_WIEN/166.212_Einf�hrung_in_die_Biotechnologie_und_Bioverfahrenstechnik/2019/Alle_Folien_2019.pdf

I am not sure if you can see the problem, but the "ü" character, right
between the "Einf" und "hrung" part in the above file path, is displayed
improperly and, I think, incorrectly.

My LANG variable is set to en_US.ISO-8859-1 and within KDE konsole I
have, under the "advanced" tab, set the local encoding to ISO-8859-1.

I also tested changing this setting in KDE konsole to UTF-8, but the
same error appears.

Anyway - I hope this error description is useful. Now I will try to 
reason why I think this behaviour is a bug; or confusing.

First, what confuses me is that okular requires the absolute path.
I only provided the filename to okular, and I am right in that very
directory. So IF the faulty behaviour is due to the full pathname,
I think it may be better to not include a faulty pathname if we can
avoid it (and if the user provided that exactly). I can understand
that the current behaviour may be better in most cases - an absolute
path can be a lot easier to work with, for instance. I use that in
my own scripts a lot too. But in the example here, I believe this 
leads to the manifestation of that bug, where I now, as a user, have
no simple way to load the .pdf file via okular. As said, evince works
fine (but I don't know if evince makes use of a full path or not).

Either way, this is not exactly the main issue.

The main issue, in my opinion, is that okular chokes on that path
completely. KDE konsole works fine here and I can change, rename,
remove, create, files, directories, symlinks etc... all with umlauts
just fine. It works very well on my system. Evince works too - what
does not work is okular.

Now, it is actually trivial for me to work around - I just move that
.pdf file to a path that has no umlauts. And then it works. :)

So I know that this .pdf file works fine via okular; okular only
chokes on the umlauts part.

How to reproduce this?

Well, hopefully the above gave enough information, but perhaps for
those who may want to try it:

- Set all relevant settings to any ISO such as ISO-8859-1 or
some other variant like ISO-8859-2 or something like that.
- Perhaps also change LANG, and, most importantly, ensure that
KDE konsole has this setting too.
- Create some strange directory path, such as /tmp/foo/bar/aäa/
and then put some .pdf file into that directory that works.
- Navigate towards that directory via "cd", and then do
"okular *pdf" (or the name of the .pdf file at hand)

I believe this should reproduce the problem. Hopefully, because
other than that I have no idea how others could reproduce it.

I'll also give some information about my OS etc..

OS is linux (slackware, but I compiled most things from source
myself). Okular version is: okular 1.6.3

https://download.kde.org/stable/applications/18.12.3/src/okular-18.12.3.tar.xz

All of KDE is latest stable (I avoid unstable because I tend to
have more problems with unstable, logically).

Qt version 5.12.2 in /Programs/Qt/5.12.2/lib

GCC 8.3.0

Most things are very latest stable in general, excluding glibc
(which is still at version 2.23 here), and the linux kernel
which is at version 4.4.12, but I do not think the latter two
have much to do with the behaviour of okular. Thanks for
reading - feel free to close/disregard at any moment in time
for any reason.

PS: I was not sure whether this belongs to any particular
backend, so I picked "general". Not sure which part is the
.pdf backend ("pdf" is not in any of the name of the components
listed here in this formular), but that behaviour may also occur
with other files - I only tested it with .pdf files, since that
is also the only file format I really use regularly, in general.

PSS: I saw at the least three other somewhat similar bugs, such as
339996, 187352 (though this refers to the filename, rather than
the DIRECTORY name), and perhaps also 50270. While several of
them are marked as "RESOLVED", this may not be completely resolved;
at the least the disparity towards evince would be very hard for
me to want to try and reason for/against, since evince works here
whereas okular does not work. If this is related to some underlying
code in KDE then perhaps it might be best to add methods that can
resolve such "umlaut"-situations in general. This is admittedly a
bit rare, since most will use english (I tend to do so too, but
in this case, the directory format is specified to be exactly as
the name of the official lectures, no exceptions to this, as otherwise
it would lead to problems or e. g. replacing umlauts via ae or ue
or oe, which are not so elegant workarounds in my opinion).