Image size.

[UncleIvor]

I'm formatting an epub with illustrations. I want the picture to have a page to itself, so I can the pagebreak before and pagebreak after to achieve that.

Let us assume that the image is relatively tall and slim. I would like it to fill the page from top to bottom - in other words, fill the screen.

I am very familiar with html code and css3.

To do this, as part of the <img src= ... etc> would I say: "height="100%"? Would this work irrespective of the size of the image?

[dgatwood]

The code above will presumably give you the image sized to fill the height of the screen. However, if it is narrower than the screen, it will not fill the full width of the screen, and if it is wider than the screen, I'd expect it to be clipped (probably entirely from the right side).

For this sort of thing, I would suggest using a bit of basic SVG. Take a look at the source code for this test page:

http://kinji.gatwood.net/

and use it as a starting point. That's basically copied straight out of my EPUB and Kindle books (except that there are stylesheets in the books, and the books don't include hackish JavaScript workarounds to allow me to use larger images on desktop computers).

If you really want the image to fully fill the screen, just change "meet" to "slice" in the svg tag's preserveAspectRatio attribute. Be aware, however, that if you do that, when shown on a widescreen device in landscape orientation, on most devices, you'll lose almost half of your image, because it will be massively clipped on the top and bottom.

Unless you're working with an unimportant background image, scale-to-fit is almost always the right choice, rather than scale-to-fill.

[Jellby]

Originally Posted by UncleIvor

To do this, as part of the <img src= ... etc> would I say: "height="100%"? Would this work irrespective of the size of the image?

Unfortunately, there's no guarantee. There's no portable and robust way to access the screen height with ePub 2. You can try "height: 100%" (in the CSS, not in the HTML), but it will not work in every reader. Whatever you do, it will not work in every reader, and not necessarily because of reader bugs.

[UncleIvor]

I know one of the major problems is lack of consistency in the implementation of CSS among the different readers.

I've been experimenting, using a Kobo, and height="100%" works for tall images, and automatically fills a page. I've also centered the image with <div style="text-align:center">. For landscape images I've used width="100%", and that works nicely.

I haven't tried a Kindle, but I gather Amazon provides a program to convert epb to Kindle, and also to view the result on a pc. My target audience will be Amazon.

[Toxaris]

For ePUB I would strongly recommend the SVG-wrapper. Probably dtgawood recommended the same. However, SVG is not supported IIRC on Kindle. As far as know all books for Kindle are converted ePUB instead of created from scratch. Perhaps you should take a look at media queries or ask in the Kindle subforum how it will work on a Kindle.

[Notjohn]

I use width="100%" in all my images, and I have never seen a bad result in an Kindle, Fire, or emulation.

The narrowest Kindle AFAIK is the Fire tablets with a height/width ratio of 1.6. So any image skinnier than that (say 800x1280 pixels) ought to work just fine at height="100%"

Why wouldn't the Sigil default for a cover image (adapted for your use) work?

<div style="text-align: center; padding: 0pt; margin: 0pt;">
<svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 1800 2700" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink"><image height="2700" width="1800" xlink:href="../Images/YOURIMAGEHERE.jpg" /></svg>
</div>

[Jellby]

Originally Posted by Notjohn

I use width="100%" in all my images, and I have never seen a bad result in an Kindle, Fire, or emulation.

Have you tried a tall image on a landscape screen?

[Notjohn]

Originally Posted by Jellby

Have you tried a tall image on a landscape screen?

Yes. It shrinks to fit, and when zoomed will go to the top and bottom margins on my Fire tablet.

I have noticed that the included book cover, when using the rather elaborate formatting provided by Sigil, will overflow the available space on the Barnes & Noble online sample. (This is not true of the KDP version, which of course does not have an included cover. Neither is it true on Apple or Kobo. I should download the B&N version and look at it on my Nook.)

But the interior images, with the width="100%" instruction, work as I would hope everywhere I have checked, including on Sigil itself.

[dgatwood]

Originally Posted by Toxaris

For ePUB I would strongly recommend the SVG-wrapper. Probably dtgawood recommended the same. However, SVG is not supported IIRC on Kindle. As far as know all books for Kindle are converted ePUB instead of created from scratch. Perhaps you should take a look at media queries or ask in the Kindle subforum how it will work on a Kindle.

Depends on what you mean when you say Kindle. SVG seems to work reasonably well on KF8-capable Kindle devices. So I use the same code on Kindle, but with a little extra magic CSS:

@media not amzn-mobi {
    .kf8only { display: inline; }
    .mobionly { display: none; }
}

@media amzn-mobi {
    .kf8only { display: none; }
    .mobionly { display: inline; }
}

With that, I can wrap the SVG wrapper in a <div class="kf8only">, and wrap a copy of the bare image with <div class="kf8only">.

Thus, the SVG gets shown only on KF8-capable Kindle readers, and really old Kindle hardware just gets a static image, with a slightly less than ideal presentation size. It isn't perfect, but it works well enough, IMO.

[JSWolf]

Also, make sure your images are high resolution. When reading on devices such as a Kobo Aura HD , Kobo Aura H2O, and Kindle Voyage, if the image is too low a resolution, they will look fuzzy from having to be increased too much to fit the screen. If this is an eBook you are planning on selling, then yes you need high resolution images.

I've seen images that look oksih (at best) on a standard Reader such as your 505. But now with Readers coming out with much higher resolution, these oksih images are now lousy and can be very hard to see properly (maps are a good example of being unreadable).

