search

readium / readium-js

EPUB processing engine written in Javascript
BSD 3-Clause "New" or "Revised" License
372 stars 107 forks source link

Total Page Count and Current Page Index for entire book #16

Open pivotal-versapub opened 10 years ago

pivotal-versapub commented 10 years ago

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.

danielweck commented 10 years ago

Related issues: https://github.com/readium/readium-js-viewer/issues/99 https://github.com/readium/readium-js-viewer/issues/98

dmitrym0 commented 10 years ago

@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?

rkwright commented 10 years ago

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.

danielweck commented 10 years ago

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

larsvoigt commented 10 years ago

Some thoughts to the cloud reader topic ... Possible ways:

1. readium server side api

2. at book session start

3. html file sizes

4. count letters

evgenlitvinenko commented 8 years ago

[self.refViewController gotoPage:1]; double position = [self.refViewController.getPageInformation pagePositionInBook]; double pages = 1 / position; NSLog(@"pages = %f",pages);

hz0324 commented 7 years ago

Hi, guys. I am facing the same problem now. I want to know, is there any progress now?

danielweck commented 7 years ago

Related: https://github.com/readium/readium-sdk/issues/286

ullstrm commented 6 years ago

In the roadmap for Readium2 (https://www.edrlab.org/readium/readium-2/) the first bullet under V2 tells:

So I have a few questions:

  1. Does this mean "total progression in percent" for the ebook?
  2. What is the status of this roadmap-bullet?
  3. Would this also include total pages or is this a separate issue?

Thank you!

llemeurfr commented 6 years ago

@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).

ullstrm commented 6 years ago

@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

llemeurfr commented 6 years ago

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.