Is there an option for Paragraph breaking between pages (might be wrong term for it)

[Veelk]

Originally Posted by HarryT

You want something like this in the paragraph style in your CSS:

p {
   widows: 2;
   orphans: 2;
}

That tells it to move the entire paragraph to the next page if there would two (or fewer) lines left either at the bottom of one page, or the top of another.

Thanks for the help. However, I've tried this with various of my ebooks and it doesn't work with any of them. Am I doing something wrong? I put it into the CSS of the user stylesheet section of preferences.

Originally Posted by Notjohn

As a reader, I have no problem with widows & ophans. I would much rather continue reading from one page to the next, as I do in a print edition, without encountering a short page. If I am reading a print edition from a reputable publisher, the book designer is going to tweak the line spacing, or perhaps ask the author to rephrase, rather than have pages of unequal length. I appreciate that the OP in a sense is trying to accomplish what book designers accomplish, but Kindle at least is going to make a hash of it. (And ending a paragraph with the last complete sentence is going to make a new paragraph, isn't it? Does the carry-over get an indent, and how is that accomplished? And what if we're talking about a paragraph that is quoted speech -- who adds the beginning quotation mark?)

Originally Posted by JSWolf

The problem is that the OP wants to end on a complete sentence. That's not possible to do without maybe dropping the last paragraph to the next page and that could leave a rather large gap. And depending on the size of the screen, I've seen a paragraph take up the entire screen.

In my mind, if the paragraph takes up half the screen before continuing onto the next sentence, I would have the program just move the entire paragraph over to the next page. So basically, fit as many complete paragraphs onto the screen as possible. The only exception is when the paragraph is larger than the screen size itself, then it has to just break. And I would agree that would mean large paragraphs could potentially leave half the screen blank, but I have a fairly large screen with normal size text, so very few books actually do this for me. And in books that have mostly short paragraphs though, it would be a godsend.

[Turtle91]

Originally Posted by Veelk

Thanks for the help. However, I've tried this with various of my ebooks and it doesn't work with any of them. Am I doing something wrong? I put it into the CSS of the user stylesheet section of preferences.

Did you properly LINK the stylesheet to your html pages?

Originally Posted by Veelk

In my mind, if the paragraph takes up half the screen before continuing onto the next sentence, I would have the program just move the entire paragraph over to the next page. So basically, fit as many complete paragraphs onto the screen as possible. The only exception is when the paragraph is larger than the screen size itself, then it has to just break. And I would agree that would mean large paragraphs could potentially leave half the screen blank, but I have a fairly large screen with normal size text, so very few books actually do this for me. And in books that have mostly short paragraphs though, it would be a godsend.

This is exactly what "p {page-break-inside:avoid}" is supposed to do, as BR posted. Unfortunately not all devices or reading apps do what they are supposed to do...either the app/device sucks, or the IDPF standard is not written clearly enough.

[Veelk]

Okay, I managed to get it to work on seemingly most of my ebooks...except the one I am currently reading. So, if I have confirmation that it does indeed work on some, how do I get it to work on others?

Edit: okay, testing it out some more, some books adhere to it and I can see clear gaps at the bottom that indicate that the program pushes the paragraphs to the next page. Other books don't care and just do nothing. It feels like older books are more prone to this than newer.

[Hitch]

Originally Posted by Notjohn

As a reader, I have no problem with widows & ophans. I would much rather continue reading from one page to the next, as I do in a print edition, without encountering a short page. If I am reading a print edition from a reputable publisher, the book designer is going to tweak the line spacing, or perhaps ask the author to rephrase, rather than have pages of unequal length. I appreciate that the OP in a sense is trying to accomplish what book designers accomplish, but Kindle at least is going to make a hash of it. (And ending a paragraph with the last complete sentence is going to make a new paragraph, isn't it? Does the carry-over get an indent, and how is that accomplished? And what if we're talking about a paragraph that is quoted speech -- who adds the beginning quotation mark?)

FWIW:

And I'm not saying that this is good or bad, BUT, we are finding a massive shift in print from perfectly aligned pages without any widows and orphans to a mindset that doesn't seem to care about w/o, telling us to ignore the w/o issue in order to square the page. {shrug}

I guess that those of us who still find it vexing, to see w/o and unsquared pages are just old fogies. :-)

