Touch Kobo Touch future firmware feature request thread

[BensonBear]

I just signed up here, read through a lot, saw that some of this has been said before, but I will give my views about this one particular issue for a starter.

Better PDF reading is crucial. To make this request as easy to satisfy as possible, we should restrict it at first to the simplest case: single column books and articles which are probably the most common sorts of material by far.

For most of us, this material will require landscape mode, and then a zoom as large as possible to get rid of the margins which are taking up needed space. The zoom and horizontal positioning should be saved across invocations, and upon opening the document, applied.

Then, the crucial thing is that the basic tap functionality must work the same as it does for epubs. A right tap should advance the document to the next readable section, regardless of where in a page this is. So in a particular case this is either further down on the same page, or to the top of the next page. Similarly for left tap.

What is done now is no good for easy reading. One has to spend way too much uncomfortable time trying to scroll up or down, losing track of where one was reading, accidentally also scrolling left or right, and waiting for the screen to update in very ugly fashion. Then, only when one is confident the end of the page is reached, one must scroll to the extreme left or right to get to the region where a tap advances the page.

Awful!

It will be necessary to retain the ability to scroll when things get a little messed up, but it should be secondary. (This will require more dedicated regions for the left and right tap, but this is no big deal. The whole thing is really quite easy. There is a slight difficulty in that without examining the contents of the page it is a little difficult to tell how to scroll down to the next unread section. It is not easy to figure it out *exactly* but the program can err on the side of caution and perhaps overlap a line or so).

To avoid the need for much scrolling in normal reading mode, one possibility is to save the zoom factor, plus *two* horizontal positionings, one for the odd pages and one for the even pages. This also is easy.

This would make pdfs readable with much more ease. And it is not so hard to do.

After this, bookmarking for pdfs should be added. The program does not have to extract the text from the page displayed, but just remember at the very worst the page number, and maybe even the physical location on the page. No need to dig into the page contents if that is harder to do. But bookmarks are very important in this sort of system where one cannot see the big picture with ease.

[BensonBear]

Something that bothers me is the little on/off button, with that little spring in it that makes a little noise when you use it. I am concerned that if this button fails, the entire machine is rendered basically useless.

It would be nice if some of the pressure could be taken off this button. This should not be hard to do. Already we do not have to use it to turn off or go to sleep mode, because we can do that in software via the tweak provided by Andreas Heider.

But I suspect it would also be possible (not for us, but for Kobo) to make it so that the (seemingly more robust) home button, if desired, could take the machine out of sleep mode. Perhaps with a long press to avoid accidents. It would make their machines last longer if this could be invoked if the on off button ever did fail.

Perhaps this button really is fine and I, and the others who have mentioned this, are concerned over nothing.

[Cottser]

Originally Posted by FJames

Something that would really make the Shortlist/Recommended bar at the bottom of the Home page more useful: I'd like to be able to drag and drop a book there from the "most recent 5" shown above, i.e., just like the Favorites bar works in iOS/WebOS/Android. I want to touch and hold until I get some visual indication that drag mode is activated, then drag it to the Favorites bar and drop it there. I would use this when I've just downloaded a couple of new books and there's one I particularly want to read soon.

This is asking way too much out of the eInk screen on a Kobo Touch (or any similar device on the market). The delay in screen response would make this more frustrating than anything.

[bart34]

Both clock and battery charge indicators are in the system but neither are displayed in 'sleep' mode or while reading. How difficult would that be? Maybe at the foot of the page in the corners of the page number bar?

[BensonBear]

Originally Posted by Cottser

This is asking way too much out of the eInk screen on a Kobo Touch (or any similar device on the market). The delay in screen response would make this more frustrating than anything.

Are you saying the delay to distinguish this gesture from a tap would be too much? I don't think so, since that is already used for bookmarking, and it is not a factor of responsiveness of eInk but rather just the need to distinguish the gesture from a tap.

So you must be referring to the dragging of the book cover. But this sort of dragging is already done for pdfs, on a much larger scale (the entire page) and required much more frequently (at least twice a page while reading).

I therefore assume you strongly endorse my request to make this unnecessary by default when reading pdfs, by implementing a decent page-tap-to-advance command?

Frankly, I think dragging and dropping a book cover is really not so bad, although the command is a totally minor cosmetic one which should be way way down on the priority list.

PDF reading is CRUCIAL. Zillions and zillions of things are in pdf, pdf that cannot be converted to epub because it has headers, footers, footnotes, margin notes. I am looking into trying to automatically strip headers and footers with regularity, but handling footnotes is going to be much harder.

PDF reading. PDF reading. Its easy to radically improve this crucial feature. Please. Give me the source to nickel, I will do it for you in a day.

[BensonBear]

When one reads a paper book, one often has to check something somewhere else in the book. To do this, one typically does something like putting one's finger in the book at the current location, to enable searching around in the rest of it.

One can then flip back and forth between two sections in different spots, reading parts of both of them until the connection between them is established or re-established in one's mind. Then one returns to reading as normal.

This should be possible in an ebook also. The process would be:

1) set temporary bookmark
2) look around at will using any technique available (including even switching books)
3) toggle back and forth between current location and temporary bookmark
4) when done, cancel temporary mark and return to reading.

This requires two new commands for steps 1,3,4: "toggle temporary bookmark" and "swap temporary bookmark and current location".

This is easy to implement, and very important in a typical person's reading.

[The Terminator]

The biggest problem for me is not having top margins right now. I've delayed reading side-loaded books for over a month now because of it.

[Xennex1170]

Originally Posted by BensonBear

...

