ePub and number of page

[Peter Sorotokin]

Originally Posted by GeoffC

Confusing when on the one hand we discover Adobe's "ePub best practice" that mentions the use of PageMap, and then a couple of posts including Do not use page mapping on epubcheck stating the OPF specs do not allow PageMap to be used.

Implying that only ADE will allow use of the page map....

So much for a 'standard' .....

Adobe had to solve page number issue (and put page numbers on the margin) for business reasons. Our position is that page map is a practical solution to existing problem. It will be supported in the future. Other renderers are free to use it as well. In the future NCX syntax will probably be "blessed" for the same purpose, but currently it is not. Once NCX page map syntax is officially part of the standard, Adobe viewer will support it in parallel to existing page map syntax.

Jon's message that you referred to is Jon's opinion (not IDPF position) and I think he misrepresents many things. I saw a variation of this message in so many places that I am just unable to go to each one and rebuke it.

In a nutshell: yes, it is non-standard extension and it won't validate (being an extension); no, it won't be dropped; no, it won't cause problems in any other viewer; no, there is no standard way of doing it (even though alternative syntax does validate, that usage of NCX is not "blessed" in the spec); no, there is no other viewer that implements NCX syntax for pages at this point.

[JSWolf]

Just to note, Peter does not mean me.

[Xenophon]

Originally Posted by Peter Sorotokin

Adobe had to solve page number issue (and put page numbers on the margin) for business reasons. Our position is that page map is a practical solution to existing problem. It will be supported in the future. Other renderers are free to use it as well. In the future NCX syntax will probably be "blessed" for the same purpose, but currently it is not. Once NCX page map syntax is officially part of the standard, Adobe viewer will support it in parallel to existing page map syntax.

Jon's message that you referred to is Jon's opinion (not IDPF position) and I think he misrepresents many things. I saw a variation of this message in so many places that I am just unable to go to each one and rebuke it.

In a nutshell: yes, it is non-standard extension and it won't validate (being an extension); no, it won't be dropped; no, it won't cause problems in any other viewer; no, there is no standard way of doing it (even though alternative syntax does validate, that usage of NCX is not "blessed" in the spec); no, there is no other viewer that implements NCX syntax for pages at this point.

OK, Peter, that explanation is just fine and dandy. Now... Can you force (or at least very strongly encourage) your ADE Mobile licensees to provide an option whereby the display of the little marginal page number can be TURNED OFF!!!! Page numbers that overlap the displayed text are really, REALLY, REALLY annoying! And I resent the idea of having to waste some of my very limited screen real-estate just to stay clear of the &^%$&^%$&^*% page number.

The concept of these page numbers seems just fine to me. But the implementation (as embodied in currently available Sony readers) is absolutely maddening! I can already see the page number in the information bar at the bottom of the screen. So why oh why must I have it "in the margin" -- especially when my preference is to get rid of the &^%*&^% margin anyway.

Thanks for you attention and sorry for the heated language above. This is one of the persistent nits that's particularly annoying with an otherwise quite nice device and display software. (Decent hyphenation support would be the next thing on my list, btw.)

Xenophon

[DaleDe]

Originally Posted by frabjous

Different software definitely puts these in different places for ePubs that don't contain a page map. Actually, the details are given in the thread I linked to above.

An eBook page is typically smaller than an Adobe page. Some eBook readers support the idea of a subpage while others do not. The outcome is that the page can be slightly different place depending on which subpage you are on. It is also possible I suppose to be one page off depending on where on the page the actual break occurs and how the rendering engine treats it. There is also a possible difference in how some readers due arbitrary breaks of pages based on buffering limits. (I have not seen this in actual practice however.)

Dale

[frabjous]

Originally Posted by DaleDe

An eBook page is typically smaller than an Adobe page. Some eBook readers support the idea of a subpage while others do not. The outcome is that the page can be slightly different place depending on which subpage you are on. It is also possible I suppose to be one page off depending on where on the page the actual break occurs and how the rendering engine treats it. There is also a possible difference in how some readers due arbitrary breaks of pages based on buffering limits. (I have not seen this in actual practice however.)

Dale

I was actually referring to the claim--made by you, actually, in the thread I linked above--that whereas ADE puts these in every 1024 chars, FBReader does every 2048, and so on. Is that not right?

