Page numbers (again)

[Jellby]

Originally Posted by HarryT

But the pages aren't "fixed". Eg, jump to any hyperlink on the Gen3 and the jump destination ends up at the top of the page. You finish up with a different page start to what you'd have if you went there a page at a time.

Yes, that's why I said than page numbers would only be accurate to +/-1 at most. I don't think I'd need page numbers "per se", but some better estimation of how much I have read and how much I still have to read (until the end of the book, end of the story, end of the chapter...). Seeing the progess bar is at ~75% is something, but does not tell how many "pages" or "screens" (in the current font and layout settings) that means, and that's what I would need to have the feeling of "how much" I have to read.

I'd also like to point out that knowing the length of the story or chapter does not affect my enjoyment of it, but it tells me whether it's worth to start reading it today or wait until tomorrow, if I should stop here and go to sleep or wait until I finish it, etc. In my PDFs I add a progress bar for each chapter in addition to the global one, and I find it very useful.

[Prospect]

As far as I can see page or paragraph numbering is not a feature supported natively in the epub format.

However Adobe has designed a add-on feature to the format that would support page numbers set by the publisher. For further details see the EPUB Best Practices Guide published by Adobe (requires an epub reader)

Further a survey sponsored by the Open eBook Forum (now IDPF?) of 2002 shows that page numbering is the no 6th most wanted feature of for ebooks. What kind of numbering is not mentioned.

[JSWolf]

Originally Posted by HarryT

That's why, though, when you add new books to the Sony it grinds away for a minute or so when you first open the book, or first select a new font size - it's paginating the book. Mobi devices don't do "real" pagination.

Unless of course you use eBook Library to add content. The pagination is done by the computer and the info stored on the Sony so it doesn't have to figure it out.

[jgray]

Prospect, I was just reading the epub guide last night. While I am glad that Adobe has a mechanism to do the numbeing (and a few other extensions to epub), I am leary of using such extensions. If you use them, you're epub is no longer standard, but proprietary Adobe. I don't know whether Adobe is simply trying to address some of the current epub shortcomings, or if they are trying to pollute the standard and drive customers to their own solutions. (Paranoia mode on) Perhaps they are even doing this to force future versions of the epub spec to include their way of doing things, instead of some other way, which may be better.

[delphidb96]

Originally Posted by jgray

Prospect, I was just reading the epub guide last night. While I am glad that Adobe has a mechanism to do the numbeing (and a few other extensions to epub), I am leary of using such extensions. If you use them, you're epub is no longer standard, but proprietary Adobe. I don't know whether Adobe is simply trying to address some of the current epub shortcomings, or if they are trying to pollute the standard and drive customers to their own solutions. (Paranoia mode on) Perhaps they are even doing this to force future versions of the epub spec to include their way of doing things, instead of some other way, which may be better.