So you must be referring to the dragging of the book cover. But this sort of dragging is already done for pdfs, on a much larger scale (the entire page) and required much more frequently (at least twice a page while reading).

I therefore assume you strongly endorse my request to make this unnecessary by default when reading pdfs, by implementing a decent page-tap-to-advance command?

Frankly, I think dragging and dropping a book cover is really not so bad, although the command is a totally minor cosmetic one which should be way way down on the priority list.

...

Unfortunately dragging a bookcover is a lot more processor intensive than you might think at first. I would imagine it would involve moving an image 'layer' containing the bookcover you want to move (in one of 5 sizes to boot) and constantly refreshing the bottom display 'layer' as you drag so that you don't end up just erasing everything in the path of the drag while moving the bookcover 'layer'. In comparison the PDF is moved on a single 'layer' that refreshes areas newly 'displayed'. If you have another concept for implementing that function it would be interesting to hear.

[BensonBear]

Originally Posted by Xennex1170

Unfortunately dragging a bookcover is a lot more processor intensive than you might think at first. I would imagine it would involve moving an image 'layer' containing the bookcover you want to move (in one of 5 sizes to boot) and constantly refreshing the bottom display 'layer' as you drag so that you don't end up just erasing everything in the path of the drag while moving the bookcover 'layer'. In comparison the PDF is moved on a single 'layer' that refreshes areas newly 'displayed'. If you have another concept for implementing that function it would be interesting to hear.

No, I can't speculate about such a thing without knowing more details about the specific hardware, and to me the whole point is very moot anyway. I think we should be avoiding the need to do dragging as much as possible; it is never going to be that good on this hardware. (Take a look at the tetris game for example of attempts to move a small object and refresh nicely in real time).

Hence my request (the whole point of my original post) to make a reasonable tap-page-to-advance command for pdfs in zoomed landscape mode which requires no dragging. To do this is not something requiring any specialized aspects of this hardware at all and I believe it would improve the Kobo Touch immensely for lots of people trying to read pdf books.

[Gray_Mouser]

Originally Posted by BensonBear

Already we do not have to use it to turn off or go to sleep mode, because we can do that in software via the tweak provided by Andreas Heider.

How do you do that? I've been looking for this piece of information for the last 20 minutes, but without success...

[robko]

Originally Posted by Gray_Mouser

How do you do that? I've been looking for this piece of information for the last 20 minutes, but without success...

You'll find the details in this thread:

https://www.mobileread.com/forums/sho...d.php?t=163997

[Xennex1170]

Originally Posted by BensonBear

No, I can't speculate about such a thing without knowing more details about the specific hardware, and to me the whole point is very moot anyway. I think we should be avoiding the need to do dragging as much as possible; it is never going to be that good on this hardware. (Take a look at the tetris game for example of attempts to move a small object and refresh nicely in real time).

Hence my request (the whole point of my original post) to make a reasonable tap-page-to-advance command for pdfs in zoomed landscape mode which requires no dragging. To do this is not something requiring any specialized aspects of this hardware at all and I believe it would improve the Kobo Touch immensely for lots of people trying to read pdf books.

Actually I was responding to your remark about how dragging and dropping a book cover was not such a bad idea.. As an algorithm I thought what I detailed was a pretty good summation of how it would work regardless of hardware/software. I'm curious as to how you thought drag-and-drop would work.

Originally Posted by BensonBear

Frankly, I think dragging and dropping a book cover is really not so bad, although the command is a totally minor cosmetic one which should be way way down on the priority list.

[aerosol_grey]

Originally Posted by FJames

Something that would really make the Shortlist/Recommended bar at the bottom of the Home page more useful: I'd like to be able to drag and drop a book there from the "most recent 5" shown above, i.e., just like the Favorites bar works in iOS/WebOS/Android. I want to touch and hold until I get some visual indication that drag mode is activated, then drag it to the Favorites bar and drop it there. I would use this when I've just downloaded a couple of new books and there's one I particularly want to read soon.

Rather than drag and drop (and thus avoiding all the arguments over it's worth) would it not be more useful for a long press on the cover to bring up the books library sub-menu? That way you could also mark the book as read, delete it, mark it as unread (please add this!!!) etc. Long-pressing already exists and the sub-menu popup exists in the library listing, so this should be fairly easy to add...

[BensonBear]

Originally Posted by aerosol_grey

Rather than drag and drop (and thus avoiding all the arguments over it's worth) would it not be more useful for a long press on the cover to bring up the books library sub-menu? That way you could also mark the book as read, delete it, mark it as unread (please add this!!!) etc. Long-pressing already exists and the sub-menu popup exists in the library listing, so this should be fairly easy to add...

Yes, a menu is a better idea, and it could have other things in it too, such as eventually the option to open up the shelves menu to place the book on a specific shelf rather than the short list. As it is now, should you enable the shelves, you will find (unless you find something I could not) that the only way to add a book to a shelf is to go to an edit shelves page and then page through your entire list of books until you find the book you want! You cannot be AT a book for some other reason and add it directly to a shelf. (Of course the problem of finding the shelf given the book also arises, but it should be handled better -- with a search in shelf names for example).

Dragging anything on a system like this is really a pain and other techniques are almost always to be preferred.

[BensonBear]

Originally Posted by Xennex1170

Actually I was responding to your remark about how dragging and dropping a book cover was not such a bad idea.. As an algorithm I thought what I detailed was a pretty good summation of how it would work regardless of hardware/software. I'm curious as to how you thought drag-and-drop would work.

Why? I don't see the point of discussing this. Details of the hardware and software do make a big difference on how this would be done and what it would look like, and we (at least I) don't know the details of this hardware so as I said we are just speculating.