About page-break

[JSWolf]

Originally Posted by icearch

And more test, yes, lot's of reader software does not work. Some do though.
Why it is so hard to put such basic and simple function to work?

Of course I read what you wrote. But doing it with page breaks may or may not work. Not all programs for reading ePub follow the rules. So making a new HTML file works in all cases.

[JSWolf]

Originally Posted by RbnJrg

You should use:

page-break-after: always|avoid; /* This is for epub2 (ADE RMSDK) */
break-after: always|avoid; /* This is for epub3 */
-webkit-column-break-after: always|avoid; /* This is for epub3, for ereaders that use webkit rendering engine */

You need to stop with the webkit code that's not valid ePub code. If the program being used needs the webkit code, then it's broken and needs to be fixed.

[JSWolf]

Originally Posted by icearch

By the way, the reader plugins in Sigil are pretty old, like the last update is in 2023, and the whole readium homepage in Github just vanished?

Is there any new / better reader plugin or whole other new ways to verify the file I'm making on the fly?

We know the page breaks will work with properly written programs. What you need to do is find dodgy programs and try them to see if they work.

[JSWolf]

Originally Posted by icearch

I think class really doesn't take that much space, so no harm to use when needed. If I want to not use this feature, there would just be more hassle I think.

In fact, just to my own preference, even most p in my book needs 2em indent, I still use class to let them indent, just because i need some p to be not affected.

The p you don't want a 2em indent, you just put in what sort of indent you want in the class. As you can see, the first paragraph after the </h2> is not indented. The second paragraph is indented. Also, if you use the class noindent, you'll do away with the indent. So your main paragraph style can be without a class.

HTML code

<h2>CHAPTER 1</h2>
<p>There were four black and whites already at the 7-Eleven when I arrived. Several people had gathered in the parking lot behind the yellow police tape, huddling close for protection against the freezing Chicago rain.</p>
<p>They weren’t there for Slurpees.</p>

CSS code

p {
  margin-top: 0;
  margin-bottom: 0;
  widows: 1;
  orphans: 1;
  text-indent: 1.2em;
}
h2 + p, .noindent {
  text-indent: 0;
}

[Turtle91]

Originally Posted by icearch

I think class really doesn't take that much space, so no harm to use when needed. If I want to not use this feature, there would just be more hassle I think.

In fact, just to my own preference, even most p in my book needs 2em indent, I still use class to let them indent, just because i need some p to be not affected.

Of course its all technique! Normally the most used style would be the default (plain tag), and the ones that are different from the norm would be given a class. It makes clean html and easier to see when something is supposed to be different.

For example:

h1 {text-indent:0; font-size:1.2em; font-weight:bold; text-align:center; margin:0 0 2em;
    page-break-after: avoid;
    break-after: avoid; 
    break-after: avoid-column;
   }

p        {text-indent:1.2em; text-align:left; font-family:serif}
        /* Or whatever your standard paragraph styling would be */
p.red    {color:red}
p.banner {text-align:center; margin:2em 0; text-indent:0; color:blue}

<h1>This is a Header Line</h1>
<p>This is a normal paragraph.</p>
<p>This is a normal paragraph.</p>
<p>This is a normal paragraph.</p>
<p class="red">This is a normal paragraph with red color.</p>
<p>This is a normal paragraph.</p>
<p>This is a normal paragraph.</p>
<p>This is a normal paragraph.</p>
<p class="banner">This is a paragraph with blue color, centered, and extra margins above and below.</p>
<p>This is a normal paragraph.</p>
<p>This is a normal paragraph.</p>
<p>This is a normal paragraph.</p>

I've seen some really nasty code that looks ridiculous when everything is given a class.

<h1 class="header">This is a Header Line</h1>
<p class="para">This is a normal paragraph.</p>
<p class="para">This is a normal paragraph.</p>
<p class="para">This is a normal paragraph.</p>
<p class="para red">This is a normal paragraph with red color.</p>
<p class="para">This is a normal paragraph.</p>
<p class="para">This is a normal paragraph.</p>
<p class="para">This is a normal paragraph.</p>
<p class="para banner">This is a paragraph with blue color, centered, and extra margins above and below.</p>
<p class="para">This is a normal paragraph.</p>
<p class="para">This is a normal paragraph.</p>
<p class="para">This is a normal paragraph.</p>

