ePub - Changing Font size doesn't change page numbers

[dordale]

I noticed on my husband's 700 the bottom will show something like "42-43 of 715" in ePub files while my 505 shows "42 of 715". The way the 700 shows page numbers/location numbers makes the numbering in the right margin absolutely redundant. It'd be nice if there was at least a setting to turn off the right margin numbering, and free up more of the screen for the book.

dordale

[kovidgoyal]

Originally Posted by LoganK

Paragraph numbers can avoid dreaded rendering, but it still requires scanning the contents of the file. Plus, there is the issue of what constitutes a paragraph? A <p> element? A top-level box?

That doesn't matter as long as the algorithm used is consistent.

You would know better than me, but why aren't page numbers related to page rendering? To put it more concretely, how do you figure out what page number a given chapter starts on without rendering all of the previous chapters? What reason, other than calculating page numbers, would you have to pre-render the entire document?

I can open an ePub document much faster than a BBeB file presumably because it isn't processing the entire file up front? Or am I wrong about what's going on behind the scenes?

The reason you can open an epub file faster is because internally it is split into multiple html files and only one html file is prerendered at a time. It is perfectly possible to calculate page numbers without rendering the entire document, it's what calibre does, for example (though in that case they aren't strictly "page numbers")

[LoganK]

Originally Posted by kovidgoyal

The reason you can open an epub file faster is because internally it is split into multiple html files and only one html file is prerendered at a time.

Yes, but the key is that it calculates a page number without having to render the other files. That is a feature that I really like. Even if BBeB books were internally split (they very well could be ... I've never looked), it seems obvious they wouldn't be able to avoid rendering and still have 1 page equal 1 rendered page.

Originally Posted by kovidgoyal

It is perfectly possible to calculate page numbers without rendering the entire document, it's what calibre does, for example (though in that case they aren't strictly "page numbers")

Isn't that what we are talking about here: calculating "page numbers" that don't strictly relate to pages? I don't know where in code the "page numbers" are calculated (so I can't look up the algorithm), but it sounds as though Calibre is doing a similar, not-compatible-with-DE trick. Which is to say that Calibre, when not viewing BBeB files, at least, doesn't pre-render the entire document but also doesn't have a strict page-number-to-rendered-page facility as the original thread was calling for.

For people that are interested in one screen of text being one page, is the tradeoff (slower opening of documents and delays when changing fonts or font sizes) worth it for you?

[LoganK]

Originally Posted by kovidgoyal

That doesn't matter as long as the algorithm used is consistent.

Sorry, there were two issues there. My primary concern was this: if your numbering is based on paragraphs, then you have to open each HTML file before the current file and interpret the contents of the file. You could get around this by using two numbers, internal file number and current-document paragraph number, but then you end up exposing to the user that large chapters are split into multiple files.

I still maintain that Adobe calculating page numbers based on the compressed file size is, by far, the fastest method for calculating "page numbers". It's still up for debate whether or not this method is useful for the person reading.

[kovidgoyal]

If you want 1 page number = 1 screen then there is no alternative to pre-rendering the entire book.

The purpose of page numbers is two fold:

1. They provide a progress indicator

2. They provide a means to refer to specific content

As far as progress indication is concerned, any scheme based on content length as opposed to rendered content length is suitable

As for references, IMO paragraph numbers are far superior, and no, you don't have to prerender the contents to use paragraph numbers as references.

[LoganK]

I'm glad that we seem to be on the same page. I was afraid there was something obvious I was missing.

Originally Posted by kovidgoyal

As for references, IMO paragraph numbers are far superior, and no, you don't have to prerender the contents to use paragraph numbers as references.

You do, however, have to examine the contents of the files which, while perhaps negligible compared to rendering, is still slower than making assumptions based on the file size. Furthermore, the only such system in widespread use is Digital Editions. Not even Calibre uses the paragraph number for its "page numbering". There would have to be a very good reason to throw out a perfectly acceptable system.