[kennyc]

Originally Posted by frabjous

I was actually referring to the claim--made by you, actually, in the thread I linked above--that whereas ADE puts these in every 1024 chars, FBReader does every 2048, and so on. Is that not right?

For the same file? And they are both ADE implementations?

I thing FBReader may not be ADE, but it may be adding the pages to 'emulate' it but do it it's own way.

[DaleDe]

Originally Posted by frabjous

I was actually referring to the claim--made by you, actually, in the thread I linked above--that whereas ADE puts these in every 1024 chars, FBReader does every 2048, and so on. Is that not right?

That is correct to my knowledge but that is not what I was talking about. An ADE page of 1024 characters is more than a screen, sometimes 4 or even more screens depending on the font size. These screens are referred to a subpages and some readers include the subpage as part of the page number and some do not. So the screen contents can be different depending on which subpage you are referring to. The ADE page boundaries should the same place if you line up the page number with the text.

Dale

[wallcraft]

Originally Posted by kennyc

I thing FBReader may not be ADE, but it may be adding the pages to 'emulate' it but do it it's own way.

FBReader implemented page numbers before ADE existed. It copied the approach from an existing Reader app (but I don't remember which one). FBReader's definition, from a post by geometer at FBReader Google Group:

At the moment the "page" definition is:
1) page contains 2048 characters
2) each image is counted as 100 characters
3) if the forced page break is occured (e.g., at the end of a book section), the next page is started from this place indepently from the value of "counter"

The same definition is used for all ebook formats.

[kennyc]

Originally Posted by wallcraft

FBReader implemented page numbers before ADE existed. It copied the approach from an existing Reader app (but I don't remember which one). FBReader's definition, from a post by geometer at FBReader Google Group: The same definition is used for all ebook formats.

Ah! Thanks.

[Peter Sorotokin]

Originally Posted by Xenophon

OK, Peter, that explanation is just fine and dandy. Now... Can you force (or at least very strongly encourage) your ADE Mobile licensees to provide an option whereby the display of the little marginal page number can be TURNED OFF!!!! Page numbers that overlap the displayed text are really, REALLY, REALLY annoying! And I resent the idea of having to waste some of my very limited screen real-estate just to stay clear of the &^%$&^%$&^*% page number.

Everyone who pays any attention on the manufacturing side has gotten that point across. In the upcoming Reader Mobile SDK there is an API to show/hide those. I think eventually on most devices it will either be off or switchable. But it will take some time to filter down.

[HarryT]

Originally Posted by Peter Sorotokin

Everyone who pays any attention on the manufacturing side has gotten that point across. In the upcoming Reader Mobile SDK there is an API to show/hide those. I think eventually on most devices it will either be off or switchable. But it will take some time to filter down.

Thanks, Peter; that's excellent news.

[Sweetpea]

Originally Posted by Peter Sorotokin

Everyone who pays any attention on the manufacturing side has gotten that point across. In the upcoming Reader Mobile SDK there is an API to show/hide those. I think eventually on most devices it will either be off or switchable. But it will take some time to filter down.

It might make start using epub. I tried the format when I got my reader but got highly annoyed at that page number. (though the lack of a top and bottom margin may keep me at mobipocket...)

[GeoffC]

Peter many thanks for the clarification on the issue of page numbers.
What I am most concerned about is that a standard has to be agreed and then maintained; we have to draw the line somewhere and the sooner the better for consistency, especially as the number of e-readering devices continues to increase.

[kennyc]

Originally Posted by Peter Sorotokin

Everyone who pays any attention on the manufacturing side has gotten that point across. In the upcoming Reader Mobile SDK there is an API to show/hide those. I think eventually on most devices it will either be off or switchable. But it will take some time to filter down.

Wonderful!

[Valloric]

Originally Posted by Peter Sorotokin

Everyone who pays any attention on the manufacturing side has gotten that point across. In the upcoming Reader Mobile SDK there is an API to show/hide those. I think eventually on most devices it will either be off or switchable. But it will take some time to filter down.

This alone has just made my week. Thanks to Peter and the whole Mobile SDK team. Now if only Sony could just push the new SDK version to PRS-505 owners in a firmware update...