Images not displaying properly in iBooks

[eggheadbooks1]

I'm trying to help an elderly friend who has written a book for her kids and wants to be able to give it to them as an ePub. Problem is, she has an iPad and uses iBooks while her children use a mix of iPads (various generations) and Android tablets, and has no idea which of the myriad of ePub apps they might be using.

Apple dictate that all images must be placed in containers (to work around the bug they refuse to fix) and they ask for images to be coded as:

HTML:
<div class="image-container">
<img src="images/bears.jpg" alt="three bears peer at goldie locks"/>
</div>

CSS:
img {height: 100%;}
.image-container {height: 100%;}

(Note: they actually ask for "height: 100vh", but nothing else I know of reads vh so I use %, which iBooks still reads.)

I also added a second image container for horizontal images:

.image-container2 {width: 100%;}

Problem is, the code works only for vertical images: horizontal images are stretched (distorted) to 100% screen height because of the (stupid) img value.

If one changes the img value to 100% width, then horizontal images work but not vertical.

How, then, does one code as Apple dictates but have both vertical and horizontal images in your ebook?

I tried to fix the problem by removing the img value from the CSS and creating classes I could add to divisions and to the img tag:

CSS:
.imageV {height: 50%; text-align:center; margin-bottom: 1em;}
.imageH {width: 100%; text-align:center; margin-bottom: 1em;}
.imageC {height: 100%; text-align:center;}
.vertical {height:100%;}
.horizon {width:100%;}

HTML:
<div class="imageV">
      <img class="vertical" alt="child" src="../Images/child.jpg"/>
    </div>

<div class="imageH">
      <img class="horizon" alt="mother" src="../Images/mother.jpg"/>
    </div>

Well, this works great in ADE, Aldiko, Kobo, but not in iBooks because it ignores the class in the img tag. The horizontal images work but not the 50% vertical ones. Those are ballooned up to the full screen even though the container is only 50% of the screen.

Help!

[Toxaris]

If the images are supposed to fill the complete page as much as possible, but not be distorted, I would strongly recommend a svg container. This is also much used for covers and does work on iBooks as far as I know. You can actually do this quite easily with Sigil and the svgwrapper plugin.

[eggheadbooks1]

The images are not supposed to fill the page; the vertical ones are 50%, the horizontal ones ends up about the same height-wise simply because they are horizontal. This is what she wants (the images are at the start of chapters). Only the cover is 100% height.

Apple iBooks doesn't read SVG wrappers, at least as far as I know. In the past, images in SVG wrappers were still often split over screens, at least when I tested them back then. The SVG wrapper worked beautifully in most ePubs, but then the new Kobo Arc, when I tested it in late 2014, ignored the SVG wrapper. (Kobo's bithub page warns that SVG images may not display correctly across devices). And the latest Apple Asset Guide states: "To ensure proper viewing of images in content, use the HTML img tag instead of wrapping images in svg:img."

So I'm at a loss as to how to code images that will work in both Apple iBooks and general ePub apps.

[RbnJrg]

Originally Posted by eggheadbooks1

The images are not supposed to fill the page; the vertical ones are 50%...

Ok, then try:

img {
     height: auto;
}

[eggheadbooks1]

Originally Posted by RbnJrg

Ok, then try:

img {
     height: auto;
}

Alas, that's worse: in ADE, the image not only balloons to full screen but it overlaps text. I recall Kobo not reading "auto" as well when I tried it last year. Earlier today I also tried

img {
     height: 100%; 
     width: auto;
}

but that didn't work either. Sigh.

I just spoke with my friend. She agrees this is an exercise in futility and I'm going to make her a regular ePub with the height and width set in the image tag as has worked historically, and which pretty much every other ePub reader is programmed to recognize, and her family can download another (better) ePub reader to their iPads.

Thanks for your suggestions, though. Truly appreciated. (And the fact that there haven't been more suggestions on this forum, where I usually find solutions within a few hours, tells me that maybe there isn't a solution to this particular problem. Apple sucks.)

[dgatwood]

Originally Posted by eggheadbooks1

Apple iBooks doesn't read SVG wrappers, at least as far as I know.

