Clara HD Read converted kepub files *without* overriding orphans/widows?

[dw28]

I've converted some .epub files to .kepub using kepubify, and learned enough add a little .css to the command line argument to adjust the font size to match the usual size that my Clara HD displays regular .epub files.

I'm doing the conversion for the better footnote handling, for books that have a lot of them...
...but one aspect that's niggling me is that using .kepub appears to hard-wire an orphans/widows value of 1 now, so I end up with a bunch of disjointed first/last lines, where I'd much rather it retained the regular default setting (which I understand is 2).
All the info about it I've managed to find in searches is apparently celebrating the override - apparently most people prefer chopped up paragraphs to "wasted space". I'm definitely the opposite :-)

I've tried adding "body {orphans: 2; widows: 2;}" to the css additions, even tried "body {orphans: 2 !important; widows: 2 !important;}" to attempt to force the issue, but both seem to be ignored.

Is there any way to achieve this with .kepub files?

[jackie_w]

Originally Posted by dw28

Is there any way to achieve this with .kepub files?

I believe the widows/orphans CSS properties are ignored by kepub. Similarly the @page style rule. On the flip side there are CSS properties which work in kepubs but not epubs. You win some, you lose some.

[Quoth]

Must be a mistake in kepub renderer design, because most renderers use 2 if the value isn't specified.

Note 1, not 0 is the regular epub css to do no widow/orphan processing. Think about what it does to the paragraphs vs page breaks. A value of 0 is meaningless.

[JSWolf]

Originally Posted by Quoth

Must be a mistake in kepub renderer design, because most renderers use 2 if the value isn't specified.

Note 1, not 0 is the regular epub css to do no widow/orphan processing. Think about what it does to the paragraphs vs page breaks. A value of 0 is meaningless.

I do know that a value of 0 (while not technically correct), does work with RMSDK.

[theducks]

Originally Posted by JSWolf

I do know that a value of 0 (while not technically correct), does work with RMSDK.

Why would you allude to using 0 being acceptable AT ALL?
It is incorrect. Wrong. BAD JuJu PERIOD.
The correct answer is: 'Don't do that.'

1 says allow a single line. (I believe this is the default if not specified), so 0 may just being ignored, thus the default.

[JSWolf]

Originally Posted by theducks

Why would you allude to using 0 being acceptable AT ALL?
It is incorrect. Wrong. BAD JuJu PERIOD.
The correct answer is: 'Don't do that.'

1 says allow a single line. (I believe this is the default if not specified), so 0 may just being ignored, thus the default.

The default is 2 for both. So if 0 was being ignored, it would be at 2. That's how I know 0 does work. Maybe 0 means no widows and orphans.

[DNSB]

Originally Posted by JSWolf

The default is 2 for both. So if 0 was being ignored, it would be at 2. That's how I know 0 does work. Maybe 0 means no widows and orphans.

Jon, didn't we go through this a few years back? The definition for widows and orphans states the value must be an integer and must be positive which disqualifies zero as a value.

And yes, I have seen some renderers where setting widows and orphans to 0 resulted in using the default though treating it as being the same as setting widows and orphans to 1 is the most common.

Widows: The minimum number of lines that can stay by themselves at the top of a new fragment after a fragmentation break. The value must be positive.

Orphans: The minimum number of lines that can stay by themselves at the bottom of a fragment before a fragmentation break. The value must be positive.

[JSWolf]

Originally Posted by DNSB

Jon, didn't we go through this a few years back? The definition for widows and orphans states the value must be an integer and must be positive which disqualifies zero as a value.

And yes, I have seen some renderers where setting widows and orphans to 0 resulted in using the default though treating it as being the same as setting widows and orphans to 1 is the most common.

Yes we did. But I'm just saying that values of 0 do work with RMSDK. I don't know about any other ePub software as I've not tried it. But I do use values of 1 in the body style.

[DNSB]

Originally Posted by JSWolf

Yes we did. But I'm just saying that values of 0 do work with RMSDK. I don't know about any other ePub software as I've not tried it. But I do use values of 1 in the body style.

I test epubs using quite a few renderers and the problem is that while RMSDK is happy enough with treating 0 as 1, there are other renderers where 0 results in using the default of 2 or 3.

I, personally, find it best to avoid those issues by not using or suggesting the use of 0 as a value for widows and orphans since 1 works on all the renderers I've tested that support widows and orphans.

[dw28]

Heh, yep, what this thread needed was definitely to be turned into the same endless argument as every other orphans/widows thread :-P

Might as well pile on I guess :-)
Setting it to 0 is clearly unjustifiable in any context - all you're doing is setting an invalid number, and counting on each individual reader implementation to do its error-checking correctly. At best, you get an unpredictable result, at worst, you'd maybe cause a bad reader to crash.

On further exploration of my original question - it appears that the kepub reader doesn't so much "ignore" the setting, as it appears to simply not have any orphan/widow processing implemented in the first place, so implicitly, it works as if the value was always set to 1.