[dgatwood]

Originally Posted by JSWolf

Also, make sure your images are high resolution. When reading on devices such as a Kobo Aura HD , Kobo Aura H2O, and Kindle Voyage, if the image is too low a resolution, they will look fuzzy from having to be increased too much to fit the screen. If this is an eBook you are planning on selling, then yes you need high resolution images.

But not too high a resolution. Experimentally, images above about 4 megapixels will fail to render in spectacular ways in the WebKit rendering engine on iOS, depending heavily on what software is rendering it.

For example, on my book website (www.patriotsbooks.com), I have thumbnails of book covers, and you can click to zoom in see the cover at full-screen size. On iOS, I had to actually load a scaled-down version of the images on iOS, because in Safari, the SVG code failed to properly scale the image down, and ended up showing one corner of the image at full size (one source pixel to one screen pixel).

Literally, the only difference between working content and non-working content was using a lower-resolution JPEG.

What's curious is that those exact same images worked correctly for me in iBooks on iOS, but Apple rejected my submission and required me to scale them down anyway. So the SVG handling of large images in iOS is still very fragile—perhaps a consequence of Apple not having removed whatever horrible hacks they did to make things work back in 128 MB of RAM on early hardware?

Either way, experimentally, the 2,640 x 2,040 images worked in iBooks, but failed in MobileSafari, whereas the 2,265 x 1,750 images work fine even when scaled up in SVG to 2,640 x 2,040 and then back down.

Just an FYI.

[Jellby]

Originally Posted by JSWolf

I've seen images that look oksih (at best) on a standard Reader such as your 505. But now with Readers coming out with much higher resolution, these oksih images are now lousy and can be very hard to see properly (maps are a good example of being unreadable).

Really? Isn't it just that you expect a better quality for a high-resolution screen, and what you get is in fact about the same as a low-resolution one?

There are two cases for low-resolution images:

Images shown at their native resolution: They can look OK in low-resolution devices, but then they'll be damn small in high-resolution devices, with unreadable text if there's any.

Images scaled to some specific size: I don't see why they should look different in high-res or low-res devices. There may be small differences due to the scaling algorithm and the factors being different. If it's optimized for low-res, such that the scaling is 1:1, the quality may be somewhat degraded in high-res (aliasing etc.). If a case like this is unreadable in a high-res device, being OK in a low-res one, there's something seriously broken in the scaling algorithm.

On the other hand, high-resolution images have their own problems: large memory usage, overflow in low-res screens at native resolution, worse degradation when being scaled down.

[JSWolf]

Originally Posted by dgatwood

But not too high a resolution. Experimentally, images above about 4 megapixels will fail to render in spectacular ways in the WebKit rendering engine on iOS, depending heavily on what software is rendering it.

For example, on my book website (www.patriotsbooks.com), I have thumbnails of book covers, and you can click to zoom in see the cover at full-screen size. On iOS, I had to actually load a scaled-down version of the images on iOS, because in Safari, the SVG code failed to properly scale the image down, and ended up showing one corner of the image at full size (one source pixel to one screen pixel).

Literally, the only difference between working content and non-working content was using a lower-resolution JPEG.

What's curious is that those exact same images worked correctly for me in iBooks on iOS, but Apple rejected my submission and required me to scale them down anyway. So the SVG handling of large images in iOS is still very fragile—perhaps a consequence of Apple not having removed whatever horrible hacks they did to make things work back in 128 MB of RAM on early hardware?

Either way, experimentally, the 2,640 x 2,040 images worked in iBooks, but failed in MobileSafari, whereas the 2,265 x 1,750 images work fine even when scaled up in SVG to 2,640 x 2,040 and then back down.

Just an FYI.

But, there is nothing to stop you from making a version for iBooks and another version that does have high resolution images.

[JSWolf]

Originally Posted by Jellby

Really? Isn't it just that you expect a better quality for a high-resolution screen, and what you get is in fact about the same as a low-resolution one?

There are two cases for low-resolution images:

Images shown at their native resolution: They can look OK in low-resolution devices, but then they'll be damn small in high-resolution devices, with unreadable text if there's any.

Images scaled to some specific size: I don't see why they should look different in high-res or low-res devices. There may be small differences due to the scaling algorithm and the factors being different. If it's optimized for low-res, such that the scaling is 1:1, the quality may be somewhat degraded in high-res (aliasing etc.). If a case like this is unreadable in a high-res device, being OK in a low-res one, there's something seriously broken in the scaling algorithm.

On the other hand, high-resolution images have their own problems: large memory usage, overflow in low-res screens at native resolution, worse degradation when being scaled down.

I expect images I can see properly. I've seen many books that have maps where the maps are just too small on an 800x600 eInk screen and if you talk H2O and Voyage, it's going to be even worse.

When books are made these days, high resolution screens (like the HD, H2O, & Voyage) need to be taken into account. If you plan on doing full screen images, then you need to find out what size works so the images look good enough. Maybe 1200 line images. Maybe 1000 line images. I have not tested what image resolution works well on an H2O for full screen.

As for high resolution images having overflow issues on low-res screens, code for it. Code for a percentage of the screen and not a resolution. That way you'll get the images not overflow on low-res screens. The thing is, we have now 3 or 4 different screen resolutions and you cannot code for them using pixel sizing. You have to use screen percentages and you have to test on a these different screens to make sure you get it correct.