[Hitch]

Originally Posted by tomsem

I’m curious about this ‘widows and orphans’ issue. About 99% of my ebook reading is on Kindle platform. Even with so-called Enhanced Typography, I still see this happening with some frequency. I don’t like it, especially when sub-titles show up at the bottom of a page, or captions that wind up on a different page than the image or figure they describe. Continuous Scrolling is a sort of workaround to this, but it does not work on Kindles, and Amazon has not really finished implementation of it (no Immersion Reading, no Speak Screen, no equivalent of Page View or even a scroller to help with navigation).

Okay, so, let's start with the fundies (fundamentals). How does the eReader KNOW where the text begins and ends, on the screen? Quick answer--it actually doesn't. The software, behind the scenes, renders a big old roll of toilet paper. It's effectively a 1990's website. No pages, no nothing. Just software that tells the device "at font size X, you can display Y lines of content, assuming the device is a Zed device." In the Kindleverse, that would translate to something like, "if you're at font size 3, you can display 25 lines of content on a Fire classic IN PORTRAIT orientation." It's probably not even that sophisticated; it's probably done in pixels versus some obscure calculation in font size = X in pixel size, but.,..that's how it works.

It bookmarks, internally, where the reader last stopped reading, so that it knows where to pick it up. But all it does is scroll X amount of space, behind the screen, each time the reader clicks. It doesn't KNOW that it's displaying 10 lines or 20 lines of content and that that content "could be" another 5 lines if there wasn't space between the paragraphs. Every time you change the font size, the ENTIRE book re-renders, and is re-scrolled to where you currently are in the TP. That's pretty much IT.

Am I to blame Amazon, lazy publishers who don’t care what their product looks like, or myself for being too sensitive?

That assumes that any "blame" is due at all. As I said, you have this big long roll of toilet paper, designed to try to please EVERY possible reader--Jane who reads at font size 8, in landscape, on her smartphone; Fred who reads at font size 3 on his Fire 10", in portrait. Two wildly different views of the same content. What you're asking for would, I tend to think, not only require significant recoding of the Kindle OS, but it would probably take a lot more processing power.

BTW: for the sake of accuracy in discussing typography, "widows and orphans" have nothing to do with stranded headings, image captions, etc. Those aren't widows or orphans. Widows and orphans are, in short:

When a paragraph BEGINS as the last line of a page, that's an orphan. (Bringhurst's method to remember it--someone that has no past, but does have a future). When a paragraph stub ends on the first line of a new page, that's a widow. FYI, orphans, in typography, are not actually considered "bad" as they are in secretarial services and the like. Widows should be dealt with, yes--but orphans? No. Despite popular belief.

The old word-processing "widows and orphans" rule is unrelated to the topics of headings and body text. The idea that body text shouldn't pull away from its related heading is simply...a rule of thumb, for readability. Not some hard-and-fast typesetting rule that cannot be broken under threat of thumb amputation by your fellow ink-stained buddies.

Even iBooks, which has a LOT more processing power available to it, doesn't fix all the issues you're talking about on the fly--and, those it does, like widows/orphans, it limits, in terms of permutations by only having two font sizes and a limited number of devices to deal with. Kindles? A whole other kettle of fish. I tried to work out the permutations that the software works through, just covering the basics, each time someone clicks, and without even taking into account many of the more-advanced options in the newer devices, I was at 38,400, just covering fonts, font sizes, 10 basic devices and orientation. Throw in users being able to adjust margins and line-heights, AND the CSS that comes from the book producers, and it's millions. Millions of permutations, every time someone clicks a Kindle page/screen. AND--it still doesn't/can't know where the actual text is.

Does KFX/KF8 even support ‘orphans’ and ‘widows’ properties? (I can find no mention in Amazon Kindle Publishing Guidelines 2019.1)

Nope, they do not. And probably because of the reasons I just mentioned--the device scrolls X pixels of content, behind the screen. Whether that's Jane's 10 lines or Fred's 20, or a heading or a caption, or an image separated from the caption, the device doesn't care, because it doesn't know.

It's not hard to envision--one screen, one roll of TP behind it, and software that says "if you're reading this in portrait, font size X, scroll X pixels of the "page" behind the screen." Voila. (not quite that simple, of course, but...that's the basic idea.) It doesn't know if that's an image, image with caption, paragraphs of text, etc.

