ADE adds blank pages?

[Psymon]

Originally Posted by Jellby

- Use a dummy element after the pagebreak. This is something like your solution, but keep your margin-top in the <h1>. Or actually use the dummy element to introduce the pagebreak:

<div class="full-page-image">
<img ... />
</div>

<div class="pagebreak" style="page-break-before:always; height:0; margin:0; padding:0"></div>

<h1 style="margin-top:42px">Title</h1>

Ah, I think I'll do that one! Thanks!

That page-break thing does work "everywhere", though? I have this weird feeling that I read somewhere (ages ago) that some devices or apps just ignore it.

One question about the code you gave, where you had this...

<div class="pagebreak" style="page-break-before:always; height:0; margin:0; padding:0"></div>

...re the class="pagebreak", is there something I should be putting in my stylesheet to go along with that?

Thanks again! This is so reassuring, to think that this will actually resolve my original problem!

EDIT: I'm slow. I gather that all I need to do, from what you said, is basically put this in my HTML...

<div class="pagebreak"></div>

...and then this in my stylesheet...

div.pagebreak {page-break-before:always; height:0; margin:0; padding:0;}

I think I was overthinking it -- I gather that's what you meant, though?

[Jellby]

Yes, that's what I meant. I'm not sure it will work everywhere, probably not, I'd bet there are some readers that don't honour pagebreaks, but I guess there would be a few other things that wouldn't work. For some renderers you may have to include some content in the <div>, or it will be discarded: <div class="pagebreak">&nbsp;</div> should be enough.

There's a caveat with this solution (or with forcing pagebreaks in general): the page numbers in ADE will ignore this pagebreak, i.e., there will be no new page number after the pagebreak, it will just continue being the same "page" as before.

[Psymon]

Originally Posted by Jellby

Yes, that's what I meant. I'm not sure it will work everywhere, probably not, I'd bet there are some readers that don't honour pagebreaks, but I guess there would be a few other things that wouldn't work. For some renderers you may have to include some content in the <div>, or it will be discarded: <div class="pagebreak">&nbsp;</div> should be enough.

Oh, okay, thanks -- I'll put that space in my div, then.

I guess there's not much I can do -- no matter how I tried to do this -- about older (or crappier) devices that would ignore what I'm trying to accomplish here, but hopefully in time these things will just be the norm.

If/when I decided to convert my EPUB to MOBI format, for Kindle, are there any issues related to this that I should know about? I do hope that I don't have to completely re-think (and re-do) everything for that.

There's a caveat with this solution (or with forcing pagebreaks in general): the page numbers in ADE will ignore this pagebreak, i.e., there will be no new page number after the pagebreak, it will just continue being the same "page" as before.

Oh, gee, I took a look and you're right! That's weird. Well, I suppose most people won't be paying too close attention to the page numbering anyway in their e-readers -- they're not exactly "burned in stone" anyway, of course.

Thanks so much for your help, Jellby -- as always! You should get a medal for the number of times you've saved the day (for me, and others).

[Psymon]

Oh, I forgot to ask...

Does it matter at all if/when one uses page-break-before or page-break-after? Is there, in fact, any real difference? I mean, apart from one being "before" and the other "after" (duh), but I guess I was thinking that where I have a single file split up into separate "pages", like this...

Chapter Title Page
Full Page Image
Chapter Text

...then should I have the page break after the Chapter Title be after? I was just thinking that if I made it before, then that bit of code -- as "empty" as it might be -- would invariably be inserted on the same page as the full-page image, and somehow screw that up.

In that regard, would I be better off just using a combination of "befores" and "afters", depending on whether there's a full-page image before or after?

[Jellby]

Originally Posted by Psymon

I was just thinking that if I made it before, then that bit of code -- as "empty" as it might be -- would invariably be inserted on the same page as the full-page image, and somehow screw that up.

Even if the dummy div would formally be in the page with the full-page image, in my tests at least it has not affected how things are displayed (but I don't think I've tried this particular test). If you find (or fear) that it does, you could indeed have two separate "pagebreak" classes, one for before and one for after.