Oh, and the widows/orphans thing, in eBooks--in about 50-70% of them, it doesn't work. If you're on iOS, fine (or Kobo, b/c they've mooched a lot of the iOS rendering engine, which in turn had originally moooched ADE...), or Readium or Azardi, but after that, rotsa ruck.

Hitch

[JSWolf]

I prefer windows and orphans set to 1 so we do get pages ending at the same place in most pages.

[fbrzvnrnd]

As Betterred said you can "ask" to do not break paragraph using the page-break-inside CSS rule. But every ebook reader application could or not use it.

[DNSB]

Originally Posted by HarryT

There is no way of moving "sentences" from one page to another. Widow and orphan control is for moving entire paragraphs between pages.

Minor nit in that widows and orphans are for controlling how many lines of a paragraph can be left at the bottom of a page or at the top of a page and have little to do with moving entire paragraphs between pages. With widows and orphans set to 2, a minimum of two lines would be required at the end of a page (orphans) or at the start of the next page (widows).

In one example, you have a paragraph which takes 8 lines with 7 at the bottom of the display and 1 carried over to the next page. A setting of widows=2 would force another line to the next page splitting the paragraph 6 lines/2 lines.

I've seen some references that reverse widows and orphans from the definitions I've used but à chacun son goût.

[DNSB]

Originally Posted by Hitch

Oh, and the widows/orphans thing, in eBooks--in about 50-70% of them, it doesn't work. If you're on iOS, fine (or Kobo, b/c they've mooched a lot of the iOS rendering engine, which in turn had originally moooched ADE...), or Readium or Azardi, but after that, rotsa ruck.

Kobo uses Adobe's RMSDK for rendering epub2 ebooks so hard to say they've mooched the iOS rendering engine. For epub3 (.kepub.epub or .fxl.kepub.epub), they use the ACCESS NetFront™ BookReader EPUB Edition which is based on WebKit though some claims are that it was originally developed using the KHTML/KJS libraries from KDE which are ancestral to WebKit.

For what it's worth, the RMSDK renderer respects widows/orphans with a default of 2/2 if not overwritten in the CSS while the ACCESS renderer disregards them (equivalent to setting both to 1) so if you are seeing widows/orphans affecting the display on a Kobo ereader, you're using RMSDK.

[Hitch]

Originally Posted by DNSB

Kobo uses Adobe's RMSDK for rendering epub2 ebooks so hard to say they've mooched the iOS rendering engine. For epub3 (.kepub.epub or .fxl.kepub.epub), they use the ACCESS NetFront™ BookReader EPUB Edition which is based on WebKit though some claims are that it was originally developed using the KHTML/KJS libraries from KDE which are ancestral to WebKit.

For what it's worth, the RMSDK renderer respects widows/orphans with a default of 2/2 if not overwritten in the CSS while the ACCESS renderer disregards them (equivalent to setting both to 1) so if you are seeing widows/orphans affecting the display on a Kobo ereader, you're using RMSDK.

No, actually, I was talking about the fact that the same FXL coding that works on iBooks will function pretty much perfectly on KOBO. With regard to their internal rendering, trying to get kepub to behave is a whole other story. :-)

If they haven't mooched some of the rendering settings, etc., from iBooks, the whole FXL thing is fairly remarkable. And truly--didn't mean to discuss iBooks; I was talking about the relative uselessness of the w/o settings.

Hitch

[JSWolf]

having widows & orphans other than a value of 1 is just silly on a screen. It's not the same as print and it just doesn't work. Many people don't care about how the paragraph splits. They care about how the page looks and to me, it looks silly when there is a varying amount of wasted space at the bottom of the screen because of widows & orphans.

[Turtle91]

Personally I could care less about widows and orphans as I use the scroll mode instead of "pages"!

[Hitch]

Originally Posted by Turtle91

Personally I could care less about widows and orphans as I use the scroll mode instead of "pages"!

First World Problems, eh?

Hitch

[Notjohn]

Originally Posted by JSWolf

The carry-over does not get an indent if it's part of the paragraph that starts on the previous page. If it's a quoted paragraph, then the quotes are where they belong.

You ignore the first sentence in that parenthesis: "And ending a paragraph with the last complete sentence is going to make a new paragraph, isn't it?"

So you have a paragraph beginning with a quote. The third sentence carries over to the next "page." So the second sentence almost certainly ends with a short line, which telegraphs to the reader that the paragraph has ended. Now we turn the "page" and find that the apparent next paragraph not only isn't indented (as you predict will happen) but doesn't begin with the quotation mark -- but ends with one!

I see a very confused reader. It would be rather like reading a Bernie Gunther novel, which is forever changing speakers within the same paragraph, requiring me to go back and do a mental he said / she said to figure out who's talking.

The whole thing is idiotic. What's wrong with a carry-over line of four words or even one?