Witness the frustration of Cybook owners over how page-numbering (isn't) implemented in their Boo Reader. It's pretty obvious, from tests others have recently conducted, that Bookeen specifically implemented a page-numbering algorithm that was supplied by Mobipocket as both Mobi and Boo fail to handle certain page-jumping (Go To Page) improperly.

Now does Bookeen break from the Mobipocket 'standard' and implement a correct page-numbering algorithm - and hope Mobi's standards don't change - or do they stick with what Mobi has decreed?

Derek

[tompe]

Originally Posted by delphidb96

Now does Bookeen break from the Mobipocket 'standard' and implement a correct page-numbering algorithm - and hope Mobi's standards don't change - or do they stick with what Mobi has decreed?

Why do you think there is a MobiPocket standard? Do you have a web page reference documenting this standard?

[delphidb96]

Originally Posted by tompe

Why do you think there is a MobiPocket standard? Do you have a web page reference documenting this standard?

Ummm... Earth to tompe. Did you not notice my single-quotes around the word "standards"? That implies that any 'standard' exists within the mindset of Mobipocket, the corporation - NOT an officially recognized standard with an international standards committee.

Derek

[tompe]

Originally Posted by delphidb96

Ummm... Earth to tompe. Did you not notice my single-quotes around the word "standards"? That implies that any 'standard' exists within the mindset of Mobipocket, the corporation - NOT an officially recognized standard with an international standards committee.

I missed the single quotes. Should you not use double quotes for this or can you choose which one to use?

[Halk]

Can't we just say that there's no absolute reason why page numbers need to exist, however some people would like them, for very justifiable reasons? .... and then leave it at that?

[Prospect]

The question is not if there should be numbering but how the numbering should be.

I think I have reached the conclusion that in order for the numbers to work as a reference they would have to be embedded by the publisher in the markup. Since one ebook typically consists of more than one html file a reference file would probably be necessary like in Adobes approach. It all looks more complicated than first anticipated.

One questions that remains is if there are alternatives to page numbering when referring to the length of a text. So far this has not been commented by anyone.

[jgray]

I was going to add further to this discussion, but it is getting too heated and personal. So, to avoid being attacked myself, I'm going to stay out of it.

[JSWolf]

Originally Posted by Prospect

The question is not if there should be numbering but how the numbering should be.

I think I have reached the conclusion that in order for the numbers to work as a reference they would have to be embedded by the publisher in the markup. Since one ebook typically consists of more than one html file a reference file would probably be necessary like in Adobes approach. It all looks more complicated than first anticipated.

Sony doesn't embed page numbers in BBeB. BBeB is paginated. But there are no preexisting page numbers before this. So it can be done with Mobipocket if they want to also paginate.

[Madam Broshkina]

Originally Posted by HarryT

I personally regard page numbers as an artifact of paper books which have no place in the eBook world. All I really want is an easy indicator of how far through a book I am, and the Gen3's "progress bar" is a perfectly satisfactory method of showing that. That's just a personal view - I know that not everyone will agree.

If ebooks do not need page numbers then print books should not need them either. It is pretty easy to figure how far your into a book by looking at it. If the right half of the book has a lot more pages then the left side you are closer to the beginning of the book. If the left side has a lot more pages then the right side you are closer to the end of the book. I think that an ebook should approximate an printed book as much as possible. As long as printed books have page numbers so should ebooks.

[Peter Sorotokin]

Originally Posted by jgray

While I am glad that Adobe has a mechanism to do the numbeing (...), I am leary of using such extensions. If you use them, you're epub is no longer standard, but proprietary Adobe. I don't know whether Adobe is simply trying to address some of the current epub shortcomings, or if they are trying to pollute the standard and drive customers to their own solutions. (Paranoia mode on) Perhaps they are even doing this to force future versions of the epub spec to include their way of doing things, instead of some other way, which may be better.

We are trying to address the shortcomings. We had to do that because certain vendors needed page numbers and simply could not use EPUB without that feature. We will work with IDPF to standardize it. And if you know a better way, I'd like to hear about it.

Some requirements for page numbers that we found to be important:

• page number to content mapping is the same for all devices, viewport and font sizes
• getting the page count and navigating to a particular page does not require reading software to parse complete book content
• reasonable default should be defined for EPUBs without any page information specified
• page map info is easy to add as a post-processing step
• named pages are supported (e.g. "iii" or "B-7"), not only numbered pages.
• (nice to have) page breaks for multiple editions can be supplied in the document

[jgray]

Peter, thanks for coming here to post. I didn't expect an official reply from anyone at Adobe on this.

Just to be clear, I'm not anti-Adobe. It is just that I think it is always risky implementing things that are outside of a standard that you are trying to use (especially one as new as epub). It is also easy to be wary of any large corporation and their motives. I'm not saying that this is the case with Adobe in this situation. But with the track record of most software companies, you get a bit skittish after a while.

I admit that Adobe has certainly added some needed functionality, even if it is non-standard. Hopefully these issues will be addressed very soon by IDPF and the standard can be updated. Just to satisfy my curiosity, was there any IDPF input or discussion on the Adobe extensions, or are they all Adobe's idea?

Again, I'm sure we all appreciate the fact that you came here to clarify things.