[GUI Plugin] Count Pages

[Wiggo]

Goodreads only works if there is an entry of pages for this book id and you have to check if Goodreads Edition matches your book edition.

Personally, however, the approximate estimation of the algorithm is enough for me.
I have the ADE, IIRC

[DNSB]

Originally Posted by Smokus

Which algorithm for Page Count is objectively the best one?
Does Page Count from Goodreads offer superior results than using algorithms to obtain Page Count?

I don't know if it matters, but I usually convert EPUB books into KFX and then use the Count Pages plugin.

None of them are objectively any better. Some use the page count from a specific print edition, others calculate the page count based on various algorithm. My preference is to use the Adobe Synthetic Page Count algorithm on epubs since it seems to have the most consistent results on the epub ebooks I read. As long as you stick to one algorithm, you should be okay. I find the page count from physical edition is not as consistent since one epub will say that it has 443 pages and another book with a near identical word count will report 386 pages. This is likely due to the influence on page count of the paper size, font size, etc. of the physical book the page count is lifted from. One recent epub had the page count based on the large print edition for some reason.

[kiwidude]

Release Notes
https://github.com/kiwidude68/calibr..._pages-v1.13.4

Another databazeknih change from @sleeper

[JSWolf]

Originally Posted by Wiggo

Goodreads only works if there is an entry of pages for this book id and you have to check if Goodreads Edition matches your book edition.

Personally, however, the approximate estimation of the algorithm is enough for me.
I have the ADE, IIRC

Heck no. Goodreads uses incorrect page numbers for eBooks.

[JSWolf]

Originally Posted by DNSB

None of them are objectively any better. Some use the page count from a specific print edition, others calculate the page count based on various algorithm. My preference is to use the Adobe Synthetic Page Count algorithm on epubs since it seems to have the most consistent results on the epub ebooks I read. As long as you stick to one algorithm, you should be okay. I find the page count from physical edition is not as consistent since one epub will say that it has 443 pages and another book with a near identical word count will report 386 pages. This is likely due to the influence on page count of the paper size, font size, etc. of the physical book the page count is lifted from. One recent epub had the page count based on the large print edition for some reason.

I agree with this and I also use the Adobe Digital Editions page count. Also, I mostly read ePub using RMSDK on my Kobo. This means the page count I see from the plugin is the same page count as reported on my Kobo. The only difference is if I was to read KePub and then the page numbers would not match.

Once you get used to ADE page numbers, it gives you an idea of how long the eBook is. Also, if you start with an ePub cna convert to KF8, you can get the Kindle page number to match the ePub page number.

[JSWolf]

I've updated all of my eBook counts. The only thing that's changed is the word count. Page numbers are still the same.

[Smokus]

I'm somewhat conflicted right now.

I found information that APNX is used exclusively for Kindle devices. I also use and own only a Kindle device for eBooks.

Then there is information that ADE is the best algorithm for ePubs.

However I don't read in ePub format. After I've configured all metadata (pages count as well), I then convert that ePub into KFX.

I have one book that is 1082 pages long when using APNX, and 822 pages long when using ADE.

I'd like to point out that I use Calibre exclusively for side loaded books that come in Epub format originally without any extra files next to the book itself.

[JSWolf]

Originally Posted by Smokus

I'm somewhat conflicted right now.

I found information that APNX is used exclusively for Kindle devices. I also use and own only a Kindle device for eBooks.

Then there is information that ADE is the best algorithm for ePubs.

However I don't read in ePub format. After I've configured all metadata (pages count as well), I then convert that ePub into KFX.

I have one book that is 1082 pages long when using APNX, and 822 pages long when using ADE.

I'd like to point out that I use Calibre exclusively for side loaded books that come in Epub format originally without any extra files next to the book itself.

I would post in the KFX conversion plugin thread and ask how to make the APNX for KePub mach the page count for the ePub.

[Smokus]

Originally Posted by JSWolf

I would post in the KFX conversion plugin thread and ask how to make the APNX for KePub mach the page count for the ePub.

I am able to send the page count to KFX format durign conversion.
There is a specific option for it in KFX Output plugin:


When I open the book on my Kindle, I see the exact same page count as in Calibre.

