[GUI Plugin] Count Pages

[jecilop]

IGNORE OR DELETE POST.
UPDATE: removing original post..I realized my error in what I'm looking at. The #pages column had been off, but got turned on I guess during an update. Now I realize what is happening....so my post doesn't matter....

[theducks]

If the column name is not available to SET in count pages config, then the column is of the wrong type (or the DB is damaged)

[jecilop]

@the ducks.....I've updated my post..I've figured it out...I don't see how I can delete my post in the thread, so I just made it an update to ignore it.
Says:UPDATE: ignore post..I realized my error in what I'm looking at. The #pages column had been off, but got turned on I guess during an update. Now I realize what is happening....so my post doesn't matter....

[Rivanov]

Is it possible to show the counted pages that has been stored in a column in Calibre, on my Kobo Libra H2O?
I don't see the counted pages on the Details page right now.

I use the KoboExtendedDriver (KePub).

[JSWolf]

Originally Posted by Rivanov

Is it possible to show the counted pages that has been stored in a column in Calibre, on my Kobo Libra H2O?
I don't see the counted pages on the Details page right now.

I use the KoboExtendedDriver (KePub).

Go to to the settings for the KoboTouchExtended Driver.

Go to the Metadata, on device & advanced tab

check Book stats

For Words, click Template Editor. Put in

program:floor($$#words)

For Pages, click Templace editor and put in

program:floor($$#pages)

#words and #pages are my columns. Put in whatever your columns are named.

[Rivanov]

Originally Posted by JSWolf

Go to to the settings for the KoboTouchExtended Driver.

Go to the Metadata, on device & advanced tab

check Book stats

For Words, click Template Editor. Put in

program:floor($$#words)

For Pages, click Templace editor and put in

program:floor($$#pages)

#words and #pages are my columns. Put in whatever your columns are named.

Thank you very much! Will try this!

[Comfy.n]

hey @kiwidude, hope you're fine.

i see this on the Wiki:

Alternatively in the configuration you can choose to use the page count used by the calibre e-book viewer

Is it actually possible that Count Pages can retrieve the same number of pages displayed in the Viewer header? Currently, it doesn't seem to do so. Perhaps the algorithm has been changed?

[JSWolf]

Originally Posted by Comfy.n

hey @kiwidude, hope you're fine.

i see this on the Wiki:

Alternatively in the configuration you can choose to use the page count used by the calibre e-book viewer

Is it actually possible that Count Pages can retrieve the same number of pages displayed in the Viewer header? Currently, it doesn't seem to do so. Perhaps the algorithm has been changed?

I second that the page count for the calibre viewer is not getting the correct number.

[Comfy.n]

Originally Posted by JSWolf

I second that the page count for the calibre viewer is not getting the correct number.

thanks!

[kiwidude]

Certainly calibre changed in the last 12 years to using a different algorithm. Kovid was kind enough to point to the code that is generating that for the ebook viewer, the problem I have at the moment is it requires parsing the book in a different way than the plugin does currently.

I will see if Kovid has any suggestions that may help with implementing his way of processing the ebook to see if I could reuse his actual viewer code. Frankly without his help this will go in the too hard basket at this point in time as my care factor is pretty low when it comes to "accuracy" of page counts. It is impossible to be definitive about because of all the variables - any algorithm is an estimate only and should be used purely to compare the *relative* size of book A vs book B of both using the same algorithm. You are never going to get "the one true value" as no such thing exists. Go lookup paperback vs hardback edition page counts in the printed world which vary based on font sizes, page sizes, layout choices etc - then all the similar variables in the electronic world of device/screen sizes and you will hopefully realise just how ambiguous the term "page" means outside of a printed edition. Right now this plugin may tell me 410 whereas calibre viewer says 388, yet goodreads says the printed paperback edition is 240! It is simply not worth getting too worked up about.

I do agree it is currently misleading to imply this plugin produces the same count as the ebook viewer does in calibre today. If I can't make it produce exactly the same then I will rename things a bit to prevent misconceptions on that. If someone else wants to wrap their head around the relevant calibre code in render_book.py and make a contribution I am happy to take a look at merging it.

FYI how the ebook viewer used to estimate (what this plugin does currently for this option) is just a very crude total characters in the html pages of the book / 1000. Whereas the current ebook viewer code parses the body sections of pages, has various tags it will exclude, strips out all whitespace and divides that by 1000. It also treats every img tag it finds as a page. So unsurprisingly you get quite different counts - with the "old" page count approach generally producing a higher count.

This plugin does already have a number of algorithms based around processing the body section of html and stripping out all tags. However it does so using raw text and regex, rather than XHTML which Kovid's code uses and some extra rules he has in there. For instance my plugin code would strip all img tags completely rather than treating each as a page. I can't make my text based parsing match the counts of XHTML based parsing, hence why this becomes a lot more work...

[DNSB]

Originally Posted by kiwidude

You are never going to get "the one true value" as no such thing exists.

Blasphemer! On a more serious side, that's why I use the same algorithm for all my epub ebooks to make it easy to compare the approximate page counts. I do have one epub that comes in at over 3,000 pages since the Adobe algorithm does not like Base64 inline images.

[DoctorOhh]

Originally Posted by DNSB

that's why I use the same algorithm for all my epub ebooks to make it easy to compare the approximate page counts.

I do the same and simply use the ADE algorithm across the entire library to give me consistent approximate page counts for a good estimate of the length of a book.


The idea that there is one perfect number eludes me.

[JSWolf]

Originally Posted by DoctorOhh

I do the same and simply use the ADE algorithm across the entire library to give me consistent approximate page counts for a good estimate of the length of a book.


The idea that there is one perfect number eludes me.

While ADE page numbers are not perfect, there are none better for eBooks.

[ownedbycats]

Originally Posted by DNSB

Blasphemer! On a more serious side, that's why I use the same algorithm for all my epub ebooks to make it easy to compare the approximate page counts. I do have one epub that comes in at over 3,000 pages since the Adobe algorithm does not like Base64 inline images.

To pick the one I use (Calibre ebook, 1500 chars/page) I used some books with both eBooks and phyiscal copies (of various sizes). Then I ran the generation with different settings and picked out the one that made page-counts close to the physical copies. I mostly care that the numbers are consistent with each other.

[Comfy.n]

Originally Posted by kiwidude

Certainly calibre changed in the last 12 years to using a different algorithm.

And if it changes again, the plugin would possibly need another code rework, I guess...

Originally Posted by kiwidude

Frankly without his help this will go in the too hard basket at this point in time as my care factor is pretty low when it comes to "accuracy" of page counts.

Until recently I used it just for quick comparisons, mainly looking at the book details panel, with the same algorithm (viewer) for all titles. I hadn't noticed that the Viewer header has a different value, currently.

For the purpose I'm aiming - to have an accurate #viewer_pages field to go with the Reading Goal plugin - I think a manually updated column will suffice. Thank you for the detailed update!