View Full Version : EPUB validates, and breaks in iBooks


_savage
01-23-2013, 07:05 AM
Hello,

(Duplicate of this (http://www.mobileread.com/forums/showthread.php?t=203612) post, because I wasn't sure which forum would be more appropriate.)

I am a bit baffled. Been building EPUB books that validate without errors/warnings in "epubcheck", which work just fine on my Nook, various applications including ADE, convert to .mobi using Kindlegen... No problems at all.

Then today I tried them on an iPad and everything looks just very broken

- In portrait mode, the text on a page is cut off on the right side and it seems they indent too much on the left side of the page. Some work in double-page landscape, but some also cut of in landscape mode.

- They seem to have empty pages inserted after each short page-chapter. I use chapters to enforce a page break, and so (in the beginning of the book) there are short one-page chapters with a dedication and such. Each of those is followed by an empty page.

- Looks like the cover image is a page of its own, but not on the actual front cover of the book. I mean that the book (in iBooks) doesn't open visually, it is already open with a cover image rendered onto the first page, and I just turn the page like any other page.

- The weirdest thing though is that none of the chapters render for more than two pages. The chapters of the book should be many pages long, but only the first two are rendered, followed by the next chapter!?

I am lost here, to be honest. I didn't use any iBook specific tags/tricks, and I (wrongly, so it seems) assumed that a validated EPUB is a "safe enough" implementation. Wrong, huh?

Has anybody seen the same issues, similar issues, and can offer tips and experience regarding their solution? Any help and insight is appreciated :-)

Thanks!

Toxaris
01-23-2013, 07:48 AM
I wrote something about that quite some time ago. There is something in your stylesheet causing this. Can you post your stylesheet, especially the html, body and @page if it is there.

Toxaris
01-23-2013, 08:36 AM
I did a quick check in my notes and it appears that there were two culprits here. It might be that one is solved though.
If you have height:100% in your body and/or html classifiers in the stylesheet, this might occur. I also found this behavior when the @page is in the stylesheet, this was not really supported in iBooks. That might have been changed though.

_savage
01-23-2013, 02:53 PM
Thanks for the response. The stylesheets vary across the books. The one that gets cut off but doesn't have its chapters truncated
html {
width: 100%;
height: 100%;
}
whereas this stylesheet is for the book which has its chapter content truncated to a single page size
html, body, table {
width: 100%;
height: 100%;
margin: 0;
padding: 0;
border-width: 0;
}
Let me see what happens when I remove width/height in both cases...

JSWolf
01-23-2013, 03:07 PM
Why do you have width and height in html and body? You don't need them there.

body {
widows: 0;
orphans: 0;
margin-top: 0;
margin-bottom: 0;
margin-left: 0;
margin-right: 0;
text-align: justify
}

That is all you need. If you need something just for the table, use a different style. You also do not need a style for html.

_savage
01-24-2013, 06:59 AM
Toxaris, JSWolf: Nice, that seems to have taken care of almost all the issues :-)

What about the cover image though? Is that normal that it renders on the first page, instead of looking like an actual book cover one opens?

JSWolf
01-24-2013, 09:48 AM
Toxaris, JSWolf: Nice, that seems to have taken care of almost all the issues :-)

What about the cover image though? Is that normal that it renders on the first page, instead of looking like an actual book cover one opens?

Yes, it is correct for the cover image to be the first page.

_savage
01-24-2013, 03:02 PM
Yes, it is correct for the cover image to be the first page.

That doesn't make much sense visually :smack:

I'd have thought that the cover image is rendered as an actual book cover, one "opens" the book, and then starts to turn pages... Ah well.

dgatwood
01-24-2013, 11:22 PM
Why do you have width and height in html and body? You don't need them there.


The only time it might be useful to have height on the html and body tag is if you're doing a single-page fixed-layout spread, such as a dedication page with a single line centered vertically. In paged media, a height of 100% means one page height (or at least it is supposed to—not all renderers seem to get this right).

JSWolf
01-24-2013, 11:26 PM
The only time it might be useful to have height on the html and body tag is if you're doing a single-page fixed-layout spread, such as a dedication page with a single line centered vertically. In paged media, a height of 100% means one page height (or at least it is supposed toŚnot all renderers seem to get this right).

All fixed layout ePub is different as it was designed before ePub 3. So each engine that supports fixed layed does it it's own way.

_savage
01-25-2013, 02:49 AM
The only time it might be useful to have height on the html and body tag is if you're doing a single-page fixed-layout spread, such as a dedication page with a single line centered vertically. In paged media, a height of 100% means one page height (or at least it is supposed toŚnot all renderers seem to get this right).

Hah! That's why I had put it there: to center an image on a single page :) Glad I did that right! (But then the width/height crept into the rest of the book.)

However, on the iPad this single page caused an empty page to follow, but I _suspect_ that's because of the "width:100%". (I noticed that the width seemed to refer to landscape/double-page rendered width!)

_savage
01-25-2013, 05:53 PM
body {
widows: 0;
orphans: 0;
...
}

I noticed the "widows" and "orphans" here, and added them to my styling. I assume it's these two that affect the spacing/stretching between paragraphs to fill a page, and to avoid paragraph breaks that would create widows and orphans.

Frankly, I am torn about this. Do I mind looking at widows/orphans if it gets me consistent spacing? Or do I accept large(er) gaps between paragraphs to avoid them?

Hmmm... :chinscratch:

DiapDealer
01-25-2013, 06:19 PM
The widows and orphans bit is just Jon pushing his own agenda. Don't use them if you don't want to. ;)

dgatwood
01-25-2013, 10:04 PM
All fixed layout ePub is different as it was designed before ePub 3. So each engine that supports fixed layed does it it's own way.

I'm not talking about fixed-layout EPUB. I'm talking about doing a single pseudo-fixed-layout page in a flowing book using either an image or SVG (which I suppose is technically an image, sort of, but...).

dgatwood
01-25-2013, 10:06 PM
Hah! That's why I had put it there: to center an image on a single page :) Glad I did that right! (But then the width/height crept into the rest of the book.)

However, on the iPad this single page caused an empty page to follow, but I _suspect_ that's because of the "width:100%". (I noticed that the width seemed to refer to landscape/double-page rendered width!)

You're setting the body height to 100% of height of your page, and then any top and bottom margins/padding/border on the body/html elements are added to that, making the total height greater than will actually fit on a page. If you set height to 100%, be sure to zero the margins, padding, and border for the html and body tags, too. (Not that any renderer will realistically set a default value for the border property, mind you—I'm being a little pedantic with that one.)

And be sure to not include any such hacks in actual flowing content. :)

_savage
01-25-2013, 10:24 PM
There's only one stylesheet in my book, and it contains these settings:body {
/* widows: 0; */
/* orphans: 0; */
margin: 0;
padding: 0;
border: 0;
}
I used to have a "width:100%;" and "height:100%;" in it as well, but I removed that as per above discussion.

If I understand you correctly then I should add a "height:100%;" to the single pseudo-fixed-layout page (the one with the dedication, for exampe). This would ensure a correct vertical centering of that page's content:
<body style="height:100%;">
...
</body>

dgatwood
01-25-2013, 10:32 PM
There's only one stylesheet in my book, and it contains these settings:body {
/* widows: 0; */
/* orphans: 0; */
margin: 0;
padding: 0;
border: 0;
}
I used to have a "width:100%;" and "height:100%;" in it as well, but I removed that as per above discussion.

If I understand you correctly then I should add a "height:100%;" to the single pseudo-fixed-layout page (the one with the dedication, for exampe). This would ensure a correct vertical centering of that page's content.

Ensure is too strong a term. As far as I can tell, iBooks seems to sometimes ignore this (because of an underlying WebKit bug; I filed a bug about it yesterday). However, I would say that it increases the probability of the reader getting it right. :)

Also, you should not be setting the margins to zero on normal, flowing pages. I've seen some readers (Kobo on iOS) break when I do that. YMMV. As a rule, you should avoid styling the HTML and BODY tags (beyond possibly setting fonts) unless you're doing something very unusual, such as the aforementioned special single-page layouts.

_savage
01-25-2013, 10:37 PM
Quite the opposite of what JSWolf seems so say :-) I've never had a chance to try the books on Kobo, unfortunately.

JSWolf
01-25-2013, 10:40 PM
I noticed the "widows" and "orphans" here, and added them to my styling. I assume it's these two that affect the spacing/stretching between paragraphs to fill a page, and to avoid paragraph breaks that would create widows and orphans.

Frankly, I am torn about this. Do I mind looking at widows/orphans if it gets me consistent spacing? Or do I accept large(er) gaps between paragraphs to avoid them?

Hmmm... :chinscratch:

Widows and orphans have nothing to do with paragraph spacing.

Widow
A paragraph-ending line that falls at the beginning of the following page/column, thus separated from the rest of the*text.

Orphan
A paragraph-opening line that appears by itself at the bottom of a*page/column.
A word, part of a word, or very short line that appears by itself at the end of a paragraph. Orphans result in too much white space between paragraphs or at the bottom of a*page.

You do end up with a ragged end of page. I prefer to have the end of most pages end at the same place regardless of how a paragraph is split. ADE defaults to a widow and orphan values of two.

JSWolf
01-25-2013, 10:43 PM
The widows and orphans bit is just Jon pushing his own agenda. Don't use them if you don't want to. ;)

But he's not using them for an incorrect understanding of how they work. Instead of getting things all wrong, it would have been better to help by explaining what widows and orphans actually are.

_savage
01-26-2013, 04:38 PM
But he's not using them for an incorrect understanding of how they work. Instead of getting things all wrong, it would have been better to help by explaining what widows and orphans actually are.

I know what windows and orphans are :) Back in the days when I used LaTeX quite extensively, I ventured into the type setting field which was quite interesting.

Widows and orphans have nothing to do with paragraph spacing.

You do end up with a ragged end of page. I prefer to have the end of most pages end at the same place regardless of how a paragraph is split. ADE defaults to a widow and orphan values of two.

I disagree, and so does LaTeX for example. Both, Nook and LaTeX seem to aim at preventing ragged page ends by (subtly) increasing the spacing between paragraphs or other objects on your page in order to avoid widows and orphans. But that, sometimes, was too aggressive and I ended up with gaps in the text flow that I thought disrupting.

It doesn't really matter to me on an eReader device, to be honest. This should be a user setting, not an eBook setting. It does matter for printed books though, but that's not what I'm doing here anyway :)

JSWolf
01-26-2013, 07:38 PM
I know what windows and orphans are :) Back in the days when I used LaTeX quite extensively, I ventured into the type setting field which was quite interesting.



I disagree, and so does LaTeX for example. Both, Nook and LaTeX seem to aim at preventing ragged page ends by (subtly) increasing the spacing between paragraphs or other objects on your page in order to avoid widows and orphans. But that, sometimes, was too aggressive and I ended up with gaps in the text flow that I thought disrupting.

It doesn't really matter to me on an eReader device, to be honest. This should be a user setting, not an eBook setting. It does matter for printed books though, but that's not what I'm doing here anyway :)

With widows and orphans both set to zero, ADE does not monkey with line spacing between paragraphs. That is what you said widows and orphans (set to zero) would do and they won't do that.

_savage
01-29-2013, 07:01 AM
Just when I thought things started to work on an iPad...

