Open don-jomedia opened 9 years ago
Thank you for reporting this bug. Are you able to reproduce the behaviour with any EPUB, or with those that load CSS font-faces? See: https://github.com/readium/readium-shared-js/pull/179
Generally-speaking (i.e. irrespective of font-face delayed rendering), it sounds like triggerLayout()
does not guarantee that scrollHeight
is computed correctly? See:
https://github.com/readium/readium-shared-js/blob/develop/js/views/reflowable_view.js#L644
There are a number of known issues related to reflowable pagination (well, CSS column-ization), but the incorrect scrollHeight
reported by the web browser is new, I think. See:
https://waffle.io/readium/readium-js-viewer?label=ReflowPagination
@danielweck It seems so far that we observe this behaviour with EPUBs that load CSS font-faces. We will try to find books that don't have CSS font-faces to confirm.
We are adding a feature to our book reader for our Android application that will remember the last page the user was at in the book and the next time we launch the same book in the book reader, we will set the book at that page. We are using the book reader bookmarks mechanism for this.
What we are observing is that when we open the book at another location than the default first page of the book, the number of pages for that particular chapter is always close to double the expected number of pages.
We traced this in reflowable_view.js, in the updatePagination() method, this call:
_$epubHtml[0].scrollHeight
The value returned for scrollHeight is always wrong at launch, it always larger than what is expected. The result of that is that number of columns returned (which is the number of pages) is always larger, so we end up with a bunch of blank pages at the end of the chapter. Once the book is loaded and we switch chapter and then go back to that chapter, the number of pages returned is corrected and we don't have blank pages any longer.
Please let us know if you require more details.
Thanks!