[theducks]

What is important is to use the SAME METHOD for all books.
Pages allows a simple comparison. File size is probably worse the good reads (user supplied ) as images, fonts, HTML tags in content all skew the size.

[ownedbycats]

Originally Posted by theducks

What is important is to use the SAME METHOD for all books.
Pages allows a simple comparison. File size is probably worse the good reads (user supplied ) as images, fonts, HTML tags in content all skew the size.

Yes, this. Personally, I had a few books that had both eBook and physical copies, so I picked three of them of different sizes (mass-market, hardback, I think the third was a weirdly-sized softcover) and then played around with options until the counts were 'close enough' to the paper copies. Then I ran it over the other books in my library.

[DNSB]

As both @theducks and @ownedbycats said, the important thing is using the same method for all your books.

As for using a paper book as the reference, I have one pbook in a hardcover, trade paperback and paperback version. The page count varies from 396 to 478.

Since I read epubs, my preference is ADE. For a Kindle owner, APNX is likely the better choice. I looked at the various downloadable page counts and was not impressed by the consistency.

[kiwidude]

Originally Posted by JSWolf

I've updated all of my eBook counts. The only thing that's changed is the word count. Page numbers are still the same.

Hi - yes that would make sense because as I mentioned it depends on the algorithm as to whether the change I made has an impact or not. In the case of ADE which I believe you prefer to use then it would not, as from memory ADE just uses the raw size of the html files without any parsing/processing. Whereas other algorithms that for instance try to count based on paragraphs or amount of text characters (or indeed word counts) need to strip out the body text from the html. Which is what I changed.

As to the whole “which page count” should you use - mostly it does not matter so long as you are consistent with an option across your library as the point of the plugin is to give a relative comparison between books. It really doesn’t matter if “the number” is 300 or 400, so long as a similar size book gives a similar number.

I will agree that the weakness of the download page count options is that you must make sure you link to an edition that makes sense or you may get wildly varying numbers which violates the statement I said above. It is not an option I personally use, nor was it added to the plugin by myself. However for people who get very specific about matching editions I can understand the appeal.

[JSWolf]

Originally Posted by kiwidude

Hi - yes that would make sense because as I mentioned it depends on the algorithm as to whether the change I made has an impact or not. In the case of ADE which I believe you prefer to use then it would not, as from memory ADE just uses the raw size of the html files without any parsing/processing. Whereas other algorithms that for instance try to count based on paragraphs or amount of text characters (or indeed word counts) need to strip out the body text from the html. Which is what I changed.

As to the whole “which page count” should you use - mostly it does not matter so long as you are consistent with an option across your library as the point of the plugin is to give a relative comparison between books. It really doesn’t matter if “the number” is 300 or 400, so long as a similar size book gives a similar number.

I will agree that the weakness of the download page count options is that you must make sure you link to an edition that makes sense or you may get wildly varying numbers which violates the statement I said above. It is not an option I personally use, nor was it added to the plugin by myself. However for people who get very specific about matching editions I can understand the appeal.

What did change was the word count. I take it the word count is now more accurate?

[kiwidude]

Originally Posted by JSWolf

What did change was the word count. I take it the word count is now more accurate?

Well I would hope so

Previously the plugin had a crude approach of extracting the html body content and stripping html tags using the raw text and regular expressions. Which for a rough estimate is usually perfectly fine.

However as with any shortcuts a crude approach creates edge cases where you can get outlier results. In this case the problem is the encoding of html entities - one book (or even two formats of the same book) might have text like "it's" and the other has "it's". Previously I was not "decoding" the first case, so if you were counting characters in the body obviously the number is larger, and if counting words then the way word boundaries were defined it might count as two words rather than one based on the semi-colon being in there.

Now however I am using the BeautifulSoup parser to process the html and then asking it to give me the body text. Because it can be told to decode all those entities (and strip out all the other meaningless html tags like spans etc) so I have a consistent starting point of the second example text to calculate page and word counts for.

Provided BeautifulSoup is given fairly well formed html it should indeed all work fine. Give it bad html books and it will probably give terrible results - but then if the html is that awful then many ereaders might struggle with it too...