Which one is "cleaner" and easier to read??

[Falkor]

CSS page breaks in epub are a mess. I've tried to make them them work across ADE, Thorium, Calibre and Apple Books.

"break-after:column" is the modern property that is most widely supported (this requires column-fill: auto !important to be set for html and/or body). There is also "break-after: page" (sounds like it was intended for books) but they are not compatible with each other. When using both variants, the second one will override the first, no matter if it does anything or not. Kinda obvious, because it's the same property.

"break-after: always" and "break-after: all" are supposed to break after pages and colums. They didn't work in any reading software I tried.

There's also the legacy "page-break-after". It generally considered good practice include it for backwards compatibility. But apparently it can also override the page-break property.

Here is a little compatibility chart:

			ADE	Thorium	Calibre	Books
break-after: always	-	-	-	-
break-after: all	-	-	-	-
break-after: page	-	-	-	x
break-after: column	x	x	x	-
page-break-after:	-	-	x	x

and here is what happens if you combine them:

PBA/BAC:		x	x	x	-
PBA/BAP:		-	-	-	x
BAC/PBA:		-	-	x	x
BAC/BAP:		-	-	-	x
BAP/BAC:		x	x	x	-
PBA/BAP/BAC:		x	x	x	-
PBA/BAC/BAP:		-	-	-	x
BAP/BAC/PBA:		-	-	x	x
BAC/BAP/PBA:		-	-	x	x
BAC/PBA/BAP:		-	-	-	x
BAP/PBA/BAC:		x	x	x	-

"break-after: left;", "break-after: right;", "break-after: recto;" and
"break-after: verso;" would be useful for books, but I haven't found any reading software that supports them, either.

[graycyn]

Originally Posted by RbnJrg

Yes, indeed. And for that reason you need to have in the style:

   
   break-after: avoid;
   -webkit-column-break-after: avoid; /* This is for ereaders that employ multicolumn to display pages */

or

   
   break-after: avoid;
   break-after: avoid-column; /* This is for ereaders that employ multi-column to display pages */

In my tests, practically all epub3 ereaders display pages in multi-column mode; for that reason the property "break-after: avoid;" doesn't work there (you need "break-after: avoid-column;" or the webkit's alternative).
<snip>

Could you have BOTH instructions, or would that cause issues? Like so:

   
   break-after: avoid;
   break-after: avoid-column; /* This is for ereaders that employ multi-column to display pages */
   -webkit-column-break-after: avoid; /* This is for ereaders that employ multicolumn to display pages */

I'm just wondering if there are apps that might prefer one instruction over the other, and therefore, both might be needed?

[JSWolf]

Originally Posted by graycyn

Could you have BOTH instructions, or would that cause issues? Like so:

   
   break-after: avoid;
   break-after: avoid-column; /* This is for ereaders that employ multi-column to display pages */
   -webkit-column-break-after: avoid; /* This is for ereaders that employ multicolumn to display pages */

I'm just wondering if there are apps that might prefer one instruction over the other, and therefore, both might be needed?

webkit code is not valid ePub code so don't use it.

[RbnJrg]

Originally Posted by graycyn

Could you have BOTH instructions, or would that cause issues? Like so:

   
   break-after: avoid;
   break-after: avoid-column; /* This is for ereaders that employ multi-column to display pages */
   -webkit-column-break-after: avoid; /* This is for ereaders that employ multicolumn to display pages */

I'm just wondering if there are apps that might prefer one instruction over the other, and therefore, both might be needed?

No issue at all; you can employ those properties because if an ereader doesn't support one of them, it will ignore it. But in my tests, I discovered that those ereaders that support -webkit-column-break-after|before|inside", they also support "break-after|before|inside".

Today, virtually all epub3 readers mimic pagination using multi-columns, making the use of the "break-after|before: avoid-column" or "break-after|before: column" property (to force a break) almost indispensable. Of course, you also have the Webbit alternative.