But, on the other hand, the reason for having the dummy div is that you want to keep whatever top-margin you have defined, and not get it turned into 0. In your case you probably want 0 anyway, so maybe this is enough:

<!--Chapter Title Page-->
<div class="fullpage">
  <img ... />
</div>
<div class="pagebreak"/>
<!--Chapter Text-->

and you just add "page-break-before: always" to the div.fullpage style.

[Psymon]

Originally Posted by Jellby

In your case you probably want 0 anyway, so maybe this is enough:

<snip>

Ah, okay. Well, I actually just finished re-doing every page (of relevance) in my whole book, using both "befores" and "afters", wherever was appropriate, and it seems to have worked out great with no problems, both in ADE and in iBooks, so I guess I'll just leave it at that. I think I need a nap now!

Thanks so much once again, Jellby!

[DaleDe]

Originally Posted by Psymon

Oh, I forgot to ask...

Does it matter at all if/when one uses page-break-before or page-break-after? Is there, in fact, any real difference? I mean, apart from one being "before" and the other "after" (duh), but I guess I was thinking that where I have a single file split up into separate "pages", like this...

Chapter Title Page
Full Page Image
Chapter Text

...then should I have the page break after the Chapter Title be after? I was just thinking that if I made it before, then that bit of code -- as "empty" as it might be -- would invariably be inserted on the same page as the full-page image, and somehow screw that up.

In that regard, would I be better off just using a combination of "befores" and "afters", depending on whether there's a full-page image before or after?

The page break before is more likely to be supported than page break after on some older devices. But both should be supported as well as page break avoid (which has less support).

Dale

[Psymon]

Originally Posted by DaleDe

The page break before is more likely to be supported than page break after on some older devices.

Oh, okay. Well, just to be safe I did a search & replace to change all the "afters" to "befores" -- as it turned out, in the whole book I'd only had one of them! -- and in both ADE and iBooks it didn't seem to cause anything funny happening, so that's good.

Thanks for the follow-up, Dale! Good to know not to use the "after" one (for the sake of some older devices out there).

[Jeff L]

Originally Posted by Psymon

... see the frontispiece and title page opposite each other (and/or whatever else might look nice like that, side-by-side).

If you have oeb-column-number set globally in your CSS, then have your frontispiece and title page in one file and have that file set with <body style="oeb-column-number: 2">. The file setting will override the CSS.

Or do it all at the file level so you always see what each page is doing. That is, do a search and replace and have all <body> changed to <body style="oeb-column-number: 1"> and then reset to 2 as needed.

Originally Posted by Jellby

For some renderers you may have to include some content in the <div>, or it will be discarded: <div class="pagebreak">&nbsp;</div> should be enough.

If I recall, this is a QT issue. Since you're using Sigil, you may want to use & #160; (close the gap in the code of course) instead of &nbsp;. The discussion about that is too long for me to recall what the problem was. Perhaps I'm mistaken and it's the other way around. Maybe someone can chime in on that.

[Jellby]

Hmm... as pointed by davidfor in another thread, w3schools says about "page-break-after":

Note: You cannot use this property on an empty <div> or on absolutely positioned elements.

I wonder where this comes from. I don't recall seeing anything about that in the spec, maybe it's just an oblique reference to the fact that some renderers (wrongly, as far as I know) discard empty elements.

[Psymon]

Originally Posted by Jellby

Hmm... as pointed by davidfor in another thread, w3schools says about "page-break-after":

Note: You cannot use this property on an empty <div> or on absolutely positioned elements.

I wonder where this comes from. I don't recall seeing anything about that in the spec, maybe it's just an oblique reference to the fact that some renderers (wrongly, as far as I know) discard empty elements.

Well, plopping an &nbsp; in there would effectively make it "not empty", right?

[Psymon]

Originally Posted by Jeff L

If you have oeb-column-number set globally in your CSS, then have your frontispiece and title page in one file and have that file set with <body style="oeb-column-number: 2">. The file setting will override the CSS.

