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).

[icearch]

Originally Posted by Turtle91

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.


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

Absolutely good practice, but it really doesn't take that much space in ratio to long text per paragraph.

I should consider using different css for title page and actual article page. So both can have cleaner tags.

Or should I use div instead of p to hold title text? Do plain text behave the same in div and p?

[JSWolf]

Originally Posted by DNSB

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.

And one other thing I forgot to post is I use the patch that turns on hyphenation in KePub.

[JSWolf]

Originally Posted by icearch

Absolutely good practice, but it really doesn't take that much space in ratio to long text per paragraph.

I should consider using different css for title page and actual article page. So both can have cleaner tags.

Or should I use div instead of p to hold title text? Do plain text behave the same in div and p?

Don't use div where you should be using p.

[icearch]

Originally Posted by JSWolf

Don't use div where you should be using p.

The thing is I don't think it should be using p either. It's a couple of short words in title page.

See the top three line in attached pic.

[Turtle91]

You are correct that it’s not technically a <p>. Same as with things like poetry where each line is also not a paragraph. There is definitely an argument that <div> is the more correct to use for semantic reasons. I personally use a <p> but that is only because I created a template long ago that I haven’t gotten around to changing…

What does matter, imo, is to use the proper <h> tag for any titles (book/chapter) because titles are usually defining a new section.

[icearch]

Originally Posted by Turtle91

You are correct that it’s not technically a <p>. Same as with things like poetry where each line is also not a paragraph. There is definitely an argument that <div> is the more correct to use for semantic reasons. I personally use a <p> but that is only because I created a template long ago that I haven’t gotten around to changing…

What does matter, imo, is to use the proper <h> tag for any titles (book/chapter) because titles are usually defining a new section.

See, we all have old tech that runs.

Having correct h is absolutely important, I'm not going to mess with that.

[RbnJrg]

Originally Posted by icearch

The thing is I don't think it should be using p either. It's a couple of short words in title page.

See the top three line in attached pic.

And in that title page, where would the properties supposedly come into play to control fragmentation? What do you want to do there? Keep the entire block together? Force (or prevent) a break before or after it? On a title page, you shouldn't need to control fragmentation (at least not with the properties that were discussed).

[icearch]

Originally Posted by RbnJrg

And in that title page, where would the properties supposedly come into play to control fragmentation? What do you want to do there? Keep the entire block together? Force (or prevent) a break before or after it? On a title page, you shouldn't need to control fragmentation (at least not with the properties that were discussed).

Ah, yes. This title page have nothing to do with page break. Just other random thought.

[icearch]

And with some testing, div and p do have different attributes, that is p have margin-block-start and margin-block-end with both 1em, which div does not have.