Created attachment 108087 [details] Okular's low resolution view in comparison to Evince On a high-resolution display (QHD+), Okular's font rendering is noticeably inferior to the rest of the desktop, and also to the rendering in Evince. Looking closely, it appears that the displayed image is a scaled-up version of a lower resolution rendering. This occurs across all formats that I have tested (PDF, PS, ODT). The attached screenshot illustrates the problem, showing the same PDF in Okular (left) and Evince (right). This is a HiDPI monitor, and I am using KDE's built-in "scale" option set to "2" (System Settings -- Displays and Monitor -- Displays: Scale Display). It seems plausible that Okular wrongly applies this scaling by first rendering the file in a low resolution and then scaling the resulting bitmap, instead of producing a bitmap using the scaled resolution right away (i.e., it applies bitmap scaling to a vector graphics). Otherwise I am on KDE Neon at default settings for Okular and Evince. I changed Okular's memory setting to "aggressive" without any effect on this issue. I do not think that this bug is related to any other font rendering issues associated with display scaling. The rest of my desktop is looking excellent (making Okular stick out even more).
*** This bug has been marked as a duplicate of bug 362856 ***
Recently a GSoC student worked on resolving this, see https://phabricator.kde.org/D6268 to track progress. If you want to run the experimental version with HiDPI support, Neon makes this easy: apt-get build-dep okular git clone https://anongit.kde.org/okular && cd okular git checkout gsoc2017_hidpi_support mkdir build && cd build cmake .. && make ./shell/okular > The rest of my desktop is looking excellent Let's just hope it does not crash again regularly in front of a large audience… ;)
Thanks for the build instructions. They worked well and the result is looking very good. I will use this local version of okular for now. Is there any estimate yet when this would make it into master, or even into Neon packages?
Thanks for testing, and make sure to let Lukas know in Phabricator if you still find any issues. > Is there any estimate yet when this would make it into master, > or even into Neon packages? As soon as Lukas is back from traveling and resumes work, and the relevant people are happy with the state, I guess, but I would not expect it earlier than for the KDE Applications 17.12 release (see https://community.kde.org/Schedules/Applications/17.12_Release_Schedule). While Neon is not the official KDE distribution, they are usually very fast to provide packages after a release. As soon as the feature is merged to master, you may find it also in some of the unstable Neon editions.
A follow up for people who try to use the above advice to get a working version of KDE: The compiled version of Okular does not quite behave as expected. The high-quality image will only be obtained when starting the application from within the build directory (by calling ./shell/okular). I had tried to install the new version locally by creating a symlink to the compiled file <path to okular>/build/shell/okular in /usr/local/bin/. At first, this seems to work (Okular will show the right version v1.3.70, no matter if started from terminal or directly from within KDE), but the rendering will be as it was in the old version. This even happens when starting Okular from the terminal from within the build/shell directory. It seems that Okular is using some globally registered KDE parts instead of its own locally compiled ones. This unexpected behaviour might cause users to think that the new version is not fixing the bug. To make it work, I created a script /usr/local/bin/okular with the following lines: #/bin/sh cd <path to my okular directory>/build ./shell/okular "$@"
The workaround in my previous post does not work for Firefox (and probably other applications). Even when manually selecting /usr/local/bin/okular in Firefox (the default Okular is hardcoded to be the one under /usr/bin), the script still won't start as intended when opening a PDF file. Maybe it would be better to install the compiled version of Okular properly, but I don't know how (without messing up my distribution).
As you have observed, for a non-developer / production ready setup, you'd also need to make the new software known to the system. This can be done system wide with "sudo make install", or just for a local user by passing "-DCMAKE_INSTALL_PREFIX=~/somepath" to cmake and then "make install" will install to <somepath>. After that, you'll need to adapt your ~/.profile (see https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source#Set_up_the_runtime_environment and possibly adapt some variables to the correct path for your system) and relogin. However, that's all a bit out of scope for this bug, might still have some gotchas and generally we don't want to encourage users to break their system by installing unstable software from random git branches. On the other hand, it's not that complicated either and anyone reading this who is interested in digging deeper into KDE development or testing will certainly find help in the wiki, the IRC channels, forums and on the mailing lists.