I just got a book with a series of images at the beginning that showed up as postage-stamp size in the bundled viewer when in paged mode, but OK in other clients and in the viewer when in continuous mode. Some investigation with the viewer's built-in inspector showed that the generated column-width of the iframe was some extremely small number, like 34px instead of equivalent to the width of the viewer area.
Crucially, this did not happen for the cover or for regular text. Comparison of the cover's xhtml file with that of the subsequent images showed that the cover page's xhtml did not import any CSS, whereas the files of those images that showed up in an extremely constricted column, did.
The CSS file in question was very short:
Code:
@charset "UTF-8";
html,
body {
margin: 0;
padding: 0;
font-size: 0;
}
svg {
margin: 0;
padding: 0;
}
After commenting out 'font-size' in the editor, saving, and reloading the book in the viewer, the images showed up normally. I am not sure what the code path is for generation of the pages in the viewer (I looked
here but I'm a little lost, I'm not sure where in the codebase css generation is) but I'm assuming that the amount and size of text is taken into account, and since this page didn't have any text and the font size was so low, it decides to make the column as narrow as possible instead of letting it fill up the width of the viewer. It's trivial for me to comment out the CSS that leads the viewer down this codepath, but presumably there's a reason it was there in the first place: I don't know what changing this would do in every other viewer. If it is possible to have a more robust check when generating the column size for paged mode, that would be rather helpful for users with books that have this CSS quirk for whatever reason.
Calibre version: 6.5.0
OS: Windows 10 Pro 10.0.19044.2006 ("21H2")
The book in question is originally an AZW3 from which an EPUB was extracted with the KindleUnpack plugin. This behavior presents itself with both formats.
Cross-posted to
launchpad