Version: 0.9 (using KDE 4.3.0) Compiler: gcc version 4.4.1 (GCC) ./configure --prefix=/usr --enable-shared --enable-languages=c,c++,fortran,objc,obj-c++ --enable-threads=posix --mandir=/usr/share/man --infodir=/usr/share/info --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic OS: Linux Installed from: Unspecified Linux When clicking on "Advance to the next page" button on the toolbar or pressing the keyboard shortcut to go to the next page, okular does not jump to the top of the next page. It rather shows the half-bottom of a page and the half-top of the next one. I think the "half-bottom page" is the page showing when the action was taken. An example is attached[1]. This happens ~1/8 tries when in "Single Page" mode and ~1/12 in "Facing Pages" mode. Once it happens, going to next page will _always_ do show the same effect of half-bottom previous page + half-top of next one. To correct this, I need to go to the previous page which then shows the top of the previous page. I can then go to next page which will show the top of the next page. In Facing Pages mode, when the bad behavious happen, going to next page will correctly go to the top of the next page. But going to the next page will show again the bad behaviour. The bad and good behaviours alternate until I go back to the previous page, "reseting" the bad behaviour. Going to the previous page _never_ gives a bad behaviour. [1] http://nbigaouette.inrs-emt.homelinux.net/linux/kde/okular.png
I tried again with 4.3.3 and I can still reproduce the problem. It seems the problem occurs when "Trim Margins" is enabled and I keep the next page keyboard shortcut pressed for a long time. When doing this, I see pages switching from previous to next quite fast, until it slows down just a bit since it needs to render the pdf. When the loading is slower, the problem is more frequent. As if okular got confused while loading a page about where it is supposed to be in that page.
It definitively have something to do with "Trim Margins" as I can almost always reproduce this with it enable but can't reproduce it without. It seems Trim Margins breaks keyboard shortcuts to go to next page. Also, when going to a specific page (ctrl+g, or put page number in the lower bar), the problem occurs: instead of being on that wanted page, okular shows half the previous page, and half the wanted page. The page number in the lower bar indicates the page previous to the wanted one. It might not be related, or might be, but sometimes when I go to a specific page (ctrl+g for example), okular jumps to that page but then starts to go to previous pages with ~four page jumps per second. I need to stop it by scrolling the page with the mouse wheel or go to next page button/shortcut. All these appeared with 4.3.0 I think and is still present with 4.3.3.
It's got nothing to do with the "Trim Margin" settings for me. It happens all the time for me with that option unchecked. See the attached video. I'm using KDE 4.3.4 from openSUSE RPMs.
Created attachment 40073 [details] Video showing bug
Some further observations for facing pages mode: The jump to the middle of the next page occurs only for pages which haven't already been viewed. For pages which have already been viewed, the "next" button alternates between doing nothing and jumping to the top of the next page. The "previous" button behaves likewise; every second time it is pressed, the button does nothing.
Does it happens when you set page zoom to "Fit Width" too?
@Tristan: Yours is a different bug, as you can see it only happens by pressing the "Next" button, but not by pressing "Space"
Nicolas, we made a few fixes in the trim mode, can you please check if you can still reproduce this bug in okular shipped with KDE 4.10 or newer?
I though about this bug report yesterday as it also happened. I just tried it again and the problem is still present. I'm using 4.10. The PDF I tried it with is this one, freely available: http://iopscience.iop.org/1367-2630/14/6/065010 Note that all following tests have been made _without_ trimming margins. To reproduce, I start at first page. Then I press the right arrow (which I configured to go to the next page) 8 times. The 8th time, the problem happened. Sometimes, it's the 15th or 16th time I skip page. Actually, it might have to do with a page which is not in cache. If I go to the first page and start to skip pages, the problem will always happen on a page which seems to load (the pdf is rendered more slowly when the problem happens). At some point, the whole pdf seems to render faster (its all in a cache somewhere?) and the problem can't be seen anymore. It's also possible to reproduce when 2 pages are shown side by side. Again, once the whole document has been viewed, I can't reproduce it at all, even when closing the document and reopening it, switching to single page view, etc.
It's weird how is so easy for you to reproduce and i can't at all. Just to make sure could you attach your `kde4-config --localprefix`/share/config/okularrc `kde4-config --localprefix`/share/config/okularpartrc and the file in `kde4-config --localprefix`/share/apps/okular/docdata that corresponds to that file? Make sure you sanitize them if needed (i.e. maybe remove last opened files and stuff)
Created attachment 77930 [details] `kde4-config --localprefix`/share/config/okularrc (sanitized) I'm attaching the (sanitized) files.
Created attachment 77931 [details] `kde4-config --localprefix`/share/config/okularpartrc (sanitized)
Created attachment 77932 [details] `kde4-config --localprefix`/share/apps/okular/docdata file Note: The full file name is: 694554.2012_Moll et al._Inverse bremsstrahlung heating beyond the first Born approximation for dense plasmas in laser fields.pdf.xml But I had trouble opening the file. less complained it couldn't open the different words as files, even if the filename was quoted or the spaces escaped... I was able to open it through kate and copy its content elsewhere. This is what I'm attaching.
Files provided, setting back to unconfirmed
Nah, can't still reproduce :-/
I think my problem is the same as described by others, but the conditions under which I first encountered the bug are slightly different. When I am using okular to view a .pdf that will update (for example as the viewer when using Kile/LaTeX to make a document) and the 'Trim Margins' option is turned on, the .pdf scrolls itself when it updates. For example: I am viewing a .pdf with the window sized to fit one page, and the view is aligned to the top of page x. If the document updates, it will scroll itself so that the middle of the view is right between pages x and (x+1). If I use the 'Next Page' button (mapped to right arrow for me), it jumps to the middle of the next pages (between (x+1) and (x+2)) instead of the top of the next page. This continues with pressing 'Next Page' repeatedly. The 'Previous Page' button behaves normally and scrolls to the top of page x in this example. This action 'resets' the view so that moving to the previous/next page moves properly to the top of pages in the document. I get the same behavior when adjusting the size of the okular window. It seems that the bug is triggered whenever the view of the document is updated, so when the document refreshes itself, when the window size is changed, or when moving to the next page in a document. This is frustrating because otherwise I love using kile/okular for building documents, this is the one part of it that is not working smoothly. I am running Arch Linux (64-bit), here is my version info: Qt: 4.8.4 KDE Development Platform: 4.10.3 Okular: 0.16.3 It looks like it was compiled with GCC 4.8.0 20130502 (prerelease) I am also running okular from within XFCE 4.10, if that matters.
Just a “me too” posting. I confirm both Tristan’s report (Comment #4) and also the one previous to this one. I’ve been having this issue for many KDE versions now. I can’t even remember anymore using an Okular without it. :-( Re Tristan: I tried it with an 89-page motherboard manual in two-sided view mode and fit-all zoom. Using l (small L, BTW thanks very much for vi keys, I only discovered them by accident) to jump to the next two pages, Okular first does as expected, but then immediately moves the view up another half page. But only for yet unseen pages: If I jump back up with h and down again over those pages, the second jump does not occur. Re Andrew: Currently my most often use case is creating music scores with LilyPond, which works the same way as TeX does: it compiles text input into a PDF. If I view a score PDF at the top of a page, for example in single-column mode with either fit-width or fit-all zoom, recompile it and Okular updates, its view moves down so the border between the viewed page and the previous one is now at the vertical centre of the view. I then have to either press hl or lh to realign the view to where it was before the reload. The most interesting thing about this is: if I move the view away from the top edge by just one notch (say, I press h to jump to the top, and then j to move it down one line), that reload-jump does not happen.
Guys can you still reproduce this issue with Okular >= 0.19.0 (KDE Applications >= 4.13.0)?
Yes, still happening with Okular 0.19.0 (kde 4.13.0) on ArchLinux x86_64.
Ok, can you please try to attach the exact file you use and the describe exactly the options you have (trim, etc) so we can try to make it fail locally (that's the first step to make a fix)
It happens with _every_ pdf out there, not just specific ones. I just create a latex document where I can see the problem. I'm attaching both the .tex file and pdf. When I don't trim margins, it only happens when two pages are shown side by side. It doesn't seems to happen when a single page is shown. When I do trim margins, it does happen even with single page view.
Created attachment 86526 [details] Example PDF showing the problem
Created attachment 86527 [details] Source file for the pdf showing the problem
Created attachment 86528 [details] Screenshot of single page view (margins trimed)
Created attachment 86529 [details] Screenshot of dual page view (margins not trimed)
ok, with document from #22 and two pages side by side and fit to width i can reproduce this now. Thanks :)
Last comment is of 2014, just wanted to state that I am too experiencing this issue (very regularly, without trimming) on KF5, running Arch Linux with these versions: Qt: 4.8.7, KDE Development Platform: 4.14.13, Okular: 0.23.2.
I've just tested to see if I can reproduce this with okular but I am unable to. Can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. I've set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved" when you respond, thanks.
I sadly no longer have access to a machine running KDE and/or Okular. As this is a bit of non-response, I'm not sure what to mark this as. Maybe someone else still has it running?
I haven’t been able to observe the problem for a long time now. There is something else, but vaguely related: when I open a file in Okular that it has never seen before, the zoom is set to fit the width of page. Usually, this means a portrait-layout file on a widescreen monitor, ergo the page does not fit into the window. But the crop that is shown is somewhere in the middle of the page, not at the top. This means that in 99 % of cases, the user has to scroll to the top in order to start reading the document.
I can confirm this issue is no longer present for the documents i've seen so far.