ePub vs. kePub

[JSWolf]

Originally Posted by Rockin

I believe you really want {orphans: 1; widows: 1} as the zero would be undefined behavior. Zeros don't make sense if you read the definition of orphans and widows.

In a binary world, 0 means off. So 1 means one line and 0 means off which means the same thing in this case.

[IanD]

I'm interested to see how this is going to turn out. As it stands (with no CSS modifications), it's as if the default is way larger than 2. I get very large gaps at the bottom of pages - much bigger than 2 lines.

UPDATE: Tried editing stylesheet directly and adding the CSS to the Calibre conversion tool. Both methods work just great. Thanks for that.

[DNSB]

Originally Posted by JSWolf

In a binary world, 0 means off. So 1 means one line and 0 means off which means the same thing in this case.

That depends on the way the software handles that setting. I've seen at least one case where setting widows and orphans to 0 reverted to the default 3.

[John F]

Originally Posted by JSWolf

In a binary world, 0 means off. So 1 means one line and 0 means off which means the same thing in this case.

Could you provide a link (for the definition of "binary world")? This description of binary sounds more famaliar (to me):

https://en.m.wikipedia.org/wiki/Binary_number

[Ripplinger]

I honestly do not add anything to my css sheets about orphans and widows, my experience in the screenshots posted above are just default conversion settings (where I have to convert) or just the epub as published. Which is why I think GeoffR's patch must be why I don't see the issue anymore and is the easiest fix to the problem.

[JSWolf]

Originally Posted by DNSB

That depends on the way the software handles that setting. I've seen at least one case where setting widows and orphans to 0 reverted to the default 3.

What program did that bit of stupidity?

[davidfor]

Originally Posted by JSWolf

In a binary world, 0 means off. So 1 means one line and 0 means off which means the same thing in this case.

Jon, we've been around this before. If you could actually tell me what "off" meant in terms of widows and orphans, then maybe I would agree. The specs I could find do not say what will happen when the setting is zero. And the only meaning I can think of is almost definitely not what you want.

[DNSB]

Originally Posted by JSWolf

In a binary world, 0 means off. So 1 means one line and 0 means off which means the same thing in this case.

Stepping onto soapbox....

How many times has it been pointed out that widows and orphans are NOT binary values and the epub 2 and 3 standards refers to the CSS specification which states:

13.3.2 Breaks inside elements: 'orphans', 'widows'

'orphans'
Value: <integer> | inherit
Initial: 2
Applies to: block container elements
Inherited: yes
Percentages: N/A
Media: visual, paged
Computed value: as specified

'widows'
Value: <integer> | inherit
Initial: 2
Applies to: block container elements
Inherited: yes
Percentages: N/A
Media: visual, paged
Computed value: as specified

The 'orphans' property specifies the minimum number of lines in a block container that must be left at the bottom of a page. The 'widows' property specifies the minimum number of lines in a block container that must be left at the top of a page. Examples of how they are used to control page breaks are given below.

Only positive values are allowed.

Also note the following from the CSS2/3 specification:

if any value is considered invalid (as unsupported values must be), CSS requires that the entire declaration be ignored.

As has been pointed out ad nausem, widows and orphans must be set to a positive integer which 0, by definition, is not. At least, the definitions I've seen of a positive integer states "Positive integers refers to all whole number greater than zero." or an equivalent. So setting widows or orphans to 0 should result in the entire declaration being ignored which means the code should fall back to the default 2 value.

Off the soapbox and back to our regular babbling....

Originally Posted by JSWolf

What program did that bit of stupidity?

One old reader for Mac (Mac OS 8 or 9 as far as I recall -- it's been a few years and I seem to recall it started as implementing the Open eBook standard and updated to epub1) and a couple of epub3 readers for Windows. I've also seen odd results with some epub2/3 readers for Windows but haven't played much with any other than ADE and Calibre lately. As I mentioned above, falling back to the default setting when an invalid value is specified is—probably—the correct behaviour—annoying but correct.

These experiences led to my preference for 1 where the end result is defined—avoid problems where you can instead of hoping that someone else has taken care of any potential issues.

Takes me back to the good(?) old days of arguing whether you should start numbering at 0 or 1.

[Jellby]

Originally Posted by JSWolf

In a binary world, 0 means off. So 1 means one line and 0 means off which means the same thing in this case.

But this is not a binary world, and these are not binary settings. According to the spec, they must be integers larger than 0, and once you understand what they mean, it makes no sense to use anything lower than 1 (what does "off" mean other than "one line"?). Using 0 might work in some readers, but again according to the spec, since it's an invalid value, it should be ignored and the default used, which is 2; so in complying systems it turns out 0 = 2.

[robko]

Can the widows and orphans people please take their never ending argument back to this thread: https://www.mobileread.com/forums/sho...+binary&page=6 where it was argued out over many pages and please not add 20 pages of argument over it to this page. Thank you.

[PeterT]

Originally Posted by robko

Can the widows and orphans people please take their never ending argument back to this thread: https://www.mobileread.com/forums/sho...+binary&page=6 where it was argued out over many pages and please not add 20 pages of argument over it to this page. Thank you.

What fun is that? It's the same as the neverending linux vs Windows threads.

[DNSB]

Originally Posted by robko

Can the widows and orphans people please take their never ending argument back to this thread: https://www.mobileread.com/forums/sho...+binary&page=6 where it was argued out over many pages and please not add 20 pages of argument over it to this page. Thank you.

Spoilsport! Taking all the fun out of my day.

[robko]

Originally Posted by DNSB

Spoilsport! Taking all the fun out of my day.

Yes I am on this one . I just don't want to have to wade through a rehash of what was thoroughly previously.

[jackie_w]

Originally Posted by Ripplinger

So it's down to something I forgot to mention in the above post. It's livable, just not preferable for me, where unless you have justification off, kepubs override all centered text and align everything left.

If you're using the Kobo Patcher one of the kepub patches can fix that for you.

Spoiler:

<Patch>
patch_name = `Un-Force user text-align in div,p tags in KePubs`
patch_enable = `yes`
# Multi-version patch: 3.3.0 - 3.16.0+
#
# This patch allows the text alignment set by the publisher in the kepub
# stylesheet to override the alignment selected by the reader from the device.
#
#     div, p { text-align: %1 !important; }
# --> body   { text-align: %1 !important; }
#
find_base_address = `d\0i\0v\0,\0 \0p\0 \0{\0 \0t\0e\0x\0t\0-\0a\0l\0i\0g\0n\0:\0 \0%\01\0 \0!\0i\0m\0p\0o\0r\0t\0a\0n\0t\0;\0 \0}`
replace_string = 0000, `d\0i\0v\0,\0 \0p`, `b\0o\0d\0y\0 \0 `
</Patch>

This should make text-alignment overriding for kepubs work the same as epubs.

[Ripplinger]

Originally Posted by jackie_w

If you're using the Kobo Patcher one of the kepub patches can fix that for you.
This should make text-alignment overriding for kepubs work the same as epubs.

I do use the Kobo Patcher, I'll have to enable this one and give it a try. Thanks for the info.

Edit: Works great, thanks again. While I really don't see the advantage of kepub over epub for myself, I don't mind kepubs anymore like before.