Paragraph numbers have the advantage of being far more specific, but they aren't perfect. As mentioned, they are slower to calculate (although the results are easy to cache and the calculation is perhaps so fast as to not matter). I don't normally argue that the speed should be a concern, but it is worth mentioning. I also believe that some publishers will mess up this system by creating documents using tags that don't conform to the definition of a "paragraph" but look perfectly normal when reading. Then there is the possibility that the numbers aren't "human" enough. A 270 page paperback book I have here has 1300 paragraphs, and each page turn on an e-ink device is going to advance the reference number by about 7 or 8. Are readers going to find such large numbers acceptable?

On the other hand, the Bible is a pretty large precedent...

[kovidgoyal]

You're confusing two separate things.

1. Progress indication. For this the use of any contents size based measure is acceptable. I actually think using file sizes is not, since that will give the user inconsistent feedback. A file with a lot of markup and little content will have the same number of "pages" as a file with little markup and lots of content. Instead, the correct approach is to use the length of non-markup content, not the file size.

2. Referencing: To re-iterate, using paragraph numbers of referencing does not require the pre-parsing of all content in the book. And obviously, you wont use a straight number for the paragraph, instead you'd use a compund number of the form section.paragraph #

[LoganK]

Originally Posted by kovidgoyal

You're confusing two separate things.

I'm not. I think we just have different ideas of what's acceptable. I happen to think the shortcut approach is "good enough".

Originally Posted by kovidgoyal

1. Progress indication. For this the use of any contents size based measure is acceptable. I actually think using file sizes is not, since that will give the user inconsistent feedback. A file with a lot of markup and little content will have the same number of "pages" as a file with little markup and lots of content. Instead, the correct approach is to use the length of non-markup content, not the file size.

