Glo Inaccurate page count...

[eXistenZ]

Originally Posted by CatherineStewart

...I like total book page count and would rather it be accurate per page turn not characters per page. I wonder if there is another work around? Not a big deal but would be nice.

Thin not make sense, if 1 page=1 screen then changing font size or line height or margins changes the amount of text in a screen/page and of course this also changes the total pages number on the same ebook which can be 100, 200 or XXX pages depending on the reader model and settings, this makes page number totally useless as reference. Also the question "how many pages is long this ebook?" would be impossible to be replied precisely.

On the other and a fixed 1000 characters=1 page makes the page number a useful, stable reference, whatever are the settings you are using to read.

[CatherineStewart]

It makes perfect sense to me. I don't need page numbers for any referencing other than to tell me how many more pages *I* have left to read at my font size settings. Don't really care how many pages "the book" has but for me I'd like to know how many page turns I have left. But that's just me.

[DNSB]

Originally Posted by CatherineStewart

It makes perfect sense to me. I don't need page numbers for any referencing other than to tell me how many more pages *I* have left to read at my font size settings. Don't really care how many pages "the book" has but for me I'd like to know how many page turns I have left. But that's just me.

And given that even in print books, the page number vary all over the place -- hard cover, paperback, large print, 1st, 2nd, however many editions-- they are useless for most purposes anyways. "Sir, page 427 in my copy of Whosit and Whatsit's Introduction to Chordate Anatomy does not mention notochords" as a real life example from a few years back.

Generally, I just use the % read as my guide to how much is left in an ebook.

Regards,
David

[guma]

Originally Posted by eXistenZ

Thin not make sense, if 1 page=1 screen then changing font size or line height or margins changes the amount of text in a screen/page and of course this also changes the total pages number on the same ebook which can be 100, 200 or XXX pages depending on the reader model and settings, this makes page number totally useless as reference. Also the question "how many pages is long this ebook?" would be impossible to be replied precisely.

... you could answer the question: how many screens remain? ... which is precisely what some people want to know. And, unless you change font and margin settings significantly per book, the number of screens should give you a pretty good idea about how long a book is.

Displaying the number of screens would also be similar to the common practice of (non scientific) printed books where editions/versions are typically not identical regarding page counts.
And for some people the cognitive dissonance between page (screen) turns and displayed page numbers is somewhat disturbing/annoying.

Originally Posted by eXistenZ

On the other and a fixed 1000 characters=1 page makes the page number a useful, stable reference, whatever are the settings you are using to read.

The actual ADE standard as used by KOBO is not as informative/stable as it seems at first glance as a reference since it is referring to the number of bytes in the compressed epub source file rather than to a count of displayed characters. Thus reformatting an epub might change this page count to some degree and the 'fixed' reference is only fixed with regards to one (unaltered) version of an epub. How many characters you will actually see on a displayed 'page' actually depends significantly on the formatting style implemented when the epub was created.

[DNSB]

Originally Posted by guma

The actual ADE standard as used by KOBO is not as informative/stable as it seems at first glance as a reference since it is referring to the number of bytes in the compressed epub source file rather than to a count of displayed characters. Thus reformatting an epub might change this page count to some degree and the 'fixed' reference is only fixed with regards to one (unaltered) version of an epub. How many characters you will actually see on a displayed 'page' actually depends significantly on the formatting style implemented when the epub was created.

I've played with reformatting an epub and changes in font size, line spacing and margins using a stylesheet don't seem to have much of an effect on the page numbers displayed. Recompressing the epub using an external archiver does have an effect as does changing the contents of the chapter files to modify the styles.

Still, I generally keep the page numbers in right margin turned off as I find them pretty useless.

Regards,
David

[DomesticExtremis]

Originally Posted by guma

... you could answer the question: how many screens remain?
.

I think a lot of money could be made by whoever gets that algorithm right.

[guma]

Originally Posted by DomesticExtremis

I think a lot of money could be made by whoever gets that algorithm right.

showing the number of screens based on current settings? this is quite a common feature. take a look at any word processing software. some e readers too already can do it (including open source os like e. g. open ink pod....)

[PeterT]

If only it was that simple. Remember, that in order to do that, the eBook reader would have to process the entire book using the current settings, decompressing each and every compressed element in the book, running it through the rendering engine, and then, whenever a change was made in the formatting selected by the user (different font, different size, margin changes) this whole process would have to be repeated.

The current approach while not precise is quick and easy to compute in that all that is needed is access to the directory of the ePub file.

[guma]

Originally Posted by PeterT

If only it was that simple. Remember, that in order to do that, the eBook reader would have to process the entire book using the current settings, decompressing each and every compressed element in the book, running it through the rendering engine, and then, whenever a change was made in the formatting selected by the user (different font, different size, margin changes) this whole process would have to be repeated.

If my old bebook one reader running an open source operating system (open inkpod) could do it perfectly fine (recomputing the page count after setting changes was fairly fast) I can't see any reason why current devices with their much faster processors should not be able to.

[guma]

Originally Posted by DNSB

I've played with reformatting an epub and changes in font size, line spacing and margins using a stylesheet don't seem to have much of an effect on the page numbers displayed. Recompressing the epub using an external archiver does have an effect as does changing the contents of the chapter files to modify the styles.

I would argue that even small differences somehow invalidate the 'fixed reference' argument. What's the use of a 'not really fixed but probably pretty close' (pseudo-) page reference?
Additionally, from my experience, the html formatting styles used in books from different sources make a rather significant difference (+/- 30%) with regards to the amount of actually displayed characters per ADE 'page'. This weakens the argument that these page counts can be used to compare the length of books.

Thus the ADE page convention looks, to me, like a rather weak standard that is anyway restricted to a specific file format and used on a small number of devices.

... and I personally do not like it anyway since I prefer my e-reader to simulate paper books as close as possible and expect the page number to increase whenever I 'turn a page' :-)

[TechniSol]

No offense intended to anyone's desires, but it seems there is no really proper way to do this without things getting rather involved, as has been pointed out by others. Further, there is no true reference as to what is correct, as published editions have differing page numbers depending on format, type style and font size.

All that said, an option to display a new page number for each page worth of type displayed may not be the worst option(I get how it can be disconcerting to flip the page several times and still be on the same page number according to the reader), but it further confuses annotations, etc which would still have to be based on a type size independent format to maintain the location. Maybe it'd be less efficient, but if they counted annotation locations based on how many words they are into a chapter, they'd only have to store chapter number plus chapter word count? Could get rather wasteful depending on how long a chapter might be and vary from work to work. My guess is that's why they went with a likely arbitrary, but easy to work with number for computers like 1024.

I suppose some standard must exist, and frankly it is little enough to stand a page number not changing through a few screens of text in order to be able to cart a library that I can read in conditions varying from full sunlight to complete darkness around in my pocket!

Now if they'd just make it as handy in terms of being a virtual moleskin notebook... preferably one that downloads into a word processor, publishing program, CAD and schematic package and cleans my lines up at the same time. Spellchecker, grammar, and CAD that knows what I want rather than what I told it to do.

[davidfor]

Originally Posted by TechniSol

No offense intended to anyone's desires, but it seems there is no really proper way to do this without things getting rather involved, as has been pointed out by others. Further, there is no true reference as to what is correct, as published editions have differing page numbers depending on format, type style and font size.

And that's why I am reasonably happy with percentage read plus an idea of how big.

All that said, an option to display a new page number for each page worth of type displayed may not be the worst option(I get how it can be disconcerting to flip the page several times and still be on the same page number according to the reader), but it further confuses annotations, etc which would still have to be based on a type size independent format to maintain the location. Maybe it'd be less efficient, but if they counted annotation locations based on how many words they are into a chapter, they'd only have to store chapter number plus chapter word count? Could get rather wasteful depending on how long a chapter might be and vary from work to work. My guess is that's why they went with a likely arbitrary, but easy to work with number for computers like 1024.

You almost got the annotations right. They are stored as walk of the tags. The annotation position is unrelated to the page numbers. Effectively, it is a count of how many paragraphs from the beginning of the file and then the number of characters within the paragraph. The complication to it is because of nested tags and non-paragraph tags. Plus if the chapter doesn't start at the beginning of a file.

[TechniSol]

Percentage read is probably the best way to go, but for many I suspect it is so "unbooklike" as to offend a significant segment. Personally, other than being able to refer back to something I'd just be happy with what chapter I'm in most of the time.

Didn't think I was even close as to the particulars of annotation math, I was just pointing out a possible method and that it had to be independent of font size and page constraints. So you're saying that annotations must also track which files they refer to or be stored as part of the files, as well as how many paragraphs and words in from the top of file they are. Reasonable enough.

I think some people are going to have to get used to the idea that every little feature they'd prefer is not necessarily model-able, or may just be too big a resource hog or take to long to execute while people are waiting. Granted there may be a way to beat most constraints if the engineer is willing/able to put enough brainsweat into doing it, but not always and you always have to trade one thing off for another -it's the main difference between dreaming and engineering...

[davidfor]

Originally Posted by TechniSol

Percentage read is probably the best way to go, but for many I suspect it is so "unbooklike" as to offend a significant segment. Personally, other than being able to refer back to something I'd just be happy with what chapter I'm in most of the time.

"Unbooklike" is correct. I only realised I had sort of converted to percentage during one of the recent discussions on this. The Kobo readers show it enough that it eventually takes hold.

Didn't think I was even close as to the particulars of annotation math, I was just pointing out a possible method and that it had to be independent of font size and page constraints. So you're saying that annotations must also track which files they refer to or be stored as part of the files, as well as how many paragraphs and words in from the top of file they are. Reasonable enough.

That's about it. The annotations are stored outside the books. For epubs it is in the database and a separate file that ADE creates. An example is "OEBPS/Text/chapter015.html#point(/1/4/2/2/2/1:0)". Not a great example as it points to the start of the chapter and it is actually the current reading rather than a bookmark. This format is ADE's. EPUB 3 CFI spec is similar. The calibre viewer uses a method that is similar to epub3.

[TechniSol]

Makes me think life would be much simpler all around if each chapter of the book was always it's own file and had only one chapter heading and contents. Sigil seems to excel at that model and it makes the most sense for anyone using it. It'd be nice if the ereader manufacturers managed to include code to clean up ratty epubs, but frankly why do anything to encourage people not to buy nicely formatted books from their stores? Can't really blame them for that.