Or am I missing something?
Noticed when compiling to epub and using ‘Books’ on Mac as the e-reader.
You should try compiling with the exact same settings to another format.
If it works, you’ll know that it is either a setting in the Ereader, or that it just plain doesn’t work for an ebook. (I personally don’t know.)
Else, if your paragraphs are too big for the Ereader’s screen, that could be why. (?)
It also doesn’t work if you put it all over your text.
And if what you want is to not have a single or two lines all alone on a “page” at the end of a chapter/sub-chapter, that is not the right function.
For that, you’d want to use “prevent widows and orphans”.
“Keep with next” is a word processing command that does not map over to ebook output. There is CSS is you need to use for stuff like this. We in fact use one form of it in the stock output. If you search the stylesheet.css file in the .epub output, you’ll find:
figure { page-break-inside: avoid; text-align: center; }
This informs the book reader to try and keep captions together with their images if possible (and supported by the reader). It’s probably not what you want if the desire is to have one element stick to its next sibling element, outside of a containing element though, because it needs a containing element which would be awkward for things like headings.
Fortunately there is another CSS formatting attribute we can use that requests how page flow should be handled after an element. This for example would try to keep all third level headings attached to whatever follows them (typically a regular paragraph):
h3 { page-break-after: avoid; break-after: avoid; }
So depending on what you need, these two attributes should help you keep text together where it should be—again though with the awareness that not every ebook reader will support them. We can only do our best, in that regard. Use the CSS compile format option pane to insert your custom CSS. We are using two attributes here, because the latter (break-after) is the modern version, but since adoption rates can be slow and book readers tend to stick around for many years, it’s best to use both.
Incidentally these attributes are also useful for controlling page flow when you do want a visual break. Full screen images for example can be achieved by using the page-break-after and page-break-before attributes, and specifying always instead of avoid.
3 Likes
Since an e-reader monopolizes document flow after the fact, I guess it makes sense that preventing widows and orphans is beyond the reach of Scrivener for that sort of compiled output. So no, it’s certainly not a bug.
Sadly, e-readers don’t seem to be sophisticated enough to handle that on their own.
I’m puzzled by what a ‘third-level heading’ might be. Does this refer to the third indent level? Such as the document level in the Binder if you have chapters configured at the second level? Or is it some level in the compiler itself?
If that refers to keeping the document title locked to the document in document flow, I guess that wouldn’t really be helpful when the documents inside a chapter are designed to just flow contiguously and the document titles themselves are not meant to appear in the text.
Yes, the third indent level (if there is one). Chapter → Section → Sub-Section, for instance.
Whether the Compiler recognizes it as noteworthy depends on your Compile settings. Here, Ioa offered it as an example.
You can also get H3 headings either through style use, where the style has the Format ▸ Paragraph ▸ HTML Level menu command set for it.
But as noted, the idea isn’t to strive to somehow get H3 headings into your document so the verbatim example works, but rather to put the CSS attributes on whatever element needs them.
What would be great is to have the ability to put those attributes on individual lines of body text.
Scenes often require transitional elements regarding gaps in time, or changes in location or focus, to smooth the path between scenes.
In fiction, I think it probably should be rare, but sometimes we use a single line heading to a scene or half-scene that truly does belong with that scene, such as ‘Monday, November Fourth’, often in italic, typically following a line break, to introduce a time stamp in the scene intro, if the author’s judgment call is that it is needed.
Sometimes that can be effective (but typically I avoid it bc it is only rarely effective). But that loses its impact if that first line is orphaned at the bottom of a page. And since e-readers make their own decisions regarding text flow, it’s impossible to predict whether that will happen or not.
But the bottom line is it can indeed happen. And if there were a way to prevent that from happening, it would improve the story and the reading experience.
1 Like
You can certainly do that, and I think the approach for doing so would be perfect for what you are describing: this would be a style-based declaration for that type of text. Say for example you create a “Scene Transition” style and put it on one of these paragraphs. When you compile that and examine the HTML, you’ll find:
<p class="scene-transition">Blah blah...</p>
Now that we know how Scrivener modifies the style name to become a valid class label, we can add the CSS to make it work, like:
.scene-transition { page-break-after: avoid; break-after: avoid; }
This is why highly formatted ebooks – like textbooks and highly technical books – often use PDFs instead. It is extremely difficult to enforce any kind of layout choice in an ePub.
I am a CSS newbie.
But I created a style named ‘scene-transition’, applied it to a 1-line paragraph, then copied your line of CSS and pasted that at the bottom of the custom stylesheet for a copy of the format I was using.
Of course, I am out on a limb (and I might have heard of cracking noise!), but it seemed to make no difference to Apple ‘Books’, which might have ignored that.
You can double-check that the ingredients are all working as intended by opening the ePub in Sigil or Calibre Edit. What I like to do to test and see if the CSS is impacting the thing you mean it to is to add something like color: red to the CSS line (between the curly braces). If the paragraph you intend to be formatted turns red in the preview, you’ve got it all set up right.
The rest is up to the reader to handle it properly.
Interesting. I added ‘color: red’ as suggested.
Even though the format I am using is set to remove all color, it did indeed turn the color red in the ‘Books’ reader. So I assume I likely edited the CSS correctly.
‘Books’ was happy to turn the type red. But it rejected the concept of keeping that line married to the following paragraph.
It’s too bad Books doesn’t handle this in an optimal fashion, but at least you know that in those readers that do, the book should look better than it did.
As for why it turned red despite your settings, that is because the only thing that matters in the end is CSS. Almost every checkbox and setting in the compiler generates or modifies the CSS of the book (those that do not adjust the HTML structure). So what you put in the CSS pane itself always wins! It’s your way of having total control over the book design, or handling it all yourself and largely ignoring the compile settings, for those adept in it or that have been given resources by a designer.
Hence, learning a little bit will never hurt, even if all you do is here and there pick up a trick from a web search or two. You’ll be able to do things the compiler cannot do.
Thanks. Always nice to learn a little something new.
Now I want to take a deep breath and learn CSS. That should only take 5 or 6 years.
But I have novels to finish. 