Or do it all at the file level so you always see what each page is doing. That is, do a search and replace and have all <body> changed to <body style="oeb-column-number: 1"> and then reset to 2 as needed.

Oh, those are interesting ideas, too -- thanks! I think what I've done now will work for this current book, but I'll definitely keep that in mind in the future.

If I recall, this is a QT issue. Since you're using Sigil, you may want to use & #160; (close the gap in the code of course) instead of &nbsp;. The discussion about that is too long for me to recall what the problem was. Perhaps I'm mistaken and it's the other way around. Maybe someone can chime in on that.

You've got me curious about that, too, whether I should (or should not!) be changing all my "filler" spaces that I've used in that way -- hope someone will reply, one way or the other (and hopefully with an explanation).

[dgatwood]

Originally Posted by Jellby

Hmm... as pointed by davidfor in another thread, w3schools says about "page-break-after":

Note: You cannot use this property on an empty <div> or on absolutely positioned elements.

I wonder where this comes from. I don't recall seeing anything about that in the spec, maybe it's just an oblique reference to the fact that some renderers (wrongly, as far as I know) discard empty elements.

The empty div bit is bizarre. I can't imagine how that came from the spec. The absolutely positioned element bit... that was hard track down, because it isn't so much stated as implied very obliquely in thick, obfuscated language, but here it is:

User Agents must apply these properties to block-level elements in the normal flow of the root element. User agents may also apply these properties to other elements, e.g., 'table-row' elements.

So agents must support these properties on statically positioned (and presumably relatively positioned) block-level elements, and may optionally support them on non-block-level elements, absolutely positioned elements, or ostensibly even fixed-position elements.

So the comment isn't quite right in that the spec provides no prohibition against using these properties with absolutely positioned elements, but fully compliant UAs are allowed to completely ignore them if you do.

[Jellby]

Yeah, the "absolutely positioned elements" makes sense. Once you move an element out of the normal flow and place it on top of the page (say), you cannot ask for a pagebreak relative to this element.

Absolutely positioned elements are disencouraged in ePub 2 anyway.

[Hitch]

Originally Posted by Jellby

Yeah, the "absolutely positioned elements" makes sense. Once you move an element out of the normal flow and place it on top of the page (say), you cannot ask for a pagebreak relative to this element.

Absolutely positioned elements are disencouraged in ePub 2 anyway.

Just so I'm on the record:

Any possibility that we can all agree that we should NOT be using "px" to set vertical whitespace elements? Ems or % would really, really work better.

And all this, over the "blank page" (that doesn't exist), that's created, on the fly if/when the reader sizes the font in such a way, and uses font X instead of font y, and IF s/he has the iPad rotated to read in two-page/column mode...honestly, why all the drama?

Here's the thing: no matter how typographically perfect we want to make our work, they are NOT. PRINT. Books. Trying to force two pages to be on the left- and right-hand "pages" of a reader that may/mayn't be rotated in landscape, may/mayn't have font X, etc....What happens if you have a sight-impaired user who cranks up the font size, with that 42px "top-margin?" what happens THEN?

I am all for trying to make books as beautiful as possible, but sometimes, you can't work around certain things, like forcing readers to ONLY see a book in one-page mode. To me, that's the very definition of being anti-e-reader. What happens with that 42px top-margin/padding/whatever when this is purchased on an iPad mini or an iPhone? And when the ex libris overflows on the mini, what happens to that beautiful "two-page-spread" then?

We can be as artistic as we want, but we also need to accept what eBooks do well, and what they do NOT. A lot of what gets talked about (page break here, page-break before:, page-break after, etc.) doesn't work on all readers. And the "extra page thing?" Again: it's only relevant when someone is reading in LANDSCAPE mode. You know how often I see someone reading in landscape mode? NEVER. I mean it: NEVER. It's time to embrace the GOOD, and learn to GRACEFULLY live with the other.

Sorry to get off on a tear, but at the very least, let's try to avoid using PX for positioning in REFLOWABLE BOOKS.

</rant>

Hitch