Created attachment 122008 [details] screenshot showing the effect SUMMARY Using a Bamboo stylus (checked and works OK in Gimp), "Freehand" annotations result in extremely jagged lines. STEPS TO REPRODUCE 1. Wacom bamboo stylus, Fedora 30, mapped to 1 display 2. open document in okular 3. F6 to open annotations 4. select Freehand tool 5. write on document OBSERVED RESULT extremely jaggy/spiky lines EXPECTED RESULT reasonably smooth lines (like when I had Fedora 28) SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Fedora 30 (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION Writing with mouse does give smooth lines.
Oliver isn't this something you worked on/fixed? Was it post 1.6?
I did work on something related, but what I did fix was something else (poor resolution of the lines in presentation mode). From looking at the picture (I cannot reproduce the problem) it seems as if the path was drawn with the Qt::MiterJoin style, which does indeed lead to jaggedness if the angles are very sharp. I don't really understand how this can happen, though: as it is an annotation it is poppler that does the line drawing, right? René, can you render the file with pdftocairo and check whether the result looks better?
Created attachment 122126 [details] new testpage, output from ocular
Created attachment 122127 [details] ocular output run through pdftocairo, pdf output
Created attachment 122128 [details] okular output run through pdftocairo, svg output
Thanks for the screenshot. To be honest I have no idea where this could come from. It is not your stylus because you say it works okay with Gimp. Is it maybe a Qt problem? Could you try with another application that uses Qt? Could you also try if you get the same behavior when drawing in Okular presentation mode? Do you have the skills to build Okular from source and try the bisect this?
*** Bug 412224 has been marked as a duplicate of this bug. ***
I'm having the same issue (Bug 412224). The only difference is that I'm using Ubuntu, not Fedora. Otherwise, everything seems to be the same. The problem occurred after I upgraded to Ubuntu 19.04 (similar to you upgrading to Fedora 30). We're using different drawing tablets as well but I don't think that is causing the issue. I use Okular for school and I might revert back to Ubuntu 18.04 to temporarily fix the issue.
Created attachment 122832 [details] Plot of the points of the spiky path I extracted the points of the problematic path from the pdf document, and plotted them using gnuplot. This gets us one step closer to an explanation: As can be seen from the attached picture, each point is actually a pair of points, a small distance apart. Together with a MiterJoin line style this explains the jaggedness of the resulting path. [Currently I simply assume that MiterJoin line drawing is used, but I didn't check. For a 'normal' set of points on a path you wouldn't see the difference.] So the remaining task is to find out where these double points come from. My system (which is a bleeding edge Okular on Debian Buster) doesn't produce them. I am tempted to conjecture that the problem is somewhere in the lower layers of the tablet input stack, and not in Okular itself.
(In reply to Oliver Sander from comment #9) > Created attachment 122832 [details] > Plot of the points of the spiky path > > I extracted the points of the problematic path from the pdf document, and > plotted them using gnuplot. This gets us one step closer to an explanation: > As can be seen from the attached picture, each point is actually a pair of > points, a small distance apart. Together with a MiterJoin line style this > explains the jaggedness of the resulting path. > > [Currently I simply assume that MiterJoin line drawing is used, but I didn't > check. For a 'normal' set of points on a path you wouldn't see the > difference.] > > So the remaining task is to find out where these double points come from. My > system (which is a bleeding edge Okular on Debian Buster) doesn't produce > them. I am tempted to conjecture that the problem is somewhere in the lower > layers of the tablet input stack, and not in Okular itself. Thank you, Oliver. By the sounds of it, I do think you're correct about the origin of the error. It would make sense why the path would appear jagged and spiky because of the pair of joints. I'm not well-versed in these things and my understanding of it is lacking. So take my opinion with a grain of salt. However, I don't believe that the error is caused by the tablet itself. My drawing pad seems to work fine in other applications that are more geared towards drawing/art (Rene stated that it works fine for him in GIMP). This could happen because it uses a different method for tracking paths or could lead to an inconclusive idea that it is a problem with Okular. I would also like to mention that my drawing pad is of the same brand as Rene's but is a different model. I don't know how relevant that information is. I suppose it's possible that this is a bug that occurs with only Wacom tablets. I don't know how likely that would be. Drawing in Okular before I upgraded from Ubuntu 18.04 to Ubuntu 19.04, I had no issues. The error only came to be after upgrading my OS. This leaves me to believe (though I may be incorrect) that this isn't an issue with the drawing tablets but something else. I would also like to reiterate that this only occurred after upgrading my OS (the same thing happened in Rene's case). I don't know why that is but I do think that it's quite strange and could have something to do with the bug.
Created attachment 122852 [details] attachment-26613-0.html Could it be that somehow the path is created by both the xinput device and the input fed to X's core pointer? That could explain sets of close points? On Wed, 25 Sep 2019 at 01:10, <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=410723 > > --- Comment #10 from blackdovahbear@gmail.com --- > (In reply to Oliver Sander from comment #9) > > Created attachment 122832 [details] > > Plot of the points of the spiky path > > > > I extracted the points of the problematic path from the pdf document, and > > plotted them using gnuplot. This gets us one step closer to an > explanation: > > As can be seen from the attached picture, each point is actually a pair > of > > points, a small distance apart. Together with a MiterJoin line style this > > explains the jaggedness of the resulting path. > > > > [Currently I simply assume that MiterJoin line drawing is used, but I > didn't > > check. For a 'normal' set of points on a path you wouldn't see the > > difference.] > > > > So the remaining task is to find out where these double points come > from. My > > system (which is a bleeding edge Okular on Debian Buster) doesn't produce > > them. I am tempted to conjecture that the problem is somewhere in the > lower > > layers of the tablet input stack, and not in Okular itself. > > Thank you, Oliver. By the sounds of it, I do think you're correct about the > origin of the error. It would make sense why the path would appear jagged > and > spiky because of the pair of joints. I'm not well-versed in these things > and my > understanding of it is lacking. So take my opinion with a grain of salt. > > However, I don't believe that the error is caused by the tablet itself. My > drawing pad seems to work fine in other applications that are more geared > towards drawing/art (Rene stated that it works fine for him in GIMP). This > could happen because it uses a different method for tracking paths or could > lead to an inconclusive idea that it is a problem with Okular. > > I would also like to mention that my drawing pad is of the same brand as > Rene's > but is a different model. I don't know how relevant that information is. I > suppose it's possible that this is a bug that occurs with only Wacom > tablets. I > don't know how likely that would be. > > Drawing in Okular before I upgraded from Ubuntu 18.04 to Ubuntu 19.04, I > had no > issues. The error only came to be after upgrading my OS. This leaves me to > believe (though I may be incorrect) that this isn't an issue with the > drawing > tablets but something else. I would also like to reiterate that this only > occurred after upgrading my OS (the same thing happened in Rene's case). I > don't know why that is but I do think that it's quite strange and could > have > something to do with the bug. > > -- > You are receiving this mail because: > You reported the bug.
I managed to get the bug to reproduce on Ubuntu 18.04.3 with Okular(v1.8.1) on a separate machine with the same drawing tablet. I initially installed Okular with "sudo snap install Okular" to get the latest version and experienced the same bug. I was trying to install and use Okular on a computer that didn't have this error and decided to try to install an older version on the same machine (Ubuntu 18.04.3). I used "sudo apt install Okular" and it installed Okular(v1.3.3) and I did NOT experience the same bug! This was good news for me but I have no clue why it was happening. I uninstalled the snap version(v1.8.1) on my main computer(Ubuntu 19.04) and installed the apt version(v1.6.3). Obviously, the apt packages are maintained by the Ubuntu Developers (you can check with "apt show okular")and because my OS is on a later version, some of the packages are more updated as well. Okular happens to be one of them. On my main computer(Ubuntu 19.04), I experience the same annotation bug with Okular(v1.6.3). This leads me to believe that this bug occurs on Okular versions 1.6.3 and later. The bug may still occur on a number of earlier versions before Okular(v1.6.3) but I think that it would work fine with Okular(v1.3.3) if I were able to run it on Ubuntu (19.04). I tried to install Okular(v1.3.3) with "sudo apt install okular=1.3.3" but I received an error: "E: Version '1.3.3' for 'okular' was not found" meaning for whatever reason, version 1.3.3 was not available. There may be a way to install version 1.3.3 some other way but I don't quite know how to navigate Okular's website to install the older version. If I discover a way to install Okular(v1.3.3), I will report what happens.
I have experienced the same issue on my up-to-date Arch Linux installation. I'm using a Wacom pan on my laptop screen. It is also working fine in GIMP. I downloaded and compiled the following versions and found that all of them have the same issue: 1.8.1 1.3.3 release tag 17.12.3 1.0.3 release tag 16.12.3 I therefor think that if this feature ever worked properly - which I don't know - some dependency must have changed its API. I can also confirm, that drawing with the pan results in a significant increase in points for the drawn path. I compared it to using my finger on the same touchscreen.
Additionally, I couldn't reproduce the problem in a Ubuntu 18.04 VM with nether the apt version 1.3.3 nor the snap version 1.7.2... this is however most likely due to the way the input is passed along; xinput does not show the pen
bug report log (debugging) AnnotatorEngine::decodeEvent for tabletEvents is called when - using mouse - using finger - using pen AnnotatorEngine::decodeEvent for mouseEvents - using pen Assumption: Calling both mouse end tablet event decode causes the double point bug resulting in fuzzy drawings Test: comment out decodeEvent for tablet events Expected Result: Smooth paths when using pen Implementation: added lines to PageViewAnnotator::routeTabletEvent: ``` // primitive always ignore in hopes to fix bug 410723 e->ignore(); return QRect(); ``` Result: smooth paths when using pen Assumption: the caller of PageViewAnnotator::routeTabletEvent could prevent the duplicate points Result: the caller PageView::tabletEvent is logically solid, the problem must lei somewhere else Assumption: the caller of PageView::tabletEvent could prevent the duplicate points Result: could not locate the caller. Conclusion: I couldn't fix the bug properly but the described workaround works for me... For those wo cannot wait for the fix I suggest compiling the project yourself its very easy: $ git clone https://invent.kde.org/kde/okular.git $ cd okular $ cmake . $ make -j # '-j' will use a lot of cpu power but is faster $ sudo make install
Could bug 411487 be related?
Can confirm this on openSUSE Tumbleweed with Okular 1.8.2 using a Lenovo pen on the screen. The lines drawn with the pen look much more jagged than those drawn with the mouse, although those could be a bit smoother as well. Ideally you would just have kritas brushes in Okular :P
(In reply to Oliver Sander from comment #6) > Thanks for the screenshot. To be honest I have no idea where this could > come from. It is not your stylus because you say it works okay with Gimp. > Is it maybe a Qt problem? Could you try with another application that uses > Qt? > > Could you also try if you get the same behavior when drawing in Okular > presentation mode? > > Do you have the skills to build Okular from source and try the bisect this? On my Manjaro installation, I compiled it for myself and was STILL able to produce the bug. (I wasn't able to compile it on Debian to test it out) For a while, I had Okular running without this issue ever being produced on my Debian installation but seemingly without reason, I started experiencing the issue. I did not perform any updates, what so ever. Also, I tested what Oliver said to try a while back. My tablet works completely fine when using it in Krita, a KDE drawing application that also utilizes Qt. I can confirm that I was NOT ABLE to reproduce the bug in the presentation mode.
Can confirm it with a Wacom Intuos M on Operating System: Manjaro Linux KDE Plasma Version: 5.18.3 KDE Frameworks Version: 5.69.0 Qt Version: 5.14.1 Kernel Version: 5.5.8-1-MANJARO > I can confirm that I was NOT ABLE to reproduce the bug in the presentation mode. Can you please describe how to use the line tool in the presentation mode? I don't see any option.
>Can you please describe how to use the line tool in the presentation mode? I don't see any option. In presentation mode, move the cursor to the upper edge of this screen. This will make a toolbar appear, where you can select a color to draw with.
Thanks Oliver. > I can confirm that I was NOT ABLE to reproduce the bug in the presentation mode. I can confirm it, to. (The presentation mode works almost* fine and is more suitable for pen written notes than the "freehand annotation". * It's not much jagged, but could still be smoother.)
I had a similar issue where there was a more or less constant zig zag pattern in the freehand lines using the surface pen on surface book with ferenOS (bionic, neon(I think)). After the installation of a lot of dev libraries I removed the input from the pen much like independent-squirrel did in comment 15 with similar results: zig zag is gone, although the lines aren't really smooth, probably X only simulating so many mouse actions in a given time frame. I somehow managed to get okular to crash when I select a custom annotation preset and mix the buttons up (freehand line is underline, squiggle is freehand line etc.) in the process. Btw: Can someone link me a resource for uninstalling stuff installed trough sudo make install? I do not really understand the underlying functionality of those annotations, but I would suggest ignoring mouse input when pen input is being detected, or an option to ignore the pen which gets automatically suggested when a repeated two point pattern or simultaneous input through mouse and pen is detected.
Created attachment 129992 [details] patch for fixing jagged line problem
The patch is for today's development version of okular.
(In reply to Rene from comment #23) > Created attachment 129992 [details] > patch for fixing jagged line problem Can you post it on invent.kde.org, please? https://invent.kde.org/graphics/okular Just fork the project, push the changes into a branch of your fork, and create a merge request? Many thanks in advance for your work.
Git commit 15ac564b93a3c17b7ccdf2ce701bac88bb43d741 by David Hurka. Committed on 16/07/2020 at 22:58. Pushed by davidhurka into branch 'release/20.08'. Annotations: explicitly accept tablet event when it is handled This fixes the jagged freehand lines problem. It was caused because tablet events were not accepted, and so were delivered again as mouse event, creating an additional line point slightly offset, causing sharp line angles. FIXED-IN: 1.11 M +3 -0 ui/pageview.cpp https://invent.kde.org/graphics/okular/commit/15ac564b93a3c17b7ccdf2ce701bac88bb43d741
(Credits for the patch go to Rene.)
Git commit ab7ae92a891adcb5c43435e75ea0e9ce8c078d81 by David Hurka, on behalf of René van Paassen. Committed on 17/07/2020 at 15:52. Pushed by davidhurka into branch 'release/20.08'. Annotations: explicitly accept tablet event when it is handled This fixes the jagged freehand lines problem. It was caused because tablet events were not accepted, and so were delivered again as mouse event, creating an additional line point slightly offset, causing sharp line angles. FIXED-IN: 1.11 M +3 -0 ui/pageview.cpp https://invent.kde.org/graphics/okular/commit/ab7ae92a891adcb5c43435e75ea0e9ce8c078d81