[Karellen]

Originally Posted by RbnJrg

Today, virtually all epub3 readers mimic pagination using multi-columns

Do you have more info on that statement? I'd like to read up a bit more about it.

[graycyn]

Originally Posted by RbnJrg

No issue at all; you can employ those properties because if an ereader doesn't support one of them, it will ignore it. But in my tests, I discovered that those ereaders that support -webkit-column-break-after|before|inside", they also support "break-after|before|inside".

Today, virtually all epub3 readers mimic pagination using multi-columns, making the use of the "break-after|before: avoid-column" or "break-after|before: column" property (to force a break) almost indispensable. Of course, you also have the Webbit alternative.

Thanks, good to know! I'll probably just use the non-webkit one then.

I get paranoid, I've seen too many weird things happen, where all is fine, and then an ebook hits ONE app, where suddenly, things are not as I expect.

Just this morning, I popped a book into the Google Books app ... only to find that some headings weren't centered. Yet, the heading tags all had:

text-align: center;
text-indent: 0;

but did contain spans. Which, every place else I'd tested, were inheriting the text-align and text-indent properties as per normal. But not for Google Books. Adding the code to the span classes as well fixed it, though shouldn't have been necessary?

I don't recall having had that problem in the past in that app, actually, so maybe something changed there since I last made a book. It all makes my brain hurt!

But I suppose it also all keeps my brain from rotting with disuse, LOL!

[JSWolf]

Originally Posted by graycyn

Thanks, good to know! I'll probably just use the non-webkit one then.

I get paranoid, I've seen too many weird things happen, where all is fine, and then an ebook hits ONE app, where suddenly, things are not as I expect.

Just this morning, I popped a book into the Google Books app ... only to find that some headings weren't centered. Yet, the heading tags all had:

text-align: center;
text-indent: 0;

but did contain spans. Which, every place else I'd tested, were inheriting the text-align and text-indent properties as per normal. But not for Google Books. Adding the code to the span classes as well fixed it, though shouldn't have been necessary?

I don't recall having had that problem in the past in that app, actually, so maybe something changed there since I last made a book. It all makes my brain hurt!

But I suppose it also all keeps my brain from rotting with disuse, LOL!

It doesn't matter if the program is webkit based or not. The thing that matters is never use webkit code as it's not valid ePub code.

[DNSB]

Originally Posted by JSWolf

It doesn't matter if the program is webkit based or not. The thing that matters is never use webkit code as it's not valid ePub code.

But what if I want to be able to support people using renderers that require the webkit codes? They seem to be treated as a null operation by other renderers and allows books to be read on more systems with formatting more or less as intended.

[JSWolf]

Originally Posted by DNSB

But what if I want to be able to support people using renderers that require the webkit codes? They seem to be treated as a null operation by other renderers and allows books to be read on more systems with formatting more or less as intended.

Why would the renderer require webkit code if it's written properly to support ePub3? It should not need to. And besides, it's not valid code. It's not part of any ePub spec.

[RbnJrg]

Originally Posted by Karellen

Do you have more info on that statement? I'd like to read up a bit more about it.

Most modern e-readers (like those based on WebKit used by Apple Books or Google Play Books) render an epub3 file not as a continuous scroll, but as a series of horizontal columns that simulate pages; technically, it creates a multi-column css layout.

In that context:

break-after: avoid: This is a generic property. Many e-readers ignore it because they don't know if you mean to avoid a physical page break, a region break, or a column break.

break-after: avoid-column: This is much more specific. It explicitly tells the e-reader: "Don't break the column immediately after this element." Because it's a direct instruction to the box model the e-reader is using (columns), it's usually the only one they actually respect.

Virtually any e-reader based on a web rendering engine (WebKit, Blink) uses this technique to simulate pages. The software tells the engine: "I have a container of infinite width and fixed height (the screen's width); divide it into columns the width of the screen."

If you want to explore that model of pagination, you could read:

https://deepwiki.com/readium/readium-css/3.1-pagination

https://github.com/readium/css/blob/..._pagination.md

but if you do a google search with "readium pagination and spreading" you'll have a lot of info about the subject.