iBooks handles SVG wrappers just fine. I use them all the time. Note, however, that by SVG wrapper, we're talking about a standalone HTML file that includes only the image. If you're trying to keep it all in one file, you're likely to have a lot more problems. For example, the cover.xhtml file from my latest book:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:svg="http://www.w3.org/2000/svg" xmlns:epub="http://www.idpf.org/2007/ops">
<head>
<title>Cover</title>
<link rel="stylesheet" type="text/css" href="nookstyles.css" />
<link rel="stylesheet" type="text/css" href="nookstyles2.css" />
<style type="text/css">
    html,body {
	height: 100% !important;
	min-height: 100% !important;
	width: 100% !important;
	margin: 0 !important;
	border-width: 0 !important;
	padding: 0 !important;
    }
</style>
</head>
<body style="oeb-column-number: 1; background-color: #000000;" >
<div class="coverpage">
<svg 
	xmlns:svg="http://www.w3.org/2000/svg"
	xmlns="http://www.w3.org/2000/svg"
	xmlns:xlink="http://www.w3.org/1999/xlink"
	version="1.1"
	width="100%"
	height="100%"
	id="svg2"
	xml:space="preserve" viewBox="0 0 2040 2640" preserveAspectRatio="xMidYMid meet">
    <image xlink:href="frontcover.jpg" height="2640" width="2040">
	<desc>Patriots: A Patriots Christmas</desc>
    </image>
</svg>
</div>
</body>
</html>

where the CSS defines this:

div.coverpage {
        height: 100%;
        margin: 0;
        padding: 0;
        border-width: 0;
}

Originally Posted by eggheadbooks1

And the latest Apple Asset Guide states: "To ensure proper viewing of images in content, use the HTML img tag instead of wrapping images in svg:img."

I just filed rdar://23772057 asking Apple to either remove that paragraph from their documentation or explain what the heck they're talking about. The SVG namespace doesn't have an img tag. The correct tag would be svg:image. So that paragraph borders on pure gibberish, as anything containing an svg:img tag wouldn't even pass epubcheck validation.

I'm guessing this is a case of miscommunication between an engineer and a tech writer who didn't fully grasp the intricacies of XHTML namespaces and other minutiae. Heck, I barely grasp the intricacies of it, and I've been doing this for longer than I care to admit.

[eggheadbooks1]

Years ago, I built a book for a friend using what was then the standard SVG wrapper, that looked, for example, like this:

<svg xmlns="http://www.w3.org/2000/svg" style="max-width:800px; max-height:1200px" height="90%" preserveAspectRatio="xMidYMid meet" width="90%" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" viewBox="0 0 800 1200" > <image alt="" height="1200" width="800" xlink:href="../Images/cover.jpg"></image>
	 </svg>

which appears at a cursory glance to be the same as you indicate. Unfortunately, in iBooks the images would still split across screens, as per the Apple bug; the SVG wrapper didn't fix it. Placing them in frames like Apple now dictate is supposed to solve the problem. Alas, the way they ask for the images to be coded doesn't make sense if one has both vertical and horizontal images.

So I'm stumped.

[dgatwood]

There are several reasons your approach didn't work:

1. The screen isn't necessarily 800x1200, so that won't necessarily fill a page.
2. There's no page-break-before to force it to begin at the start of a page.
3. Even if you included page-break-before, the height:90% would still not be 90% the height of the viewport, but rather 90% the height of the enclosing container (the body element), I think.

The SVG wrapper approach requires the image to be by itself in an HTML file, with nothing else in that file. That way, the 100% width and height on the top-level element (html) are relative to the viewport height, the 100% dimensions on the next element (body) are relative to the html element (which is equal to the viewport size), etc.

[eggheadbooks1]

The SVG wrapper I included was, as I said, from some years ago. And yes, 800x1200 is no longer the norm. The code was just by way of example of the SVG wrapper that Apple did not and, as far as I know, continues not to, read. Which is why I did not use it with this latest project.

SVG-wrapped images have never required the image to be in its own HTML file. I produced my image-heavy manuals between 2009 and 2012 using the SVG wrapper and the images were interspersed throughout the text. There is no need, or indeed desire, for images to have a page break before them in many cases.

The "height=90%" attribute caused the image to display at 90% of the screen. However, if 90% of the screen was larger than, in the above example, 1200 pixels, the SVG wrapper's max height and width attributes prevented small images from being resized in larger screens. Instead of displaying at 90%, the image would display at 1200 pixels, whatever percentage of the screen that was.

When the first-generation larger screens appeared but many people did not have images of sufficient size to accommodate these new larger screens, the SVG wrapper prevented unsightly uprezzing. The SVG wrapper also prevented image distortion on the new rotating screens, and thus became a staple of ebook coding.