I recognize this and find it acceptable, but you may be right in that most people would not (which is why I'd love to hear from some other users).

Originally Posted by kovidgoyal

2. Referencing: To re-iterate, using paragraph numbers of referencing does not require the pre-parsing of all content in the book. And obviously, you wont use a straight number for the paragraph, instead you'd use a compund number of the form section.paragraph #

I mentioned such an approach above (twice if you include the indirect reference via the Bible), and I'm still trying to decide if it's acceptable. The first problem I mentioned above: large chapters will be split into multiple sections. I think this will upset most users. Similarly, chapter-less books will have arbitrary section splits. (I'd love to say here that ebook software shouldn't mandate file splits where they don't make sense, but the reality is that there are decently good reasons to do so ... at least with the ePub format.)

Then there's the problem of referencing the section. I'm tempted to say we should simply use the manifest ID, but "fm01.12" is slightly cumbersome.

I could be sold on the idea, but it doesn't seem like enough of a leap over the Digital Editions system to justify throwing out the existing, widespread software. And if we are going to define what a "paragraph" is, then some currently-available content would need to be converted to work with the new system.

[kovidgoyal]

Originally Posted by LoganK

I could be sold on the idea, but it doesn't seem like enough of a leap over the Digital Editions system to justify throwing out the existing, widespread software. And if we are going to define what a "paragraph" is, then some currently-available content would need to be converted to work with the new system.

Since no one even knows what precisely the Digital Editions system is (it's certainly not file size based), this argument is moot. The real motivation for the ADE page based system is the digitisation of paper books that refer to content via page numbers. In fact, ADE supports a system whereby the creator of an EPUB file can specify an arbitrary page map (you can see this in action in calibre. calibre has conversion options to let you create the page map based on XPath expressions for detecting page boundaries). In any case, this is my last post on this subject, there have already been 3 previous discussions on page numbers in e-books and I'm starting to feel like I'm in a zombie movie where fresh waves of zombies just keep coming at me (please don't take offense at the analogy, I don't mean to imply you're a zombie).

[LoganK]

Originally Posted by kovidgoyal

Since no one even knows what precisely the Digital Editions system is (it's certainly not file size based), this argument is moot.

I assumed the algorithm described in the ePub Best Practices document, published by Adobe, was correct. Since I haven't finished implementing it, I can't say whether or not it is correct, but it should be easy to verify. Your comment implies that someone else has already done this, though, and it turned out to not be the case.

Originally Posted by kovidgoyal

The real motivation for the ADE page based system is the digitisation of paper books that refer to content via page numbers. In fact, ADE supports a system whereby the creator of an EPUB file can specify an arbitrary page map (you can see this in action in calibre. calibre has conversion options to let you create the page map based on XPath expressions for detecting page boundaries).

I knew about the page mapping (it's also documented in the Best Practices document), but I wasn't aware that Calibre supported it. Neat!

Originally Posted by kovidgoyal

In any case, this is my last post on this subject,

Thanks for your time (I'm actually surprised that you posted as much as you did).

I was actually kind of hoping that other people would chime in with an opinion, but maybe I was stretching my hope too far in thinking that others would have an opinion on this subject.

Originally Posted by kovidgoyal

there have already been 3 previous discussions on page numbers in e-books

Maybe that is why the others have been so silent. I will try to track them down before going any further down this path.

Thank you, Kovid.

[astra]

Originally Posted by Amalthia

I like the way Sony handles page numbers with the LRF, RTF format already. The numbers really need to be away from the text. I prefer to know I'm page 400 out of 600....the percentages don't mean much to me at all.

LoganK

So you like the concept of the virtual page numbers, but you don't like the idea of embedding the page information within the text.

Applies to me too.
That's why I don't consider any other reader as alternatives to Sony, because they don't have virtual page numbers (maybe BeBook has?)

[radamo]

I too prefer the Sony (lrf) page numbering methodology. I like to know how far along I am in a book. A % complete is next to useless to me because without knowledge of how large the entire document is that fact that I have finished 50% could mean I have 50 screens of text left or 5,000. Without the "page x of y" type of reference I would not have any way to know how much progress I have made into a document or book.

I really don't mind waiting for the calculations to be performed when a book loads or I change font size. I would prefer to have that feedback and it is worth the time invested.
RA

[tompe]

Originally Posted by LoganK

Disadvantages of virtual page numbers:

• Flipping to the next page doesn't increase the number at the bottom by 1

I do not see that this is a disadvantage.

would people be happier with "13.428%" instead of virtual page "190"? (I know Americans generally prefer whole numbers to percentages; I'm not sure about the rest of the world.)

I would not like that at all since you have no idea av the length of 1%. Optimal would be somethink like 156/987 were 987 is the total number of positions. It would be good if one position corresponded to the number of words on a page in a normal paper book.

[radius]

Just wanted to put my two cents in...

I am going to call a page number based on physical, rendered screenfuls of text physical pages. I am going to use virtual pages to mean those where the page number is calculated, stored etc. and do not have a link to the number of rendered screens.

I want the following things from page numbers:

1) Progress indication - how much of the current book have I read versus how much left to read?
- Tie

2) Navigation - skip ahead/back by a number of pages
- Tie; maybe slight edge to physical numbers

3) Book length comparison - how many pages does this book have compared to that book?
- Physical numbers win as long as I stay on the same device and font but I read on multiple devices in many fonts

4) Portability - I want the same page number to represent the same block of text regardless of the device I am reading on and regardless of the text size I am reading at.
- Virtual wins

So for me, its pretty close, but virtual pages win by a tiny margin for me.

[astra]

Originally Posted by radamo

I too prefer the Sony (lrf) page numbering methodology. I like to know how far along I am in a book. A % complete is next to useless to me because without knowledge of how large the entire document is that fact that I have finished 50% could mean I have 50 screens of text left or 5,000. Without the "page x of y" type of reference I would not have any way to know how much progress I have made into a document or book.

I really don't mind waiting for the calculations to be performed when a book loads or I change font size. I would prefer to have that feedback and it is worth the time invested.
RA

And I thought I am weirdo
I am really glad there are people who think the same about page number system of Sony Reader.