Aligning Readium positions with RMSDK pages
johanneskoch opened this issue · 5 comments
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
Is there any consensus on this issue? Do we move to 1024 compressed bytes instead of uncompressed ones to better align with RMSDK?
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.
@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?
@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.
It's implemented in the mobile toolkits.