continuous reading mode or "scroll" mode

[dracodoc]

In acrobat reader you can "enable scrolling" in page display, which will connect all pdf pages into a continuous flow. This mode can be very useful in reader too, because it's very often the pdf page aspect ratio is not as same as the reader screen aspect ratio, that means:

1. in fit page mode, there will be gray area in sides, lots of screen wasted. And the font could be too small in this mode.
2. in fit width mode, user need to use "down" to move down bit by bit instead of move screen by screen in current kpdf, and the last part of one page often only occupy a small part of the screen, another waste of screen and need additional key press for next page.

If kpdf support scroll mode, these problems will be solved perfectly. Fit width can use all the screen, the font will be much larger, and next page always bring another page of contents, no big white area or additional page turn in each page break.

Another detail about this mode is the gap between two pages. It's better to only take the content of pages to connect into a scroll, so that the white margin in page bottom and top will not come into the display. There could be a user customizable gap (either transparent or light gray, should also customizable) between pages if user don't want all pages connected seamlessly.

[hwhw]

I agree that it would be nice to have.

That said, implementation is not that easy as it might occur at first. Some things off my head:

• logic of what to render and display: at least two pages might come into play, possibly more for lower zoom levels.
• page width differences between pages. Actually, a quite common case. This leads to
• horizontal navigation (vertical is obvious, horizontal is a headache, e.g. do you clamp all pages to the "biggest width" page and center them on that width? can get messy with just a single rotated page in an otherwise homogenous document)

Well, that's probably why I didn't consider it at the start. It's just hard to do right. There's a reason why a lot of PDF readers don't have it :-) And I won't touch it until the new framework is in shape...

[dracodoc]

Yes it could be quite complex. I think we can divide the feature into different cases, some of them are easier to do.

1. use some key to scroll next screen in fit page width or fit content width mode instead of using five-way to move bit by bit. This could be done quite easily, right?

2.I think the scanned pdf can be postponed because that would be more complex and it can be solved by other software like pdflrf.

3.For text based pdf, first user need to chose fit page width or content width. To fit page width is relatively easy, and user can actually crop pdf to desirable content with some margin so that page width is just like content width -- I always believe the process can be done in pc software should be done in pc software. So we can further limit user cases to page width.

4.If there are some pages vary a lot in page dimension, they should be separated from the continuous flow.

I totally agree this feature should be considered after the new framework, just want to have it recorded in list :)

[Dmitriusan]

I think, the a big and common issue is pagination in fit-to-content mode. Maybe, the simplest solution would be using a Space Bar, for example, to move viewport down through the rendered page on 1 screen. When page end is reached, part of page is displayed and free space is filled by gray. Pressing Space Bar once more moves viewport to the beginning of new page. So that we can focus on reading instead of navigation :) Currently, it is not too handy to read books because of need to use joystick to move through the page, use page buttons to switch page, and then scroll to the beginning of this page using joystick. But kindlepdfviewer even now is definitely much more usable for reading pdf ebooks compared to standart one :)

[dracodoc]

I found this app based on mupdf support continuous mode, maybe you can take it as a reference: http://repo.or.cz/w/llpp.git llpp — A very fast PDF reader based off of MuPDF, that supports continuous page scrolling, bookmarking, and text search through the whole document

[tigran123]

IMHO, this feature is not really needed and will complicate the code unnecessary, thus inviting bugs. Instead, the users should be encouraged to learn how to use the main crowning feature of kindlepdfviewer (namely, the manual bbox assignment via Shift-X for odd and even pages). This will solve all the problems you mention. In fact, one could throw away all the existing "zoom" etc features as unnecessary and leave just Shift-X --- this would change nothing substantial and kindlepdfviewer would still remain the best PDF and DjVu viewer in the world (for Kindle).

[dpavlin]

I have found manual zooming quite useful when you are trying to see detail of picture or some small part of page, so I wouldn't remove it completely, but I would suggest to use Shift-X, after all that's why I implemented it :-)

[dracodoc]

I beg to differ. Almost ANY feature will complicate the code, unless your code is already complicated unnecessarily and the new feature actually involve a rewrite. "inviting bugs"? If you are afraid of bugs, the only safe way is no code, no bugs.

I can understand your concern of "inviting bugs" from the feature you don't wanted.

Anyway, can you elaborate and educate me how to use Shift-X to solve the all the problems I mention?

I'm eager to learn and prove myself wrong that there is already a perfect solution.

[tigran123]

I was being more generic than specific (i.e. specific to the problem you mention) when I spoke of Shift-X. Namely, "very generally speaking", one can achieve very comfortable level of reading by carefully tuning the bbox using Shift-X to any particular book (or Shift-F for books typeset in two columns). Also, "very generally speaking" (i.e. from very long experience of not only reading books, but also typesetting, publishing, editing, proofreading, etc) I found "continuous mode" of Acrobat Reader quite useless and confusing, even with the page boundaries clearly marked.

Perhaps I should have explained something clearly instead of expecting people to "read between the lines". In the implementation of "continuous mode" you would have to either scroll down in little chunks or in screen worths. If you allow scrolling down in little chunks then there is a lot of unnecessary screen refreshes (and so draining the battery). But if you only allow discrete jumps one screen-worth at a time, then the only benefit is the time otherwise spent on pressing Next key at the bottom of those (hopefully very few) particularly empty pages at the expense of total confusion during the reading as to where on the page you are, i.e. at the top or at the bottom.

There are more serious bugs in kindlepdfviewer (e.g. in the twocolumn mode it oftens does things wrongly, I will need to look into this thoroughly and then open as an issue) and, imvho, these should be ironed out first before adding such a major feature as continuous reading mode.

[dracodoc]

So Shift-X didn't solve my problem?

1.If you did read my first post, point 2, moving screen by bits is not desirable.

2.For a pdf file with certain aspect ratio which can be comfortably read with fit content width but are too long in height, there WILL be empty space for the second screen for EVERY page, not "hopefully very few".

3.This scroll mode is available in numerous other software, asked by many users in different forums. Actually, the current method of epub page display of kpv is some kind of scroll mode, which don't even have the page header and footer often found in pdf. You can start a poll, ask users whether the scroll mode will be "total confusion".

4.Everybody have his own priority, I never use Shift-X, I almost never use two column mode(I'd split it in pc instead of moving in kindle), nor did I suggest my request to be top priority and put down every feature I would not use.

If you are representing all major contributors, you can close this issue.

[dpavlin]

No need for harsh words, we are just volunteers with limited time on our hands, so excuse our attitude.

I would really love to have continuous scroll mode, probably together with two-page mode and thumbnails of all pages which all would require quite a bit of logic we currently don't have.

Having said that, I don't have ETA for this features, but we'll keep this issue opened and have it in mind while working on future versions.

[dracodoc]

dpavlin, I definitely didn't mean anything harsh to you. I myself wrote some small applications in my spare time before, so I totally understand volunteer software authors have limited time and his own priorities.

You may notice I've submitted lots of bug reports and feature requests, but I never push or request a ETA. It have been some time from last update, but I can totally understand, and current kpv is good enough that I use it every day exclusively.

[dpavlin]

Don't worry about it, I just wanted to bring ball down a little in this conversation :-)

[houqp]

Actually, I agree with both @dracodoc and @tigran123. I myself use 'Shift+X' and two column mode a lot, and so far, all my ebooks can be read comfortably with the help of these two features. But in some books, the bottom of the current page is related to the top of next page. In this case, scroll mode might be quite helpful for readers. However, in some other cases, like reading comic, scroll mode might screw things up.

On the other hand, introducing scroll mode is not a trival task for current code base. It might break some other parts of the software. This is why it is still not supported by KPV ;P It will be easier to implement scroll mode in our new_ui_code branch. But seems that current active developers are more interested in current code base...

I believe freesoftware is not just about giving programmers freedom to hack on the source code, but also freedom for users to configure the software so it can work in the way they want. Apple sometimes makes great designs, but it sucks on forcing users to adapt to all their designs. I hope eventually, the scroll mode feature can be added to KPV but is configurable so users can turn it off.

Anyway, I think we should stop arguing on whether we should have scroll mode here. It will just lead us to no where :) In freesoftware community, "Those who code, decide". ;-P

