Get number of pages of a book in sqlite DB

[chris33]

Hi,
I need to retrieve the number of pages of some books from the KoboReader.sqlite database file.

It looks like content/___NumPages might show the information but for pdf only. It doesn’t seem to give any information for epub/mobi files for instance.

Do you know a way of getting a book’s number of pages for any format ?

[Szybet]

Epub's don't have a fixed number of pages, it depends on font, margins etc. Kobo may save this value somewhere to not calculate it every time, or just don't ¯\_(ツ)_/¯

[Aleron Ives]

There is no such value. The whole point of EPUB is that the page layout is variable, depending upon your chosen font face, font size, margins, and line spacing.

The closest you can get is to count the number of words or characters and then divide by a fixed number of words or characters per page to get an approximation of the number of pages a paper book would have, but you have to choose the divisor arbitrarily, since different font sizes and page sizes yield different words per page in paper books.

[qkqw]

I've looked at this when working on https://www.mobileread.com/forums/sh...d.php?t=349637

As you said, for PDFs you can easily get the current page number. For Epubs the best you can do is a percentage read (___PercentRead) and the current chapter (Title).

[chris33]

ah ok I didn't know that.
Is this the same with mobi files ?

[DNSB]

Originally Posted by chris33

ah ok I didn't know that.
Is this the same with mobi files ?

Yes. It will be the same for any reflowable format since margins, line spacing, line height, font size will all affect the amount of text that will fit on a page.

If you do a search on MobileRead, you will find pages of discussions about why there is no one true page count for epubs and other reflowable books. An example for Google would be 'epub page numbering site:mobileread.com' (remove the quotes). They tend to get repetitive but are good for when insomnia strikes. Nothing like reading about the ONE TRUE PAGE NUMBERING heresy to cause me to want a nap.

[JSWolf]

ADE page numbering is the one true page number for ePub.

One page number to rule them all,
   one page number to find them,
One page number to bring them all
   and in the darkness bind them.

[DNSB]

Originally Posted by JSWolf

ADE page numbering is the one true page number for ePub.

Page-map and pagelist both give consistent page numbers across devices since they depend on a pre-built page number list generally based on a hard cover paperbook edition. One issue is that a page number can occur anywhere on the screen. At one point, calibre supported page-map in ePubs but that disappeared in 2009-2010 (going by my vague recollection).

There were other ePub synthetic page numbering schemes that worked or could work across devices. The key is that both the alternatives to the Adobe algorithm I am aware of mimic the Adobe SPN and calculate the pages in the ePub based on the number of synthetic pages in each text file and have no relationship to the pages seen when reading so a page number can occur anywhere on the screen.

For all of them, the base algorithm is similar to the one use by Adobe's algorithm:

• Determine a compressed byte length of each resource which is referenced in the spine, subtracting any known encryption overhead (IV size).
  
• Assume that there is a page for each 1024 bytes in each resource, rounding up to the nearest whole number of pages for each resource.
  
• To map page breaks into a resource, use the number of pages for the resource as determined in step 2, count the number of Unicode characters in the resource; distribute synthetic page breaks in the resource evenly between the characters by dividing the number of characters by the number of pages; if the number of characters don’t divide evenly among the pages, round the number of characters per page up and let the last “page” contain less characters than the rest.

The other two differed in the number of compressed characters per page (1000 and 1023), the allowance for encryption and compression overhead and for one of them, the ability to recognize images and B64 inline images. That one required unencrypted ePubs to work properly and was slower than molasses since it had to unzip each text file but it could also add a page-map file and page numbers internal to the ePub which looks something like <a id="Page_023"/> going off my rather vague recollection. Both those projects have long since passed into abandonware.

[JSWolf]

Is there any easy way to make a page map that works with RMSDK if you have page number IDs in the ePub?

[DNSB]

Originally Posted by JSWolf

Is there any easy way to make a page map that works with RMSDK if you have page number IDs in the ePub?

It should be fairly easy to do automatically if someone wrote a tool but I'm not aware of any existing tools. Checking the few epubs I have around that have page numbers as IDs, they also have pageList entries in the XHTML navigation document and toc.ncx files. Since pageList is a part of the epub recommendation and that 15 years ago, the comment on page-map was "the 'page-map' attribute is not supported in the OPF Package Schema and thus NOT ALLOWED.", implementing page-map is unlikely to be a good idea.

Oddly the epubs that I have the implement pageList tend to flag that portion of the XHTML navigation document as hidden.

<nav epub:type="page-list" hidden="hidden">
 <ol>
   <li><a href="hurkle.xhtml#page101">101</a></li>
   <li><a href="hurkle.xhtml#page102">102</a></li>
   <li><a href="hurkle.xhtml#page103">103</a></li>
   <li><a href="hurkle.xhtml#page104">104</a></li>
 </ol>
</nav>

[chris33]

ok thank you for the explanations, I'll stick to a percentage+chapter name for locating highlights on my kobo books.