I fired up Bookari for iOS and downloaded a Feedbooks edition of Sherlock Holmes. It uses both Adobe RMSDK and Readium SDK (I think the latter for whatever EPUB 3 stuff is supported). I don’t see a single orphan or widow (granted this is a sample of 1 and has very simple formatting). I don’t know if this is because Feedbooks use of CSS or an implementation decision of the rendering engine. And yes, bottom margin varies from page to page, leaving me wonder if I’ve completed a chapter section, or if it is just the result of avoiding orphans and widows on relatively small (compared to print) page size. But I still think it is ‘better’.

Well, the software used may well recognize, or use, widows/orphans, which would tell the device "when you scroll, make sure you scroll these X pixels with it," but to do that, they're limiting other options. No doubt about it. I don't use Bookari--seems to me that I used that on my Windows 8/10 Tablet/Laptop device (Lenovo Thinkpad Yoga) and it annoyed me. Don't recall why; could be something minor, and I just don't remember what that was.

I fired up Apple Books and opened up one of those ‘Idiot’s Guide’ books, which has more complicated formatting. Indeed, it has what I consider one of the more egregious variants of Orphaning: a section header that appears at the bottom of the page, separated from the body text that follows on the next page. Simply intolerable, I say! But is there CSS property that tells the section header to move to start of next page to stick with the paragraph following?

In typography, that's "keep with next," used to keep headings with their content, or some portion thereof. Yes, there is a CSS property, which is "page-break-inside:avoid," if memory serves, which only works in blockquotes and pre formatted content. And it's ePUB2. There's page-break before; you can see how that won't work, given the reflowable nature of ebooks, and page-break after, ditto.

Hell, even in websites, unless I've missed a new trick (entirely possible) I believe that the go-to is still using divs, around images and captions, TRYING to keep them together, not always successfully. And a website has all the processing power in the world available to it, unlike a portable device. And even then--doesn't always work. There are probably some cooler things available in CSS3, and I know that I've been able to use Bootstrap, on my own site, to keep X and Y together, but then again, I'm not doing anything that fancy on my site--images and captions, pretty much, and hell, for all I know, they're breaking apart hither and yon.

In short, last time I looked, no HTML CSS existed that actually kept text together in disparate elements (a heading a a paragraph, or two paragraphs, an image and a caption). SOME amount of widows/orphans seems to work, but that's page-break-inside:avoid, which is quite different than making disparate elements stay together.

In any case, it seems, I must continue to tolerate some non-zero level of what I judge to be bad typography, or give up reading ebooks.

Pretty much, yes.

I don’t understand what is so hard about this. Can’t rendering engine apply some heuristics, at least where there’s ample processing power? Do we have to wait for machine learning to find its way to reading platforms?

I don’t want more Settings in the reading platform, I have no time to play with CSS. I just want it to look better.

For one thing, the "ample processing power" doesn't exist, for the sake of portability. For the other, as I mentioned, every single click, every change, can cause millions of calculations, due to the vast number of permutations. I fail to see why you would think that "machine learning" would solve it.

If the CSS existed, on websites, to do it, that would be one conversation--but even THEY deal with far, far fewer permutations than does Amazon or other device-makers and software renderers--changing fonts, for example. Hyphenation for another. On websites the reader doesn't change the line-heights, the margins, the fonts. They can't tell the website to hyphenate, or not. Yet, in that quite limited environment, comparing apples-to-apples, "keep together" still doesn't work.

But you're asking it to work in an environment with far less processing power, and hundreds of thousands or even millions more permutations, where the end user controls most of the choices? Where each and every author or publisher makes choices in design that affects the rendering? Where one guy might just slap in his image, and a caption below it, not even marked or coded as a caption, but rather, a paragraph; someone else uses them in a table, with two rows, and a third person puts them in a div, with "page-break-inside: avoid" deployed?

The TL, DR version:

Lots and lots and lots of permutations--and lots and lots and lots of workarounds, getting around limitations in CSS. Basically, you're asking eReaders to do 10x the work of websites, with millions more permuations and on-the-fly calculations, with much much less processing power.

Why is it so hard to do?

Quite simply, just because it is.

Hitch