[dracodoc]

Well said houqp!

[Aaron2Ti]

+1

sometimes the font of the origin pdf is so tiny, and I have to rotate 90 degree on my DX.

after rotating, the PageDown would go to the beginning of next page instead of the next half of current page, the 5ways key could only move one line down for the current page

[dracodoc]

An immediately improvement can be made about the page down key. In fit width or fit content width mode, the page down button should move screen to the next part of same page, instead of next page. Why would anybody page down to next page without seeing full content?

There should be something to mark the edge of first screen and second screen, probably like the epub end of screen gray shade.

After the current page is finished, next page down should move to the top of the next page.

This is not as difficult as the scroll mode. I didn't stress this only because I almost always use pdflrf to process my pdf to fit the screen.

[tigran123]

@dracodoc I totally agree with you on the behaviour of the "page down" key. And I suggested exactly the same in issue #236 "Next-page stops working after panning in fit page width and fit content modes." (see the discussion there)

I should perhaps emphasize that the skipping to the next page only happens if you do some scrolling (with FW-selector) just before. But if you don't do it, then "page down" behaves exactly as you and I expect (see my reply to @Aaron2Ti below)

[tigran123]

@Aaron2Ti In the case you describe the continuous scroll mode wouldn't really help as much as correctly tuning the bounding box (bbox) with Shift-X function. So, if you adjust the bbox with Shift-X and then press "Shift-S" then pressing "Page Down" (I meant "Next Page") key will give you precisely the behaviour you seek, i.e. it will go one screen-full down on the current page, NOT jump to the next page.

The problem will arise if you temporarily switch to "scroll" mode using Up/Down keys of FW-selector (btw, if you use Right/Left keys thereof you will end up in a rather messy situation, try it :) So, if you use Up/Down of FW-selector while in Shift-S mode then the behaviour of PageDn will change and indeed skip to the next page. This is a bug which I described in the issue #236 "Next-page stops working after panning in fit page width and fit content modes."

[dracodoc]

I found that ebookdroid have the scroll mode and it is using mupdf, maybe you can have a look at it. http://code.google.com/p/ebookdroid/

[tigran123]

Thank you, @dracodoc , you are very helpful. But the problem with implementing the continuous scroll mode is not to do with the usage of mupdf library, but to do with how to manage the page data inside KPV's internal implementation, e.g. interacting with tile cache, etc.

[dracodoc]

Yes, I understand that kpv's special implementation method is different from other reader apps, and that's why kpv is fast. Just want to provide a reference. :)

[houqp]

scroll mode is added in #781 by @chrox , welcome to give it a try :)

[dracodoc]

@houqp , where is the scroll mode? I downloaded the newest nightly build kindlepdfviewer-v2013.1-20-g7ad2c7c, but I didn't find any scroll mode in the help page of kpv. I also didn't find any difference in fit content and fit content width mode.

I looked at the code in #781, it is not included in the latest nightly build I downloaded. Is it in the new UI branch?

[houqp]

Yeah, sorry that the scroll mode is only added to new ui branch ;p

[dracodoc]

Then will the new ui branch support kindle DX when it is released? I imagine there could be some complexities if it need to support both keyboard and touch devices.

[houqp]

Technically, you can run the new version on all kindle devices. Practically, you won't want to do this ;p Because the new release only targets touch device for now. We haven't run it on any non-touch device so far and I suspect some of the features won't work properly as code for keyboard devices are not added yet.

I am afraid fully keyboard device support will probably have to wait for the second new version release.