However, the programming of latest-generation devices with regard to image handling has become in a sense the new DRM -- it's a way to force publishers to produce retailer-specific files and therefore force consumers into brand "loyalty."

Which is why we are stuck here with this stupid Apple problem and so far no solution.

[Hitch]

Originally Posted by eggheadbooks1

I'm trying to help an elderly friend who has written a book for her kids and wants to be able to give it to them as an ePub. Problem is, she has an iPad and uses iBooks while her children use a mix of iPads (various generations) and Android tablets, and has no idea which of the myriad of ePub apps they might be using.

Apple dictate that all images must be placed in containers (to work around the bug they refuse to fix) and they ask for images to be coded as:

HTML:
<div class="image-container">
<img src="images/bears.jpg" alt="three bears peer at goldie locks"/>
</div>

CSS:
img {height: 100%;}
.image-container {height: 100%;}

(Note: they actually ask for "height: 100vh", but nothing else I know of reads vh so I use %, which iBooks still reads.)

I also added a second image container for horizontal images:

.image-container2 {width: 100%;}

Problem is, the code works only for vertical images: horizontal images are stretched (distorted) to 100% screen height because of the (stupid) img value.

If one changes the img value to 100% width, then horizontal images work but not vertical.

How, then, does one code as Apple dictates but have both vertical and horizontal images in your ebook?

I tried to fix the problem by removing the img value from the CSS and creating classes I could add to divisions and to the img tag:

CSS:
.imageV {height: 50%; text-align:center; margin-bottom: 1em;}
.imageH {width: 100%; text-align:center; margin-bottom: 1em;}
.imageC {height: 100%; text-align:center;}
.vertical {height:100%;}
.horizon {width:100%;}

HTML:
<div class="imageV">
      <img class="vertical" alt="child" src="../Images/child.jpg"/>
    </div>

<div class="imageH">
      <img class="horizon" alt="mother" src="../Images/mother.jpg"/>
    </div>

Well, this works great in ADE, Aldiko, Kobo, but not in iBooks because it ignores the class in the img tag. The horizontal images work but not the 50% vertical ones. Those are ballooned up to the full screen even though the container is only 50% of the screen.

Help!

Well...here are my questions. You're setting 100%, as the width/height, of the images? Not max-width, or max-height, but simply height:100%? So, you are setting the image to be 100% of the containing div, which is also 100%? (for the landscape images). Have you tried using max-width, to control what's happening with those landscape images?

If memory serves, there were issues with the first-gen iPad, too, surrounding images. I think I'm correct when I say that we worked around it by embedding the images in not 1, but 2, divs. The first one set the h/w of the area, the second was to set the size of the image itself, and THEN we put the image inside the nested div, at 100% max-height/width. (So, 100% div, with an X% div inside, say, 50% in this instance, and then 100% max-width for the image, inside that 50% container div. See what I mean?)

Have you tried either doing that--two divs and a nested image tag--or using max-height/width?

And SVG may well be your answer, but I wanted to ask about the nested divs and the max-XXX factors.

Hitch

[eggheadbooks1]

You're setting 100%, as the width/height, of the images? Not max-width, or max-height, but simply height:100%? So, you are setting the image to be 100% of the containing div, which is also 100%? (for the landscape images). Have you tried using max-width, to control what's happening with those landscape images?

Yes, not max height but a set value. We wanted the vertical images to be 50% of the screen size (these were at the start of chapters beneath the heading and a quote); only the cover was 100%. The horizontal images, also at chapter starts, were 100% width. So I created a div class that set the container size and then I created a class to set the image size in the container. Worked as expected in everything but Apple, because Apple ignores anything in the img tag.

I hadn't tried the double nest approach. If I understand correctly, you are creating another level of div so as to avoid the need to put a class in the img tag. Correct?

I loved the SVG wrapper but it doesn't work in iBooks, at least not in my experience. Books using the SVG wrapper still had images sometimes split over screens in iBooks. And the latest-generation Kobos also ignore it. Last year, when I published the latest edition of my self-pubbing book that has a lot of images, I put them in SVG wrappers as I had before and tested the ebook on the Arc -- got image distortion. SVG worked perfectly on my older-generation Kobo Touch, but out of luck with the Arc.

[eggheadbooks1]

I should add the problem isn't with the horizontal images, it's with the vertical ones. In iBooks they were ballooning to the full screen size instead of 50% as coded. I don't get it. The img tags of "vertical" and "horizontal" were for the other devices, whereby if you don't set the size in the image tag the images balloon up to their pixel dimensions; they're not shrunk to fit the screen. I assumed eBooks would read the div in the CSS that limited the vertical images to 50%, but it isn't happening.

