Created attachment 130504 [details] Example pdf illustrating the bug (generated with 'img2pdf -o test.pdf test.png') SUMMARY Hello, I have observed that unfortunately in Okular PDF files that contain images with text (e.g. scanned pages) are rendered in a relatively "ugly" way at certain zoom levels when compared with other open source PDF readers. STEPS TO REPRODUCE 1. Open attached file "test.pdf" with Okular. 2. Set zoom level to 75%. OBSERVED RESULT Text looks "rather ugly". (See also attached screenshot.) EXPECTED RESULT Text looks "clearly readable". (Compare screenshot from same document opened in Evince.) I have compared the rendering of other open source PDF viewers with Okular (at same zoom level): Evince, MuPDF, Firefox embedded PDF viewer, Chromium embedded PDF viewer The rendering looks fine on all of them with Okular being the only exception. When I check/uncheck "Enable Graphics Antialias" in Okular, this makes no difference for me. I'm using Kubuntu 20.04 as my main system, but I also verified that I see the same result in the current KDE Neon live image (neon-unstable-20200726-1102.iso). SOFTWARE/OS VERSIONS Linux: 5.4.0-42-generic (available in About System) KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 Kind regards, Jan
Created attachment 130505 [details] Source image file from which the test example was generated.
Created attachment 130506 [details] Screenshot rendering of test.pdf with Okular (zoom level 75%)
Created attachment 130507 [details] Screenshot rendering of test.pdf with Evince (zoom level 75%)
Maybe it is related to the image downscaling algorithm of Okular? I can reproduce the issue by comparing the image side-by-side with Okular and Gwenview: 1. Open the source image in Gwenview. 2. Resize the Gwenview window so that the image is displayed at 75% zoom. 3. Pay attention to the letter "d" in "Wir durften" and you will notice the difference.
@2wxsy58236r3: Okular doesn't do any downscaling. @Jan: I can't reproduce that. Which poppler are you using? Are you on hidpi?
@Alberto My screen is a 24" model with 1920x1200 resolution, I don't think that's hidpi? On my Kubuntu 20.04 installation the package libpoppler97 has version number 0.86.1-0ubuntu1, on KDE Neon (neon-unstable-20200726-1102.iso) there is libpoppler87 with version number 0.77.0-0+18.04+bionic+build2. Since Evince AFAIK also is based on poppler, my first thought was that this problem seems not to be directly related to poppler... Did you also try to reproduce with current KDE Neon image (neon-unstable-20200726-1102.iso)? I just tried that again and verified I can reproduce it in a virtual machine (VirtualBox) as well as by booting the image directly on my machine.
@aacid FYI: Poppler: 0.90.1 Okular: 20.04.3 Using X11 Screen: 1080p, not hidpi
Please try to not misspell my name. Correct, that's not HiDPI. I don't really have time to install KDE Neon to reproduce something, sorry, maybe someone else can. Just for completion, here's my rendering at 75% zoom https://i.imgur.com/UoXrXHk.png Which i realize it's much bigger than yours, so there seems to be something wrong in your configuration, i.e. the file is 23.5 cm wide (file->properties), if you put it at 100% and measure it on your screen with an physical measuring tape, is it 23.5 cm wide?
@Albert Really sorry for mispelling your name, don't know how that happened... Thanks for the screenshot, it looks indeed much bigger on 75% than on my system! If I set zoom to 113% in Okular I get exactly the same rendering (size and image quality) as on your screenshot. So if you set zoom to ~50%, does it look like my screenshot with zoom set to 75%? If I set zoom to 100%, the document width is 23.5 cm as it should be. For my testing I didn't actually install KDE Neon - it was sufficient just to boot the live image. The reason why I tested with KDE Neon live image was that I considered it sort of a unmodified "reference distribution" of KDE (correct me if I'm wrong), and that I wanted to verify that I can reproduce the bug in a "clean", unmodified environment to rule out possible misconfigurations on my main system. Which distribution/setup do you use? Perhaps I can mimic that and try to reproduce how it looks on your screenshot.
(In reply to Jan Rathmann from comment #9) > Thanks for the screenshot, it looks indeed much bigger on 75% than on my > system! If I set zoom to 113% in Okular I get exactly the same rendering > (size and image quality) as on your screenshot. > So if you set zoom to ~50%, does it look like my screenshot with zoom set to > 75%? > > If I set zoom to 100%, the document width is 23.5 cm as it should be. > > For my testing I didn't actually install KDE Neon - it was sufficient just > to boot the live image. > > The reason why I tested with KDE Neon live image was that I considered it > sort of a unmodified "reference distribution" of KDE (correct me if I'm > wrong), and that I wanted to verify that I can reproduce the bug in a > "clean", unmodified environment to rule out possible misconfigurations on my > main system. > > Which distribution/setup do you use? Perhaps I can mimic that and try to > reproduce how it looks on your screenshot. This is probably related to screen sizes. Your screen is much bigger than mine but with the same resolution, so you get less quality than me "per percentage". Because for your 100% less pixels are needed that for my 100%, so i see it better than you at 100%. Can you attach a screenshot of the document at 100% in your screen to confirm? Anyhow, [mostly] that solved that, this is a poppler bug in which the Splash renderer seems to be not so great when resampling text.
Created attachment 130657 [details] Screenshot rendering of test.pdf with Okular (zoom level 100%)
(In reply to Albert Astals Cid from comment #10) > This is probably related to screen sizes. Your screen is much bigger than > mine but with the same resolution, so you get less quality than me "per > percentage". Because for your 100% less pixels are needed that for my 100%, > so i see it better than you at 100%. > > Can you attach a screenshot of the document at 100% in your screen to > confirm? Ok, did that. So if I got this right the bug appears only on lowdpi screens like mine? > Anyhow, [mostly] that solved that, this is a poppler bug in which the Splash > renderer seems to be not so great when resampling text. I'm a bit confused - do you mean "rescaling images" instead of "resampling text"? (since my test document doesn't contain any "real" text but a bitmap image that shows text.)
Yeah i meant "resampling images with text" Yeah makes sense, your 100% is about 875 pixels wide while mine is 1315 pixels wide, since my screen is smaller, i need more pixels to make it 23.5 cm than you, so i see a better image. Anyhow, not an Okular bug, poppler is doing the resampling, so it needs a bug there https://gitlab.freedesktop.org/poppler/poppler/-/issues
(In reply to Albert Astals Cid from comment #13) > > Anyhow, not an Okular bug, poppler is doing the resampling, so it needs a > bug there https://gitlab.freedesktop.org/poppler/poppler/-/issues I did some further testing with other pdf readers based on poppler: qpdfview, Atril, Zathura (all on KDE Neon and Kubuntu 20.04) With Atril and Zathura the rendering is fine at all zoom levels (like with Evince). Interestingly, qpdfview shows the same "ugly" rendering as Okular. Since Okular and qpdfview are in contrast to the other pdf viewers both based on Qt and they are the only one who have this weird rendering, would it be possible that this is somehow a bug in Qt and not in poppler? Otherwise I can report the bug to poppler upstream.
In qpdfview you can select the rendering engine that poppler should use (Splash vs. Arthur), their rendering might be different. There is also a Cairo-based engine that GTK based viewers use.
(In reply to Jan Rathmann from comment #14) > would it be possible that this is somehow a bug in Qt and not in poppler? No, please stop pretending you understand how things work better than me, the poppler maintainer
(In reply to Albert Astals Cid from comment #16) > (In reply to Jan Rathmann from comment #14) > > would it be possible that this is somehow a bug in Qt and not in poppler? > > No, please stop pretending you understand how things work better than me, > the poppler maintainer I didn't know that you are the poppler maintainer... My intention was to do as much testing myself and to provide as much information as possible to help to narrow the circumstances where the bug appears - I thought this would be helpful and "good practice". I honestly didn't want to pretend that I know something better than anyone else - especially since actually I don't have much clue I think. I'm a bit unsure, should I still report the bug to poppler? I don't want to make any further mistake... @Christoph Yeah, I saw that in qdfview and I also tried "Arthur", but the rendering was even worse with it...
I don’t think there is any bug, but just that Poppler uses the available algorithms in e. g. the Qt painting framework, instead of complicated cutting-edge alternatives which *might* perform *slightly* better. https://bugs.kde.org/show_bug.cgi?id=408222#c20 and the following comments contain some explanations and evaluations of some possible “fixes”.
(In reply to David Hurka from comment #18) > I don’t think there is any bug, but just that Poppler uses the available > algorithms in e. g. the Qt painting framework, instead of complicated > cutting-edge alternatives which *might* perform *slightly* better. Poppler is not using any Qt painting framework in this case. Anyway agreed, it's not a bug, but it's something that may need improving.
(In reply to Jan Rathmann from comment #17) > (In reply to Albert Astals Cid from comment #16) > > (In reply to Jan Rathmann from comment #14) > > > would it be possible that this is somehow a bug in Qt and not in poppler? > > > > No, please stop pretending you understand how things work better than me, > > the poppler maintainer > > I didn't know that you are the poppler maintainer... > > My intention was to do as much testing myself and to provide as much > information as possible to help to narrow the circumstances where the bug > appears - I thought this would be helpful and "good practice".ç It is, apologies for my rudeness. > I honestly > didn't want to pretend that I know something better than anyone else - > especially since actually I don't have much clue I think. > > I'm a bit unsure, should I still report the bug to poppler? I don't want to > make any further mistake... Yes please, do a report. > > @Christoph > Yeah, I saw that in qdfview and I also tried "Arthur", but the rendering was > even worse with it...
(In reply to Albert Astals Cid from comment #20) > (In reply to Jan Rathmann from comment #17) > > > > My intention was to do as much testing myself and to provide as much > > information as possible to help to narrow the circumstances where the bug > > appears - I thought this would be helpful and "good practice".ç > > It is, apologies for my rudeness. No problem, apology accepted :) > > > I honestly > > didn't want to pretend that I know something better than anyone else - > > especially since actually I don't have much clue I think. > > > > I'm a bit unsure, should I still report the bug to poppler? I don't want to > > make any further mistake... > > Yes please, do a report. > Ok, here is the report: https://gitlab.freedesktop.org/poppler/poppler/-/issues/950