kotlin-toolkit
kotlin-toolkit copied to clipboard
readium
Parts of epub3.0 are not fully displayed
On android devices, a lot of pages are only half displayed.
The picture above is incomplete;
@windflowersnowandmoon Hi, thanks for reporting this issue.
Would you be able to share an EPUB that has this problem with us?
@windflowersnowandmoon Hi, thanks for reporting this issue.
Would you be able to share an EPUB that has this problem with us?
This is the link to the problematic epub file. https://drive.google.com/open?id=1_Sj4h26-tvEEw06Ed7ucXx9UzHO_-ueW
Thanks, after a quick test: it looks like the resources are not specifying the size of the pages through CSS, which is unusual. But according to the spec, the page dimensions are set in the viewport meta tag, and not in CSS. Right now, viewport seems to be ignored on Android, which is probably the issue.
Thanks, after a quick test: it looks like the resources are not specifying the size of the pages through CSS, which is unusual. But according to the spec, the page dimensions are set in the
viewportmeta tag, and not in CSS. Right now,viewportseems to be ignored on Android, which is probably the issue.
Thank you for your reply.I have tested the demo of ios, the same EPUB file can correctly display and play audio;How to fix this problem?
If you can modify the books used in your app, you can add width and height CSS properties to <body>.
Otherwise, there's no easy fix without modifying the toolkit, and I don't think we'll have time to fix this soon.
You're welcome to send us a Pull Request if you want to tackle this issue yourself. Here's the relevant JavaScript parsing the viewport meta tag in the Swift version:
https://github.com/readium/r2-navigator-swift/blob/6654a5d266b121de9b1bd1f332cb5b860ce95f3b/r2-navigator-swift/EPUB/Resources/Scripts/fixed.js#L18-L35
You could use this to extract the page size, and then apply the CSS yourself.
But according to the spec, the page dimensions are set in the viewport meta tag, and not in CSS.
I think I may have a different interpretation, as this section is about the Initial Containing Block, so:
Reading Systems MUST clip XHTML content to the initial containing block (ICB) dimensions declared in the viewport meta tag — content positioned outside of the initial containing block will not be visible.
The initial containing block is like the rectangle inside which the XHTML contents will be displayed. So if it’s say 700 * 1400 (viewport meta), and a 1400 * 2100 image doesn’t have width and height in CSS for instance, you’re supposed to clip and make the parts of the image overflowing not visible – and I guess in case of spreads, you don’t really have any choice but to clip.
That said, I’ve had a hard time with viewport, initial containing block, and content display area in the past as the terminology makes it pretty obscure. And there’s an issue opened for that in the EPUB-revision repo: https://github.com/w3c/publ-epub-revision/issues/1306
I can recall using the same exact technique as in swift in my cloud implementation though (forcing width and height on body).
That said, I’ve had a hard time with viewport, initial containing block, and content display area in the past as the terminology makes it pretty obscure. And there’s an issue opened for that in the EPUB-revision repo: w3c/publ-epub-revision#1306
Yeah, I'm not sure I fully understand the nuance. I actually simplified the description of the Swift implementation, since we're actually using iframes to be able to render 2-page spreads. So the size is actually fixed on the containing <iframe>, without touching at the actual DOM of the resource.
https://github.com/readium/r2-navigator-swift/blob/6654a5d266b121de9b1bd1f332cb5b860ce95f3b/r2-navigator-swift/EPUB/Resources/Scripts/fixed.js#L43
So I've used the viewport meta tag as basically the fixed size of the iframe/page. Implicitely the content is clipped inside.
So I've used the viewport meta tag as basically the fixed size of the iframe/page.
That’s how I understand it too since the definition of “initial containing block” is:
The containing block in which the root element lives is a rectangle called the initial containing block. (source)
And in theory, you shouldn’t bother with what’s inside – in practice, you might because some FXL books are broken otherwise.
But what’s most probably expected is that as a user agent, you create this rectangle (so size of the iframe) according to the viewport meta and then what’s inside the document is up to authors. And the difference with a browser is that instead of applying scrollbars (overflow), contents must be clipped (and hidden).
Then content display area is, well, quite an abstract concept added on top of existing web concepts so I’m not sure I ever understood it precisely.