Problem is, I don't have an iPad or Mac to test on, which is why I really didn't want to do this to start with. And what started out as "Okay, no images" turned into "Couldn't we try just a few?" to "The [vertical] images are too big" but no real explanation as to what that means. Sigh.

[Hitch]

Originally Posted by eggheadbooks1

I should add the problem isn't with the horizontal images, it's with the vertical ones. In iBooks they were ballooning to the full screen size instead of 50% as coded. I don't get it. The img tags of "vertical" and "horizontal" were for the other devices, whereby if you don't set the size in the image tag the images balloon up to their pixel dimensions; they're not shrunk to fit the screen. I assumed eBooks would read the div in the CSS that limited the vertical images to 50%, but it isn't happening.

Problem is, I don't have an iPad or Mac to test on, which is why I really didn't want to do this to start with. And what started out as "Okay, no images" turned into "Couldn't we try just a few?" to "The [vertical] images are too big" but no real explanation as to what that means. Sigh.

So...you can't SEE the issues? Only your client can? Sweet baby Jesus. That's a nightmare.

Yes, I mean nested divs. You really need TWO divs, and, occasionally, a tag of 100% on the image as well. You set the original width on the first div--say, 50%; you set the second div to 100% of the first div, and the image to 100% of that. (I think we've also done 100-50-100, and IIRC, that works as well. Not counting 1st gens, which still have that bloody problem with images floating left at the top of the page will be overwritten with text.)

When iBooks was in its early incarnations, and iPads were 1st-gen, we on occasion used one div, a paragraph, AND an image tag--but it's really the same thing. Two containers, one image. Is it the spec? Hells, no, but that's Apple for you.

Hope that helps.

Hitch

[eggheadbooks1]

Yes, and that is why I stopped doing ebook conversions. I still do them for myself and for friends who cannot afford to hire someone like you, but otherwise I'm done with this craziness, at least when it comes to images. Images in Kindle books are easy because they are particular to Amazon, but with all the ePub apps out there, and everyone programming differently, it's a nightmare.

I'm beginning to suspect that iBooks has an option to turn off publisher formatting, like many other ePub apps do, and that this may have been the culprit from the start. Do you know if it does? I Googled it but nothing came up.

I much prefer sticking to my day job, which is as a writer and editor. Language may evolve and change but at least different devices don't change the words (though give Apple time and I'm sure they'll do something there too).

(That said, there was some bizarre Christian app that would change "offensive" words in one's ebooks. You would get crazy stuff like "The witch gave birth to a litter of puppies" or "You anus, I hate you!")

[Hitch]

Originally Posted by eggheadbooks1

Yes, and that is why I stopped doing ebook conversions. I still do them for myself and for friends who cannot afford to hire someone like you, but otherwise I'm done with this craziness, at least when it comes to images. Images in Kindle books are easy because they are particular to Amazon, but with all the ePub apps out there, and everyone programming differently, it's a nightmare.

Well...it requires several things. It requires doing it fairly full-time, so that you can keep up with what works on what devices. You need to know what fonts will work at Amazon, for example. Or won't. Or will be stripped--and how. The proliferation of cheap ePUB-reading apps certainly hasn't helped, but I know that I and most of the commercial builders now simply tell clients that the books are created for the main platforms--Amazon, B&N, iBooks & KoboBooks, on devices, and that's that. There are far too many Droid-based readers that will drive you bonkers.

I'm beginning to suspect that iBooks has an option to turn off publisher formatting, like many other ePub apps do, and that this may have been the culprit from the start. Do you know if it does? I Googled it but nothing came up.

There's a publisher font option, yes, on the K4IOS app. At least two of the Kindle devices have this as well. Not on the iBooks app, although you can change the fonts.

I much prefer sticking to my day job, which is as a writer and editor. Language may evolve and change but at least different devices don't change the words (though give Apple time and I'm sure they'll do something there too).

(That said, there was some bizarre Christian app that would change "offensive" words in one's ebooks. You would get crazy stuff like "The witch gave birth to a litter of puppies" or "You anus, I hate you!")

There was a fairly lengthy thread on this forum, somewhere--one of the sub-fora--about that very app. But if memory serves, the copyright holder/publisher of the book had to agree, or...something. I think it kind of died a slow death (the app, I mean).

Hitch