Version: (using KDE KDE 3.95.0) Installed from: SuSE RPMs OS: Linux At the moment, in continuous mode, going up or down one page moves the view exactly one page up or down. This is really annoying because it leads to lines that can never be read. For example, if only the top half of the last line is visible and I go down one page, then only the bottom half of that same line is visible afterwards. Conclusion: that line is never displayed entirely, thus never readable. Most PDF viewers solve the problem by moving down one page *minus* a small amount, typically one line. Same for page up. To conclude on a nice note, it's my first use of Okular and I find it very good! My only gripe with KPDF was its inability to display the table of contents of a PDF expanded by default (it was always collapsed and the clickable area to expand it was too small). Okular expands by default, it's very convenient. :)
Thibaut, you're right. This is a problem that should be addressed. > Most PDF viewers solve the problem by moving > down one page *minus* a small amount, typically > one line. Same for page up. I suppose one line will be difficult, as Okular probably does not know about the line height of the document. However calculating the amount depending on the zoom level or something similar should do the trick too. I am sure the okular developers will find an appropriate solution :) Florian
I tried that with a few other PDF readers: - KPDF has the same problem, I just never got around to report it. - Adobe Reader correctly goes up or down one page minus one line, as long as I don't zoom in too much. After that it's obviously less that one line (3/4 of a line, I'd say). In any case, the goal is reached: all lines are readable. - Apple Preview manages to go up or down one page minus one line whatever the zoom is. Maybe a consequence of the vectorialized interface. Adobe Reader's behavior isn't perfect but it works, so the "small amount" could be one calculated for usual font sizes, with a little confort margin. That would probably be enough for most uses.
*** Bug 171138 has been marked as a duplicate of this bug. ***
I have just wanted to report this wish but it was already done. Good to know I not the only one who misses this feature. This feature if implemented would improve reading quality a lot. If one line is difficult to implement, it can be just few pixels - not necessarily exactly one line.
*** Bug 220780 has been marked as a duplicate of this bug. ***
> If one line is difficult to implement, it can be just few > pixels - not necessarily exactly one line. Agreed. The point is to make the text readable both before and after the scroll. How much overlap is not very important, the fact that there is overlap is important.
*** Bug 229915 has been marked as a duplicate of this bug. ***
Of course, the workaround is to adjust vertical position with the mouse wheel.
This bug was filed ages ago. Is there any chance of seeing this feature implemented any time soon? Most popular pdf viewers have it and others should have it. It appears Apple's preview has the best implementation of paging down in continuous mode, but I'm sure most would be happy with a simple "approximation" hack.
(In reply to comment #9) > This bug was filed ages ago. Is there any chance of seeing this feature > implemented any time soon? Most popular pdf viewers have it and others should > have it. It appears Apple's preview has the best implementation of paging down > in continuous mode, but I'm sure most would be happy with a simple > "approximation" hack. +1 I'm a programmer, so if somebody would point the way, I'd solve this problem myself, but to find the right file/piece of code myself in that amount of code is nearly impossible..
#9 This is not a bug, this is a wish, do not expect a wish to be fulfilled just because someone had it. #10 Okular code is quite well organized, have a look at ui/pageview.cpp most of it should be probably be there, if in doubt drop by the #okular IRC channel in freenode where we can chat live and it's easier to give some directions.
As far as I'm concerned, this is a bug. Paging down in documents, as it currently stands, has a serious usability issue, otherwise known as a BUG. You may call it a wish (it's also that too) but it deserves attention and fixing. Instead of a complete page up/down, it should do that minus one arrow-key in the opposite direction.
(In reply to comment #11) > #9 This is not a bug, this is a wish, do not expect a wish to be fulfilled just > because someone had it. > > #10 Okular code is quite well organized, have a look at ui/pageview.cpp most of > it should be probably be there, if in doubt drop by the #okular IRC channel in > freenode where we can chat live and it's easier to give some directions. ui/pageview.cpp:2978 is { setWidgetResizable(false); } this, in particular, sets the vertical page step to the displayed page height. In order to fix this once and for all, it would suffice to say { vscroll = this -> verticalScrollBar(); vscroll -> setPageSize (vscroll -> pageSize() * 07 / 010); } after calling setWidgetResizable. Of course, the hem height could be promoted to an option. Of course, you could also make a Qt feature request out of this (who needs documents that paginate edge to edge in continuous view? I believe this problem is not particular to Okular.)
All other pdf readers I know have this feature. All internet browsers have this feature too. If you look at this issue from programmers perspective, this is not a bug. It is a wish. But if you look at this issue from users perspective THIS IS A BUG. Everybody expects from a text reader (web browser, pdf reader, etc) to overlap a line or two when paging down.
Workaround: increase window height. This workaround depends on Bug 249164.
(In reply to comment #13) > { vscroll = this -> verticalScrollBar(); > vscroll -> setPageSize (vscroll -> pageSize() * 07 / 010); } { vscroll = this -> verticalScrollBar(); vscroll -> setPageStep (vscroll -> pageStep () * 07 / 010); } Oops.
I would also want to propose an alternative -- somewhat more complex solution. Of having a "smooth scroll" which is used usually in image galleries which allow users to go down quickly and slow down as it getting to the next area. This is a bit of physics and allow the user to catch continuity in it's reading. Currently the jump of the eyes is also a bit annoying. This is also good for touch interfaces and such but some websites also enable this effect for their sites. This is a "web" example of smooth scroll: http://www.footballmadeinafrica.com/english.html The organization is a bit different since it derives from a fixed menu. A reader should have something more fixed to the size of the workspace/view. Here is a tutorial explaning the code using Javascript: http://www.itnewb.com/v/Creating-the-Smooth-Scroll-Effect-with-JavaScript Core script goes like this: function smoothScroll(eID) { var startY = currentYPosition(); var stopY = elmYPosition(eID); var distance = stopY > startY ? stopY - startY : startY - stopY; if (distance < 100) { scrollTo(0, stopY); return; } var speed = Math.round(distance / 100); if (speed >= 20) speed = 20; var step = Math.round(distance / 25); var leapY = stopY > startY ? startY + step : startY - step; var timer = 0; if (stopY > startY) { for ( var i=startY; i<stopY; i+=step ) { setTimeout("window.scrollTo(0, "+leapY+")", timer * speed); leapY += step; if (leapY > stopY) leapY = stopY; timer++; } return; } for ( var i=startY; i>stopY; i-=step ) { setTimeout("window.scrollTo(0, "+leapY+")", timer * speed); leapY -= step; if (leapY < stopY) leapY = stopY; timer++; } } The first thing this function does is fetch the start and stop Y coordinates via the functions covered above. Next, it compares these two values to determine the distance between them. When setting the distance variable, an alternate control structure is used to determine which point should be subtracted from the other (depends on whether it needs to scroll up or down). Once the start, stop and distance values are set, a check is done to see whether the destination element is less than 100 pixels away, and if so it simply jumps to it. If the destination point is further away the function continues by dynamically setting the scroll speed (distance divided by 100) without letting it exceed 20, step size (distance to jump each time the visible top of page Y coordinate is changed, thus moving closer to the destination), the leapY (next coordinate to jump to) and the initial timer value of 0. At this point, a check is performed to determine whether the destination point is greater than the starting point (scrolling down). If so, the if is entered and the scroll is performed otherwise the for loop at the very bottom is hit, which performs an upward scroll.
Created attachment 63295 [details] Patch to scroll a page and go up a line This triggers a scroll-line-up event whenever a page-down event is triggered with the keyboard. So if you press space bar, it will go down a page and up a couple lines. There is an option to enable/disable this.
The option name is quite bad, i do not know which one would be better, but i know i do not like this at all. Can anyone propose a better one? Also this is not the correct way of implementing it. You should just change the PageStep of the vertical scrollbar (see PageView::resizeContentArea) thus there would be no need of going down and then a bit up.
(In reply to comment #18) > Created an attachment (id=63295) [details] > Patch to scroll a page and go up a line Why did you ignore the method of comment #13?
I was told about this bug report after I created the patch. Sorry that I did not implement it correctly, this is my first attempt with Qt. So the solution from #13 is the one to go for, just nobody has it implemented yet? Or is there another reason there is no patch for it yet?
Created attachment 63379 [details] Shrinking the page step of the scroll bar This uses the approach shown in comment #13, the shrinking of the page step of the scroll bar itself. I added a field where the user can specify a ratio between 0 and 1 for the overlap. That way, users can choose to have .05 or .1 overlap.
(In reply to comment #22) > Created an attachment (id=63379) [details] > Shrinking the page step of the scroll bar > > This uses the approach shown in comment #13, the shrinking of the page step of > the scroll bar itself. > > I added a field where the user can specify a ratio between 0 and 1 for the > overlap. That way, users can choose to have .05 or .1 overlap. Could you do it without going into floating-point arithmetic?
(In reply to comment #21) > I was told about this bug report after I created the patch. Sorry that I did > not implement it correctly, this is my first attempt with Qt. > > So the solution from #13 is the one to go for, just nobody has it implemented > yet? Or is there another reason there is no patch for it yet? The reason I have not turned it into a patch is that Albert (or another KDE developer knowing the Okular source code better than I do) has not approved the idea yet.
(In reply to comment #23) > Could you do it without going into floating-point arithmetic? You mean using an integer percentage instead of a decimal ratio instead? Sure, I can look into that tonight.
Created attachment 63404 [details] Shrinking Page Step -- Integer Version Same as method as above, but now using integer percentage instead of decimal ratio.
I am not sure the maximum overlap can be set to 100. That way, the document will not scroll at all. How amout max=50?
Some comments: * Add an accelerator (&) to the label * make the KIntSpinBox buddy of the label * Add a tooltip to the label explaining what that "Scroll overlap" means so that people can decide what they want * Fix the spacing (no tab at the beginning but spaces) (space in /100) * Agree with Christopher that 100% does not make much sense
Created attachment 63418 [details] Shrinking Page Step -- Revision 5 I did not find the option with the &, but I took care off all the other points. Since I did not want to impose any arbitrary number onto the user, I used 100% as a maximum, although nobody would use that. 50% seems like a good thing to do. That way, people can still set a big number there, but if prevents breaking the whole program.
(In reply to comment #29) > I did not find the option with the &, but I took care off all the other points. Just pick a unique letter for the accelerator, and then in the dlggeneralbase.ui file, for your element's 'property name="text"', in the '<string>' element add '&' in front of that letter. See how 'Show scrollbars' has 'b' underlined in the 'General options' page, and its text '<string>' is 'Show scroll&bars' in the source.
#29 Please make sure that when clicking Apply the or Ok the settings are applied, at the moment you have to restart okular.
(In reply to comment #31) > #29 Please make sure that when clicking Apply the or Ok the settings are > applied, at the moment you have to restart okular. This is definitely something that should be done. How would I apply a new page step after the value has changed in the options? #30: Thanks for the explanation. It already uses the 'l' as the accelerator. Does it make much sense to specify it by hand then?
#32 Have you looked at how to do it yourself? Because if i tell you without you having tried to sort it out yourself you are missing part of the fun ;-) And yes, adding the & in the ui is wanted.
(In reply to comment #32) > Thanks for the explanation. It already uses the 'l' as the accelerator. Does it > make much sense to specify it by hand then? You mean "l" is already in use as accelerator by another entry? Just pick a different letter that isn't, like "o".
Created attachment 63482 [details] Shrinking Page Step -- Revision 6 @Albert: I was looking in conf/preferencesdialog.h, but with some help in the IRC I got PageView::reparseConfig() now. Since I did not want to call the whole PageView::slotRelayoutPages() every time, I refactored my new code into a method which is called on every config parse now. The l is now the accelerator key for this.
I know you got help on IRC, who do you think gave you the tip? ;-) Seems fine, i'll give it a final review and probably commit it.
Git commit 5fd95a3c92825c766805217e72031af5898c7a23 by Albert Astals Cid, on behalf of Martin Ueding. Committed on 08/09/2011 at 00:43. Pushed by aacid into branch 'master'. Allow setting an option so that next/prev page keys do not move really a viewport You can set the amount of overlap in % FIXED-IN: 4.8.0 BUGS: 152049 M +35 -2 conf/dlggeneralbase.ui M +5 -0 conf/okular.kcfg M +11 -2 ui/pageview.cpp M +1 -0 ui/pageview.h http://commits.kde.org/okular/5fd95a3c92825c766805217e72031af5898c7a23