how can we calculate total no of pages in a book in Background

[ashishdixitmca]

Hi , I am trying to implement goto page functionality in IOS Readium SDK so i need to calculate total no of pages from entire book in background.

Can anyone please suggest how can we calculate total no of pages in background without blocking the user interface .

**Note :-As per our R&D with multiple forums need to create hidden container and iterate the spine items .I am unable to do in background .

Regards 
Ashish

[danielweck]

My comments extracted from the parallel Slack discussion:

in the SDKLauncher-xx apps, there is no publication-wide "page" count (i.e. estimation of the number of CSS columns for the entire spine / reading order, or approximation based on an arbitrary unit of characters that define a single chunk of data). There is only an accurate figure computed by the "shared JS" component, based on the exact number of CSS columns (of course for fixed layout each page is a standalone document, I am talking about reflowable publications here)

the obvious limitation of the R1 implementation is that the total figure for the entire publication is not available, only for the currently loaded document (because in this case we know exactly how many CSS columns are used to layout "pages"). In Readium2 there is a better architecture to handle the real-world case of estimating the total number of "pages" for the entire reading order. There are reading systems (like iBooks on MacOS, I think) that launch a background thread / activity to compute the actual number of "pages" by rendering documents offscreen. Alternatively you can also count the number of characters in each document and divide by a number of arbitrarily-sized chunks, which gives you a metric to present to the user (some approximation of what the progression of the reading experience is)

it is really one or (xor) the other: "real" number of CSS columns (accurate because computed from rendered documents, and correct because depends on font size etc.) vs. arbitrary units of content (e.g. division of reading order into consecutive chunks of n chars), which is an approximation that fails when there are pictures, video, canvas widgets, etc. ... but in many cases it is "good enough" (because most ebooks mostly contain text)

I remember a developer who tried to build on top of R1 a system to render documents offscreen (by launching separate instances of the shared-js reader object), in order to compute the actual number of CSS columns at any time, depending on font size etc. ... it was computationally (CPU, memory) very expensive, and also difficult to manage concurrency in a background thread/activity.

instead, much easier to load raw HTML documents one by one in a non-blocking operation, for example when importing a publication into an app database, count the number of chars in the body, divide by 1024 (or some other metric) and store the values permanently in the publication object model. these do not change depending on font size, so can be persisted forever.

then, use this system of arbitrary chunks of (text) content to inform the user about their reading progression (percentage, or even the actual numbers like "position 14 / 187" ... do not use the term "page" as this is confusing, in my opinion ;)

that's a UX decision for you to make. I personally think that the term "page" is overloaded and confusing (fixed layout pre-paginated documents == pages, reflowable CSS columns == pages, EPUB epub:type pagebreak / page-list == pages, arbitrary "chunks of text". == pages) ... hard to design a unified concept because of mixed user expectations.

[danielweck]

Readium2 approach: https://github.com/readium/architecture/blob/master/locators/README.md https://github.com/readium/architecture/blob/master/locators/locator-api.md https://github.com/readium/architecture/blob/master/locators/timeline.md

[danielweck]

Also see: https://github.com/readium/architecture/issues/90