Random page breaks on PRS-600 and Irex DR1000S

[gaphic2]

I'm struggling with what seems to be random behavior in one of my epubs. On ADE there is no problem, but on the two readers I'm testing the file on the page cuts off in mid-sentence and continues on the next page. This only happens a couple of times - it's a 200+ page book.

The cut-off points are not the same on both readers and they are not consistent - if I change the font size, the cut-off disappears or moves.

I've checked the files but there is nothing in the paragraphs that could account for this.Any ideas as to what might be causing this? The epub is generated with Indesign CS4.

[charleski]

Do you see any cutoffs in Desktop ADE if you change the size of the window?
Is the space below the cutoff the same size each time or does it vary?
It might be an idea to post the css for the file

[gaphic2]

@ Charleski: No, no cutoffs at all in ADE. The space varies.
CSS is plain vanilla.

But I think I've cracked it. I's caused by long paragraphs! I've combined and split a few paragraphs and that has an immediate effect.

There has to be something in the rendering software that tells the reader to break the paragraph if it is longer than X (screens?). This would account for the different behavior between the two readers.

I'll do some more testing to find out if I can come up with a number of characters. I've attached a test epub with placeholder text, a couple of pages, all in one paragraph. On both my readers, page breaks seem random. Surely there must be some logic behind the breaks?

[charleski]

This is the widow and orphan mechanism. The default is to have both at 2, meaning that the renderer will adjust text on the page so that at least 2 lines of a paragraph are present at the top (widows) or bottom (orphans). If your paragraphs are appreciably longer than the amount of text that can fit on a page then it will cause exactly this problem. Since this is very rare in current fiction it's uncommon to see it.

To fix it, add
widows: 1;
orphans: 1;
to the body section of your css.

[gaphic2]

Thanks Charleski! Changing the value for widows and orphans to 1 (I think if you don't specify it is 2?) certainly gets rid of the cutoffs.

However, now I've got widows & orphans in the text! Not in the sample epub I posted, obviously, as this is only one paragraph, but in the main book.

So are you saying the choice is between a rock and a hard place?

Why does the reader cut off the text in the sample epub if the standard value for w/o is 2? As it is only 1 paragraph, the only cutoff possible should be on the last but one page/screen.

Sorry if I seem dim, I can't get my head around it.

[Jellby]

Originally Posted by gaphic2

On ADE there is no problem, but on the two readers I'm testing the file on the page cuts off in mid-sentence and continues on the next page.

Does it maybe occur in the middle of a very long paragraph? I have observed the same thing (page broken mid-sentence, with no particular markup there), and it was always in very long (multi-page) paragraphs. I guess the device avoids overloading its processor and memory by adding pagebreaks.

[gaphic2]

Yes, it has to with long paragraphs, and as Charleski pointed out the widow and orphan control in the page rendering.

But why would the device need to add a page break halfway through a page when there is no issue with orphans/widows, as in the sample epub posted earlier?

[charleski]

Originally Posted by gaphic2

Yes, it has to with long paragraphs, and as Charleski pointed out the widow and orphan control in the page rendering.

But why would the device need to add a page break halfway through a page when there is no issue with orphans/widows, as in the sample epub posted earlier?

My best guess is that there's some sort of obscure overflow error which is causing the layout algorithm to give up and just chop the paragraph. In some cases with multiple long paragraphs there can be problems with cascade effects, but this clearly isn't the case here.

Personally, I don't mind widows and orphans nearly as much as seeing the last line of text jump around. It's really a matter of style in the majority of cases. A stylistic source like Bringhurst is of the opinion that while widows (a single line at the top of a page) should be avoided, orphans are acceptable (Bringhurst explains this using some typically flowery reasoning ). So you could try widows: 2; orphans: 1;.

[JSWolf]

Originally Posted by charleski

This is the widow and orphan mechanism. The default is to have both at 2, meaning that the renderer will adjust text on the page so that at least 2 lines of a paragraph are present at the top (widows) or bottom (orphans). If your paragraphs are appreciably longer than the amount of text that can fit on a page then it will cause exactly this problem. Since this is very rare in current fiction it's uncommon to see it.

To fix it, add
widows: 1;
orphans: 1;
to the body section of your css.

I prefer widows and orphans of 0. That way each full page of text can end on the same line.

[Jellby]

Originally Posted by JSWolf

I prefer widows and orphans of 0. That way each full page of text can end on the same line.

I don't think there's a difference between 1 and 0. The "widows" and "orphans" properties are the minimum number of lines of a partial paragraph at the top or bottom of a page. A value of 1 already means that just a single line is allowed, a value of 0 makes no sense, and actually, the specification says "only positive values are allowed".

[gaphic2]

Thanks for all your help guys. I've submitted 2 epubs, one with the standard values for w/o and one with w=1. My client can decide which one to use. I've thrown Bringhurst in their face as well, for backup.

I'm still interested in the mechanics of how the Adobe Reader Mobile implementation on these readers gets it wrong. Adobe puts content creators in the same bag as end users however, so I don't think I'll get any answers from them.