Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aligning Readium positions with RMSDK pages #123

Closed
johanneskoch opened this issue Mar 17, 2020 · 5 comments
Closed

Aligning Readium positions with RMSDK pages #123

johanneskoch opened this issue Mar 17, 2020 · 5 comments

Comments

@johanneskoch
Copy link

As documented in (1), the RMSDK uses the compressed byte length of each resource in an EPUB and a page size of 1024 bytes when calculating the number of synthetic pages per resource.

The Swift (2) and Kotlin (3) implementations of this for Readium, while also using 1024 bytes as the page size, perform the same calculation using the uncompressed byte length.

Due to the ratio of compressed to uncompressed size not being constant from resource to resource, the out-of-the-box experience for implementers migrating from the RMSDK to Readium is that existing page-numbers used in bookmarks etc. cannot be aligned.

If this alignment is desired, Readium should adopt Adobe's way of calculating the position-list.

(1) https://wiki.mobileread.com/wiki/Adobe_Digital_Editions#Page_numbers
(2) https://github.com/readium/r2-streamer-swift/blob/2049164bb2f89cf2300475156dc642024e105c50/r2-streamer-swift/Parser/EPUB/EPUBParser.swift#L328
(3) https://github.com/readium/r2-streamer-kotlin/blob/feature/position-list/r2-streamer/src/main/java/org/readium/r2/streamer/parser/epub/EpubPositionListFactory.kt#L85

@HadrienGardeur
Copy link
Contributor

Is there any consensus on this issue? Do we move to 1024 compressed bytes instead of uncompressed ones to better align with RMSDK?

@mickael-menu
Copy link
Member

mickael-menu commented Apr 16, 2020

I think it's worth aligning with the RMSDK if the user experience is good with compressed length, so we need to perform some testing.

However, to implement this correctly on mobile toolkits, we need the Fetcher refactoring to be able to get the compressed length at the Positions Service level without hacks.

@mickael-menu
Copy link
Member

@johanneskoch The changes needed to implement this on the mobile toolkits is underway, and after a few tests I personally think that using the compressed length gives nicer positions. We'll do more tests and probably ship this solution in Readium. Do you have any feedback after using the compressed length for a few months, are you still using it?

@johanneskoch
Copy link
Author

@mickael-menu Sorry for seeing this so late. Yes, we have been using the compressed length in production ever since launching our R2-based apps and have not had any issues or bad feedback.

@mickael-menu
Copy link
Member

It's implemented in the mobile toolkits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants