Kobo Firmware 3.5.0

[the.Mtn.Man]

I've seen the long-paragraph bug (which has apparently been fixed), but I've never encountered an instance where only a single line is moved to the next page like in your example. Hard to say what's going on. I get the majority of my epubs from Feedbooks.com. I don't know if that makes a difference.

[DNSB]

Originally Posted by JSWolf

Thanks.

0 is a valid value. 0 means off.

Not quite right. 0 is not a positive integer.

If you want to turn widows and orphans off, set them to 1 -- it's a bit hard to leave less than 1 line at the top/bottom of a page.

CSS Level 3 makes this clear -- "Only positive integers are allowed as values of ‘orphans’ and ‘widows’. Negative values and zero are invalid and must cause the declaration to be ignored." From a discussion in another forum, it appears that for one ereader if the declaration is ignored, the default value (2) will be used.

Regards,
David

[violent23]

I see that this update did not fix the kepub cut off F's and italics on the lowest margin settings.

[Jellby]

I did some tests with epub in 3.3.0 and 3.5.0 (https://wiki.mobileread.com/wiki/EPub_Reader_Test), I noticed:

- Even with 3.3.0, I didn't see the long paragraph bug in the sample text. Maybe I'd need longer paragraphs, but as noted that was enough to trigger the bug in the Orizon.

- Auto margins work! It should now be possible to center blocks of text or tables.

- The bug with low-bitdepth PNGs seems fixed!

- Missing characters do not show as a question mark or rectangle, instead they show blank or as some other character, which may be more confusing.

- Left-to-right text works! At least in Hebrew, Arabic ligatures are probably more demanding.

[PeterT]

Originally Posted by violent23

I see that this update did not fix the kepub cut off F's and italics on the lowest margin settings.

what font?

[arspr]

Originally Posted by Anak

This widows/orphans issue doesn't bother me that much. Personally i think that the default value of 2 is a bit overkill for ereaders as it breaks/moves (imho too frequently/unnecessary) sentences to the next screen while there is still enough space to display them.

No!!! If there's still enough space while respecting the widows and orphan settings, it's broken!!!

The worst case is when your paragraph has n (let's say 3 as the commonest example) lines and widows (2) + orphans (2) = n+1 (4). Then, of course, there's no way that paragraph can be split at the end of a page. And you can get n-1 (2) blank lines at the bottom in the worst scenario. Or, as you can have more available space it could nearly look like having n (3) blank lines. I mean imagine that the available space you have at the bottom is enough for 2.9 lines...

But, if the space looks like n+1 lines (4), then it's BUGGY.

(Or as I posted if in a 5 line paragraph, there's a blank space of more than 1 line and 3 lines in the second page).

Originally Posted by Anak

It is nice to read that I'm not the only one who edit the widows and orphan properties to it minimum value of 1.

Of course, as I previously posted, widows and orphans cause more blank spaces at the bottom of the pages which are ugly. But widows and orphans are also ugly themselves. It's a trade-off between two different kind of ugliness..,

It's a matter of personal preferences.

But the discussion here is that RMSDK is BUGGY when applying widows and orphans despite if you like/use/avoid/despise or not that property/feature. And it shouldn't...

(Exactly as, IMO, ACCESS shouldn't have directly killed it. Kobo could have set it to 1 as default, if they thought it was the prettiest setting, but they should have left the final decision to the ebook publishers or users).

Originally Posted by Anak

The end of chapter bug bothers me much more and is still present in fw 3.5.0.

Originally Posted by treadlightly

I posted an example here.

Wow! I've never seen it myself in my old Sony PRS-650. But nevertheless I'm ALWAYS on sideloaded kepubs since I bought my AuraHD...

[AnemicOak]

Originally Posted by PeterT

what font?

Don't know what font violent23 is using, but I've run into cut off letters when using Georgia with 3.5.0 in kePub's (haven't tried other fonts).

[arspr]

Originally Posted by PeterT

what font?

It happens with at least the Default Font (whichever it is) but I think (IIRC) it always happens in kepubs, even when they have embedded fonts. The used font type just makes the problem more evident or less.

I've just got used to it and ignore it, but it is a bug nevertheless...

[Anak]

Yep, i also don't like those cut off characters: all fonts with a negative right side baring (rsb), of which the "f" is probably the most common.

I don't know if this works for kepubs but it works for regular epubs. Do not use the margin property to set page margins, use the padding property instead. This won't cut off characters with negative side barings.

CSS

Do not use:
@page {margin:0;}
p,div {margin:0;padding:0;} /* optional / necessery if all default values are set in the body tag */
div.page-margins {
margin-left:2%;
margin-right:2%;
}

Use this
@page {margin:0;}
p,div {margin:0;padding:0;} /* optional / necessery if all default values are set in the body tag */
div.page-margins {
padding-left:2%;
padding-right:2%;
}

HTML, add/wrap this code around, something like:

<body>
<div class="page-margins">
…  
</div>
</body>

[arspr]

That's what I call a hack...

Pretty similar to the 99% one I use for covers... (Thread and post here)

Nevertheless I'll probably test it for my kepubs. Thanks.

OTOH, have you tried using 1%? Why do you insert a div tag? Why don't you set it directly in body?

[JSWolf]

Originally Posted by davidfor

And what exactly does "off" mean? The only thing it can mean is the same as using 1. i.e. Allow one line from the a paragraph to appear at the end or beginning of the page/screen. The specs I can find say only "positive numbers are allowed". "0" is not a positive number.

Or do you think that "off" means don't leave any widows or orphans. i.e. Always start a paragraph on a new page/screen.

Off means do not fix widows and orphans so they are not widows and orphans. Turn the feature off. 2 is on, 0 is off.

[JSWolf]

Originally Posted by Anak

No, it is not. The properties widows and orphans are (now) strictly-positive (CSS3). The minimum value is 1. The default is (and should be) 2.
The old CCS2.x accepted 0 as a valid value, but 'since the draft/introduction' of CCS3 it doesn't anymore. Try the W3C CSS Validation Service on both properties.

This widows/orphans issue doesn't bother me that much. Personally i think that the default value of 2 is a bit overkill for ereaders as it breaks/moves (imho too frequently/unnecessary) sentences to the next screen while there is still enough space to display them. It is nice to read that I'm not the only one who edit the widows and orphan properties to it minimum value of 1.

The end of chapter bug bothers me much more and is still present in fw 3.5.0.

This is ADE we are talking about ADE allows 0. Kobo uses ADE thus 0 is valid.

[PeterT]

Unfortunately, no mention of Widows / Orphans @ https://github.com/kobolabs/epub-spec

[Rev. Bob]

Originally Posted by JSWolf

Off means do not fix widows and orphans so they are not widows and orphans. Turn the feature off. 2 is on, 0 is off.

To quote a TV commercial, "That's not how this works! That's not how any of this works!"

We're not talking about a binary on/off setting; W&O isn't something that can somehow not exist. The default value is 2: "Allow two lines, but no fewer, to exist on a page by themselves. If the affected paragraph contains fewer than two lines, put them at the bottom of the first page." The lowest value that makes any sense is 1: "Allow one line, but no fewer, to exist on a page by itself. If the affected paragraph contains fewer than one line, put it at the bottom of the first page." Since the paragraph cannot contain less than one line, the second sentence (which administers the W&O setting) is effectively ignored; the paragraph falls wherever there's room for it.

How would zero work; what would it do? How would you write that instruction, as I did with 1 and 2 above? Explain this to me, please.

Originally Posted by JSWolf

This is ADE we are talking about ADE allows 0. Kobo uses ADE thus 0 is valid.

"Works" and "is valid" are two different concepts. Ideally, yes, they should overlap completely...but they don't. "Valid" applies to code, and is very easy to check. Here are the specs, here's the code, see if the code adheres to the specs. If so, it's valid. Nice and simple.

"Works" applies to a specific combination of code, rendering engine, device, and (in some cases) subjective opinion. ADE, as a renderer, is expected to handle all valid code - but it's also expected to tolerate some flawed code, because many ebooks fall short of the "valid" bar...such as, say, by setting W&O to zero. In that case, the proper thing for ADE to do is ignore the invalid value, but it can do that in many ways. One of them, which is what it sounds like is happening, is to treat it as 1 instead. Another equally "correct" way of handling that error would be to completely ignore the bad line, thus leaving the default value of 2 in place.

In a particularly drastic case, equally "correct" and defensible, but which most people would regard as a bad solution, it could treat 0 as "maximum" in the same way that some 8-bit software treats 0 as 256; since 0 is not allowed, the coder "obviously" intended to indicate the maximum, which there's no other way to do. (In the 8-bit example, this changes the value's range from 0-255 to 1-256.) Of course, that opens the question of what "maximum" means - maximum number of lines that can be shown on one page in the current configuration, highest value the rendering engine can handle, or what?

[Rev. Bob]

Originally Posted by PeterT

Unfortunately, no mention of Widows / Orphans @ https://github.com/kobolabs/epub-spec

Sure there is:

Originally Posted by The cited page

The ePub 3.0 spec is based on HTML5 and CSS3, adhering to the most recent versions. Content creators are advised to review the HTML5 and CSS3 reference profiles because changes to them could impact file production.

Widows and orphans are defined in CSS, and in this case, the CSS3 specification applies:

Originally Posted by The linked document

Normative References

[AltStyleTags] Alternate Style Tags . Elika J. Etemad.

[CSS Namespaces] CSS Namespaces Module . Elika J. Etemad, et al.

[CSS2.0] Cascading Style Sheets, level 2 - CSS2 Specification . Bert Bos, et al. 12 May 1998 (revised 11 April 2008).

[CSS2.1] Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification . Bert Bos, et al. 7 June 2011.

Ah, that's what we want. Since none of the CSS3 modules further down the page address widows/orphans, the CSS2.1 spec applies:

Originally Posted by The CSS2.1 spec, section 13.3.2: Breaks inside elements: 'orphans', 'widows'

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.

For information about paragraph formatting, please consult the section on line boxes.

(Boldface mine.) Thus, according to the kobolabs page, the minimum correct value for the widows and orphans properties is one. Not zero, not two (although two is the default value), not -37, but one. Period, full stop, end of debate.

Now, with respect to display bugs, line boxes are also relevant. In its simplest form (but this is VERY simplified; see section 10.8 for the nitty-gritty), the height of a line box is the same as the absolute line-height for the tallest text within that line. Technically speaking, W&O calculations apply to line boxes, so anything that affects those affects W&O display.

Thus, if your font is 20px tall and your line-height is 1.2, the line box is (at least, assuming no weirdness) 24px tall. If the space at the bottom of a page is only 47px, then regardless of how loudly someone argues that there's plenty of room for two lines there, it's just not true. Sure, it's picky - but picky is what computers do. It's their job. When we tell them to be picky about displaying text...well, you know. They'll be ruthlessly picky, in ways that a person applying judgment might not be.