About page-break

[JSWolf]

Originally Posted by RbnJrg

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.

This is why it's best to break the HTML into another HTML file at the break point. You then don't have to worry about webkit or Books aor any other software not respecting a page break in CSS.

[jackie_w]

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.

How do you plan to get hyphenation in a Kobo kepub without using -webkit-hyphenate-limit-before and -webkit-hyphenate-limit-after?

[JSWolf]

Originally Posted by jackie_w

How do you plan to get hyphenation in a Kobo kepub without using -webkit-hyphenate-limit-before and -webkit-hyphenate-limit-after?

That's easy. And it requires no webkit code in any KePub.

[Reading]
webkitTextRendering=geometricPrecision

Plus, the English hyphenation dictionary has before and after values. I use the one I made because the values Kobo use are too big.

[DNSB]

Originally Posted by JSWolf

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.

There are quite a few ePub renderers out there. Some of them still use the -webkit extensions. It's simply easier for me to allow for their existence than to threaten to hold my breath until I turn purple if the renderer is not upgraded to a version that does not need the -webkit extensions.

As for not being part of any ePub spec? Not that big a concern to me since I've found virtually all renderers treat a properly structured but unknown entry in a CSS stylesheet as a null operation.

[DNSB]

Originally Posted by JSWolf

That's easy. And it requires no webkit code in any KePub.

[Reading]
webkitTextRendering=geometricPrecision

While geometricPrecision allows scaling to use fractional font sizes, I don't seem to recall have noticed any effects on hyphenation.

I will admit to preferring to use:

  hyphens: auto;
  hyphenate-limit-chars: 8 3 3;

instead of mucking with hyphenation or the -webkit-hyphenate-limit options.

[RbnJrg]

Originally Posted by JSWolf

This is why it's best to break the HTML into another HTML file at the break point. You then don't have to worry about webkit or Books aor any other software not respecting a page break in CSS.

Here the main issue is to AVOID a break after some elements. Or to have all elements joined (break-inside: avoid|avoid-column). The problem is how to avoid fragmentation, not how to generate it (that is easy).