I noticed that text flows into an image: ...
</p>
<div style="width:45%; float:left;"><img ... /></div>
<p>
...
This seems to work ok when the paragraph does not break across pages. When it does, however, the image starts at the top of the new page and is scaled correctly. However, the first line of the paragraph on the new page crosses the full width of the page (like on the page before where the image didn't fit) before subsequent lines are rendered next to the image.

I thought this could be solved by avoiding widows and orphans, but that didn't change a thing. There was some talk about wrapping the <img> into a <span> but that didn't work either (it's already wrapped in a <div> anyway).

Is this a page height issue? Or how do I go about this?

Jellby
01-29-2013, 03:40 PM
What happens if you apply the style to the <img> rather than the <div>?

_savage
01-30-2013, 06:33 AM
What happens if you apply the style to the <img> rather than the <div>?

That's actually where I come from: it didn't work. I then read (http://www.pigsgourdsandwikis.com/2011/04/resizing-images-in-epub.html) that, in order to scale images for some readers, one ought to wrap the image in a scaled <div> element. So I did that which took care of the proper scaling, yet that one line of text is being rendered over the image...

dgatwood
01-30-2013, 06:53 PM
Top margin difference between the paragraph and the div, maybe?

_savage
01-31-2013, 04:06 AM
Top margin difference between the paragraph and the div, maybe?

Hmm... thanks for the hint! I tried to add some padding to the <div>
...
</p>
<div style="width:45%; float:left; padding:1em 1em 1em 0;"><img ... /></div>
<p>
...
which moves the image down so that the one line of text doesn't render across the image. (There's some overlap still, but that can be fixed with 1.5em or so.)

However, because the <div> floats left I hoped that the top of the image and the top of the paragraph would line up. As it is now the image is 1em further down.

Also, should I used padding or margin here?

Thanks :thumbsup:

Turtle91
01-31-2013, 08:15 AM
Just when I thought things started to work on an iPad...

I noticed that text flows into an image: ...
</p>
<div style="width:45%; float:left;"><img ... /></div>
<p>
...


According to the article you linked there is a second part to the solution. The first part is to wrap the image in a scaled <div> as you have done. The second part is to add a 'width="100%" ' to the <img>. I didn't see that in your code ...

Hey, I wonder, if everyone STOPPED accommodating the buggies in iBooks with all these workarounds, do you think Apple would get off their A$$le and FIX it?? Sort of like a union strike?? "ePubbers United"!!!:ban::dots:

_savage
02-01-2013, 03:39 AM
According to the article you linked there is a second part to the solution. The first part is to wrap the image in a scaled <div> as you have done. The second part is to add a 'width="100%" ' to the <img>. I didn't see that in your code ...

It's not in the code I posted, but it's in my book. That didn't change a thing.

Hey, I wonder, if everyone STOPPED accommodating the buggies in iBooks with all these workarounds, do you think Apple would get off their A$$le and FIX it?? Sort of like a union strike?? "ePubbers United"!!!

I'm very tempted to not bother bending over backwards just to please the iBooks audience. I'd rather have an eBook which conforms closer to the standards... So yes, I am with you on the strike :2thumbsup

dgatwood
02-02-2013, 04:03 PM
According to the article you linked there is a second part to the solution. The first part is to wrap the image in a scaled <div> as you have done. The second part is to add a 'width="100%" ' to the <img>. I didn't see that in your code ...

Hey, I wonder, if everyone STOPPED accommodating the buggies in iBooks with all these workarounds, do you think Apple would get off their A$$le and FIX it?? Sort of like a union strike?? "ePubbers United"!!!:ban::dots:

There may have been a lot of bugs in the past, but I haven't experienced very many actual bugs in current versions of iBooks. Out of the huge list of CSS quirks that I've been putting together on the EPUB page on the MobileRead wiki, only two or three of them are quirks in iBooks. The other 19 bugs are are in one version of ADE or another.

Turtle91
02-02-2013, 08:53 PM
There may have been a lot of bugs in the past, but I haven't experienced very many actual bugs in current versions of iBooks. Out of the huge list of CSS quirks that I've been putting together on the EPUB page on the MobileRead wiki, only two or three of them are quirks in iBooks. The other 19 bugs are are in one version of ADE or another.

Well, that's some good news. Any buggies noted from their current rendition of ePub3??

dgatwood
02-03-2013, 07:39 PM
Well, that's some good news. Any buggies noted from their current rendition of ePub3??

I have no idea. I'm sticking solidly with EPUB 2.0.1. :)

Turtle91
02-03-2013, 07:59 PM
Hmmmm.....well, I still want to have a strike!!! Maybe against Amazon??!!?? Please!

_savage
02-04-2013, 05:29 PM
So what am I to do about the floating text issue then? Think up some margin value and hope that iBook gets it right and floats the text correctly? Probably not going to go that way.

Also, what's preferable: margin or padding in this context?

dgatwood: Uh, which thread is that?

Turtle91: To the barricades! The guilty ones will feel guilty, we don't have to choose for them. Just to the barricades! :swear:

dgatwood
02-06-2013, 12:47 AM
So what am I to do about the floating text issue then? Think up some margin value and hope that iBook gets it right and floats the text correctly? Probably not going to go that way.


First, make sure that it's really a bug. Try putting the same content in at the top of an HTML file and see what it does in a browser (e.g. Chrome, Safari, and/or Firefox). Experiment with setting the @page margins, and the margins for the html and body tags to zero and nonzero values when you do so. If you're able to make it behave the same way in a browser as it behaves in iBooks, then the issue is that the upper margin of the floated image is greater than the upper margin of the paragraph, and you need to fix that. If it behaves differently, try adding:


html {
-webkit-line-box-contain: block inline replaced !important;
line-box-contain: block inline replaced !important;
}


to the style sheet, and if that fixes it in iBooks, let me know, because it will give me more ammunition to push them to fix a bug that I filed. :)

If that doesn't fix the problem in iBooks *and* it doesn't behave that way in a browser, then please file a bug with Apple at bugreport.apple.com and post the bug number or PM me. I'd be interested to find out what the underlying issue is.



dgatwood: Uh, which thread is that?


You mean where I posted a big giant list of known bugs? It's not a thread. It's on the wiki site:

http://wiki.mobileread.com/wiki/EPub#CSS_Tips

Toxaris
02-06-2013, 02:41 AM
Does iBooks support @page already?

Also, if a lot of -webkit entries are required in a stylesheet to ensure that iBooks behave, I do not consider that to be a good thing...