Add chapter title and page number info to the book page

[iBelieve]

Something that I liked about iBooks that gave it some polish was displaying the book name and page number info on the book page. So, I've done the same (though using chapter title instead).

[rschroll]

Thanks for the patch. One thing I've wanted is some progress indicator, so it's good to see a page count.

That said, I have some concerns about this approach:

First, the title and page count should look like they're part of the page. But because they're done in QML, they don't get the font, color, or background of the page. While we could imitate this with QML, it seems like it'd be easier to do in HTML. Monocle does have the capacity to add information to each page. (See http://monocle.inventivelabs.com.au/books/dubliners for an example.)

Along these lines, we'd need to figure out how these would interact with the margins. Note that the lower margin should be twice the upper one; the current layout doesn't respect that.

I'm not sold on putting the chapter title at the top of each page.
Part of that could be that lots of my books have chapter titles like "Chapter Four", which isn't so interesting to see. Besides, the current chapter is highlighted in the chapter list, so it's not difficult to find out that.

In a little bit of testing, I've noticed that the total page count jumps around quite a bit on chapter changes. I haven't really understood the code yet, but it seems to be estimating the total number of pages based on a ratio from the current chapter. Why do it this way? Why not to a more careful calculation when the book is opened?
If it's expensive, it could be moved into the cover calculation and stored in the database.

But before we do that, two other ideas:

• Some epubs have pagination information in them (http://blog.safaribooksonline.com/2009/11/26/adobe-page-map-versus-ncx-pagelist/). Should we use that instead?
• Are page numbers even appropriate for ebooks? Perhaps we should show a percentage or progress bar. This could be turned into a control for scrubbing through the text.

I'm also going to comment on some of the code inline. This is just to alert you to the type of things I'm pedantic about. Don't worry about fixing them yet. Let's get a plan of action before putting more code down.

[rschroll]

After some more thought -- this could be something that depends of screen size. On a phone, you probably don't want anything other than text on the page. But on a tablet, you can't (comfortably) fill up the whole screen with text, so we can add these bits to take up some of the room.

Already, we're adjusting the margins to account for this. The left and right margins will grow to keep the width of the text block, in characters, about constant. For the first bit, the top and bottom margins grown in proportion. But these are capped at some value (5 and 10%, I think; the bottom is always twice the top). Past that point, we could add in a header and/or footer.

Are you interested in working on this further?

[iBelieve]

Sorry for the delay - here are my responses to your comments:

• I guess you're right that the chapter isn't very useful. Should I change it to the book title?
• Color and font. I like it being a different font and color since it is really secondary information that shouldn't distract the user from actually reading. It is also the approach taken by iBooks on iOS and the Mac.
• Total page count jumps around - that was a problem I read about while researching how to do this, but didn't realize it was that bad. Switching to a percent seems a good idea. We could also add a Slider widget
• All the code comments - that was a block of code I took out of Monacle, so I hadn't changed it at all. We can remove it anyway if you want to go with the percent.

[iBelieve]

On the phone, you could use the new bottom-edge gesture to bring up the slider to move around in the book, and then on further dragging up, bring up the table of contents. But normally the title and percent could be hidden by default.

[rschroll]

I wanted this to percolate in my mind for a bit, but then I forgot about it. Sorry.

Here are my current thoughts:

• This should only appear above a certain screen size. On a small screen, we want to preserve space as much as possible, but on a larger screen, the extra info is nice. I'm not sure where the cut-off is. Any tablet should have the information; I'm not sure about the phone.
• The chapter name makes sense to display. Sure, it's mostly useless in some books, but the book title and author are even less useful. My initial reaction was due to a worry about space on small screens, but the above item should take care of that worry.
• Having a scrubber to select the page would be nice, but let's save that for another bug. For right now, let's worry just about display.
• The display should be done through the HTML, so the style is the same as the main text. We can play with little styling choices (small caps, italics, etc.) to make it stand out. But we don't want these things to be light-on-dark if the user has chosen a dark-on-light scheme.
• I'm not adverse to doing an expensive operation to get the page count correct. On devices, we can cache that result, so it's only done once. On the desktop, we'd need to rerun it when the window size changes, but we have cycles to spare.
  • We could also do the calculation as the user's going through the book. As each new component is entered, we cache to the total up to that point and use it to set the offset from the beginning of that component. We won't be able to display the total page figure, but that's less important. We would have to deal with what happens when the user jumps to the middle of a book before reading through the beginning, though.
  • We could number pages in a way other than consecutive numbers. For instance, we could do <component #>.<page #>. Since there's generally a mapping between components and chapters, this might actually be useful in some cases.
  • We could show a percentage.
  • We could show a page count based on some arbitrary page size; say 1 kB. This has the advantage that the page number won't change when you resize the viewer. The down side is that what's displayed doesn't map to a single page. (This is how my Sony Reader works.)

Let me know if this seems reasonable and if I can help point you in the right direction on implementation.