readium-js
readium-js copied to clipboard
readium
Total Page Count and Current Page Index for entire book
Currently there is no obvious way of getting the total page count and current page index for the entire book. In previous versions of Readium, we eager loaded the entire book, which allowed us to do this, with performance drawbacks.
One workaround in our code could be to make a second hidden Readium container and iterating through each SpineItem to get the page count.
We would prefer an official way of doing this, while still maintaining performance considerations and clean code.
Related issues: https://github.com/readium/readium-js-viewer/issues/99 https://github.com/readium/readium-js-viewer/issues/98
@rkwright are we looking to solve this as a general problem, as part of readium or for chrome extension?
Chrome extension might be easier to solve because of course the epub is local. We could iterate through the whole book fairly rapidly to get the number of pages. I think this is similar to what iBooks does.
I dont have a good solution for the cloud reader though that doesn't rely on external metadata. For ATB we generate an index that we then use to identify where the user is in the book. The index is fetched along with the initial spine item so there's not much overhead.
It's going to be difficult to come up with a solution that doesn't rely on actually rendering the full epub because that's the only way to get an accurate measure of everything. Do you know much about the approach that adobe used -- i remember seeing something about estimating page size based on kb... do you know if that worked well?
At Adobe we just faked the number of pages(dividing the chapter length in bytes by some number (2048?)) because AFAIK there is no way to get the page count without laying out the pages. And when we wrote RMSDK the devices (e.g the Sony 500) were very slow, using 400 MHz ARM chips. Ideally one shouldn't have to render the pages, just lay them out. There is a similar problem when one steps from the first page of a chapter to the last of the previous. the only way to know what page to render is to lay out ALL the pages in the chapter. In the old days it caused a perceptible pause doing that and in particular complained about it endlessly.
Today, it appears that iBooks actually does layout all the pages extremely quickly. Of course the CPU is far faster and they may leverage the GPU as well. Using the GPU is not really an option for us. It would be a very useful experiment to write a script that would force the browser to paginate a given document. Then we could get some real numbers.
This is for "global" spine-level page counting. I just want to point out that there is a separate issue in readium-shared-js for "local" spine item document-level page counting (spread items / total), to mimic the logic that has been available in Launcher OSX and iOS for some time now (the canGoNext/Previous() API was actually inspired from this existing native code). See: https://github.com/readium/readium-shared-js/issues/105
Some thoughts to the cloud reader topic ... Possible ways:
1. readium server side api
- make a hidden “rendering” of the full epub on server side to use the power of the server-machine to e.g. compute the total page count and other parameters of interest during the book session
- a server side api can also useful for a full text search
2. at book session start
- make a hidden “rendering” of the full epub only on session start to compute the total page count with standard parameters
- this computed value is living on client side as a reference during the book session
3. html file sizes
- make an estimate of total page count based on sum of all html files sizes
- AFAIK It is possible to get the file header via http request and with it the sizes
4. count letters
- count the letters at html files (ignoring html grammar)
- and multiply with a “magic” value ( font size + …)
[self.refViewController gotoPage:1]; double position = [self.refViewController.getPageInformation pagePositionInBook]; double pages = 1 / position; NSLog(@"pages = %f",pages);
Hi, guys. I am facing the same problem now. I want to know, is there any progress now?
In the roadmap for Readium2 (https://www.edrlab.org/readium/readium-2/) the first bullet under V2 tells:
- get his reading position (progression indicator) in the publication (relies on GlueJS’s locator.js milestone 3)
So I have a few questions:
- Does this mean "total progression in percent" for the ebook?
- What is the status of this roadmap-bullet?
- Would this also include total pages or is this a separate issue?
Thank you!
@ullstrm, readium-js, the current codebase for web reader development, is not part of the "Readium 2" initiative (therefore the V2 roadmap does not apply). The active developers of the Readium community are starting a new project under the "Readium-2" banner but there will be no result before some months.
The bullet in the v2 roadmap means that there will be a mean to get a pointer to the current reading position of the user (we call it a "locator"). Which means getting the progression in the chapter and in the book and also a "position". The notion of position is explained here and here. This notion of position is equivalent to the notion of "page number". This notion of Locator is under development on the iOS and Android implementations. It will take time before it's implemented on a Web Reader (shorter time if more developers participate to the development).
@llemeurfr Thank you for your answer! 😃 I am indeed mostly interested in the iOS and Android-roadmaps.
Where can one follow the status of the Locator-implementations in these platforms? I'm having a hard time figuring out which projects on the readium github is used in "Readium 2" and not. 😿
Ps. The links are broken. I guess these are the correct links. Ds. locator readme locator-api
Let's discuss this on the Readium Slack or via emails, as this has nothing to do with the readium-js issue we're in.