How to keep epub reader apps from changing my formatting

Latte Other Software & Development
1

I’m lookin’ at you, Apple.

I think we likely all agree that formatting is exceptionally important. So the big question is why, why, why, does Apple Books try to mess with that?

Probably an inscrutable question.

So my real question is how do I fight against this?

My best guess is that formatting to e-pub in Scrivener is probably formatting to a plain vanilla format that fits the requirements of e-pub, and it may have no ability, since it must fit the ‘rules’ of that format, to do things that will prevent Apple from screwing everything up.

My wishful thinking is that maybe there are ways to fix this, hopefully in Scrivener.

To wit, I use a carriage return, a blank line, to subtly indicate scene changes. Apple, in their remarkable wisdom, removes that blank line if it falls at the bottom of a page in ‘Books’ (and yes, I have the compiling set to not strip blank lines). I am not about to use three asterisks or some icon for a scene change.

The blank lines are there for a reason, Apple. Please leave them there.

What’s worse is they add blank lines indiscriminately, wherever they feel like it. So I may get a couple blank lines that DO NOT BELONG THERE in any chapter. This screws everything up. The subtle cue for a scene change no longer makes any sense to the reader if sometimes it does indicate a scene change, but sometimes it’s there for no real purpose, or if the blank line goes missing based on it falling at the end of a page in Books.

It could be they are trying to not ‘orphan’ paragraphs by not having half the paragraph on one page and the other half on the next, so they move the entire paragraph to the next page. Whoever imagined that was a good idea? Not an actual writer, of that I am certain. The end result is a blank line where it isn’t wanted or needed.

Then there’s the indenting. I created a particular indent in Scrivener, yet Apple Books thinks they know better, and change that indent to something twice as big. Not what I have in mind.

So what I wonder is if there are settings in Scrivener (likely the compiler) that might prevent Apple from messing with these things.

Or, should I compile to some third-party app that can then be converted to e-pub in a manner that will solve the issues.

And is there an invisible character in Scrivener? I use the ‘word joiner’ all the time ahead of m dashes and the non-breaking space ahead of elipses, but I suspect neither could be placed into a blank line all by itself. If it could be, that might solve the deleting of the blank line problem. Or not.

So I welcome any input from anyone who might have a suggestion. Thanks in advance.

2

Yes. A non-break space should prevent blank lines from being removed. As a matter of fact, epubs can’t have blank lines at all. Unless you insert a non-break space. (A style with space after should work too.)

As for the rest, whatever it (the ereader) is doing, there should (but not always) be an option to stick to “publisher’s formatting”.

So in short, no, you can’t force a formatting on a device, unless its owner has it set to stick to the original formatting. (Or if you don’t mind publishing to pdf – yuk.)

3

The short answer is that you can’t, not easily.

Ebook software is designed for readers, not writers, and as such allows readers to change the font and font size at will. Which means that “page breaks” are entirely unpredictable: even Apple has no way of knowing in advance where they will be.

Removing blank lines at the bottom of a page is actually a pretty standard typographic convention. Scrivener does have a setting to use asterisks (or whatever) only in those situations, but obviously it only works in formats that understand page size.

For indents, double-check to make sure you haven’t used tabs, as indents + tabs is the most common cause of overly large paragraph indents.

1 Like
4

Apple Books (where e-pub is the only format) does indeed allow blank lines, even without a non-breaking space or any character of any kind. It just doesn’t do it consistently, and it even creates its own blank lines where one might not want them.

What I’m looking for is an option to stick to “Author’s formatting”.

I’m not implying this is a Scrivener issue. It’s an Apple issue. But maybe Scrivener has ways to ameliorate this which I don’t yet know about.

So I will do an experiment with adding invisible characters to lines that are in reality technically only a carriage return, and report back.

5

My answer wasn’t oriented specifically toward your Apple app. (Never used it.) But if you intend your publication to be read on any other “standard” ereader, what I said is true.

@kewms Same as for blank (empty) lines, ereaders don’t display tabs. (But again, what this Apple app does or doesn’t do? this I don’t know.)

6

  1. The first thing about ePub is that the reader controls the appearance on their device to the extent permitted by the device’s software: font, font size, justification, maybe indents. So as the author, you have to go with that.

  2. ePub is a (sub-)set of html, which doesn’t support blank lines, and the only way to make one is to have a non-break space in the line, just as is the case on a web page.

  3. If you want to see what’s happening to your document following compile to ePub, open it in an app like Sigil, where you can examine the CSS and code directly.

  4. Scrivener compiles to valid ePub, from there it’s down to the reader. If you modify the CSS and the code, there is a possibility that it will be rejected as invalid if/when you come to publish.

Mark

7

It may be possible that you missed this: Apple Books is e-pub only. When I compile with a blank carriage return, to e-pub, in most cases that does indeed make the trip. It is there in the reader. So it does support blank lines. It just does not do this consistently. It also supports the chosen amount of points after a paragraph and inter-line spacing.

The reader does control certain things in Apple Books. I think you can justify the ragged edge, for instance, or choose not to, or double-justify both edges. Font and font size, sure. I’m fine with that. And quite obviously, that will determine where the page breaks will be. Of course. No problem. But why it sometimes removes the blank lines at page breaks and at other times doesn’t, remains a mystery.

The reader apparently has no control over indenting, however. We are left to the arrogance of Apple’s arbitrary decisions there.

What is puzzling is this: I indent the first line of narrative paragraphs 14 points, and I also indent dialogue 14 points. The only difference there is dialogue begins with a quote mark while narrative does not. Apple Books indents dialogue properly, at about what I set it at. Yet it indents narrative twice as much.

I’m not sure I’ve seen Apple do anything quite that boneheaded before.

8

It is a mystery for which you would need to consult Apple Support. If the blank line, indent, or other formatting is there in the output document, Scrivener has behaved as instructed.

1 Like
9

I didn’t think of it before, it just came to me as I read the title of the thread again .

Perhaps that would work for you :
A good while back I was looking for a way to have android ereaders not mess up my ebooks by removing italics and – well they mess up pretty much everything.
Thing is that they ditch the css stylesheet completely. (Not all of them apps, but close to all of them.)
But, but but, I found out that if your formatting is inline instead of in the stylesheet, it forces them (forced, or they are designed to obey only those ??) to respect the instructions they receive formatting wise.
With any luck, that’d be your fix.

On the other hand, the fact that your Apple app doesn’t ditch the empty lines as any ereader normally does (the html explanation was given earlier) leads me to think that there is some kind of silent conversion going on first. What it shows you ain’t quite an epub anymore. (Meaning that if you plan on publishing, you can expect these blank lines that you want in there to disappear on you whenever your reader will be using anything but your Apple app. You should use a non-break space (or a style + paragraph space after) even if it works without in this specific app. As a matter of fact, should you use Sigil and wish to clean up the code, it’ll sweep them empty lines out. – They’ll be gone before they even got a chance to exist.)

10

What Apple device(s) are you viewing your ebook on? The iPhone version gives you the option to switch between paged and continuous presentation. If you switch to continous and your (possibly too) subtle blank line scene separator is there but not in paged style then I guess Apple are trying to be kind to human readers who might think there is something wrong with your publishing process when a blank line appears at the top of a page; the reader is unlikely to notice a blank line that appears at the bottom of the page. I would certainly be one of those who reacts badly to this top-of-page effect upon my visual perception.

The iPadOS version of Apple Books also has this continuous/paged capability. Sadly the macOS version of Apple Books does not have it and only presents in pages. But you might be able to check in the macOS version is ditching your blank line by changing the size of the Apple Books window forcing the material to be redrawn on the screen.

1 Like
11

Presenting as continuous rather than paged is not the problem. Paged is fine. Continuous is fine.

The problem is the arbitrary REMOVAL of random intended blank lines, and the arbitrary INSERTION of random UN-intended blank lines. And that this happens completely inconsistently.

The blank line, or extra carriage return, is an important tool for writing fiction. It is often a cue to a reader that time has passed, focus has changed, location has changed, or a new scene has begun.

So we should expect that to be consistently something an e-reader respects and is faithful to, bc not respecting it is usurping authorial wishes, and confusing the reader.

And no, inserting a little filigree or 3 asterisks is not acceptable as a way to force this.

What I do to minimize this is place a non-breaking space on all intended blank lines, bc that is invisible. But it does not seem to fix the issue in ‘Books’.

They also don’t respect the formatting of that blank line. If you set the formatting to be a different line height, they ignore that, too, and just shove in whatever their arrogance imagines the line height should be.

12

You mean like a… scene break? Why would you try to format this with carriage returns? I mean, in every scenario not involving a typewriter.

1 Like
13

Yes, it can indicate a scene break. That is why I said ‘or a new scene has begun’, above. Define it as you wish, but I define a scene break as the (sometimes invisible to the reader or not noticed by the reader), moment when one scene ends and another begins.

Readers may not even notice this. Or they might. It doesn’t matter. All they want is the story. Authors are better off defining for themselves where the breaks are so that they can regard each scene separately in a vacuum and make sure it has all the elements it needs, including when the moment of change isn’t clearly defined, and is fuzzy.

Sometimes scenes overlap each other. Sometimes scenes encapsulate other scenes, like flashbacks, then return to the original time, place, and focus. And sometimes the things that can be regarded as where a scene might end (change in location, change in focus, gap in time) can happen in the middle of a scene, too. It’s arbitrary. One writer might define those boundaries differently than another.

Writers need to look at the story as a whole as well as all of its parts, separately. Readers just want to read.

But I also want the breaks to give the reader just a very subtle cue, which is why I use only a blank line or carriage return (also a fuzzy definition). I don’t want to pull them out of the story with asterisks so that they stop being in the fictive dream and instead are thinking, ‘Oh. A new scene.’ I’d rather they just float right on through.

14

Of course. We all do. That’s why I’d suggest: Don’t invent new formatting workarounds. If you fight the ebook reader (the app or device, not the human holding it), it will fight back.

2 Likes
15

For example. A chapter in Scrivener, containing two scenes:

Scrivener
Scrivener1406×724 179 KB

Scrivener Compiler settings:

Compiler
Compiler1800×464 80.8 KB

Compiled to ePub, viewed in Apple Books:

ePub
ePub1248×796 40.4 KB

Compiled to Pandoc → ePub, viewed in Apple Books:

Pandoc ePub
Pandoc ePub1170×554 33.4 KB

16

If you compile that to epub and view it in Apple ‘Books’, there will be no blank line. Scrivener has placed a separator between the paragraphs, and not a blank line.

The separator is only an indication in the Scrivener Editor that one document has ended and another has begun, not that a scene has ended. A scene can have a dozen or more documents that comprise it, and include a dozen or more separators indicating this to the writer, which is one of the stunningly powerful features of Scrivener—it allows you to break a scene down into separate moments (in separate documents) which is a boon to the author, yet stitches them all together as a single document during compiling, which is the goal the author wants for the reader.

The decision of where a scene ends is an artistic decision, not a technical decision. Scrivener can’t make an artistic decision, and we really do not want it to (although it may be possible for the compiler to be programmed to place a blank line at the end of every document, but I see zero value in that).

Otherwise, if you want to create a blank line, you have to add that manually. You have to make that artistic decision, yourself, as the artist. And that is the way is should be.

And ‘Books’ should not be trying to make those artistic decisions. They should back off, shut the eff up, and allow the author to make them.

17

I just showed you that it positively will. Both screenshots show the compiled ePub files in Apple Books.

Yes, Scrivener doesn’t care how you structure your work (I use “subdivided scenes” regularly). It doesn’t have to. It still produces an ePub with those “empty” lines exactly where you want them. And Apple Books also doesn’t care. Unless you’re feeding it questionable code. It’s basically an HTML viewer, not a magic lamp.

1 Like
18

That can only mean you have programmed the compiler to do that.

And I honestly don’t know why you felt you needed to show us that in this thread (though I welcome your input and thank you for your participation)

It never does that for me, bc I have not programmed the compiler to do that. And the reason is what I spoke of earlier—I want a scene and a chapter to be segmented in The Binder and The Editor but not in a compiled epub.

That’s about the only way to clearly and efficiently separate scene moments for writing and revising without showing those separations to the reader, who neither needs nor wants them.

It’s also one of the many things that makes Scrivener such a great platform.

19

Nope. All you need to know is contained in those four screenshots. I haven’t changed a thing, that’s out of the box Scrivener.

Would you believe it otherwise? I mean, you don’t even believe me now, so I guess that didn’t work… :partying_face:

Well, I acknowledge your problem, but it has (almost) nothing to do with programming the Compiler. I still think we can get you back on track.

Good news: That’s easy to achieve. I use a “subscene” Section Type for that (doesn’t matter how you call it). Defined via C.2.3 Default Types by Structure (in the manual).

Basically anything “under” a scene is automatically of that type, I don’t have to manually change it or anything.

And this (sub-)section type is configured (in the Compiler) to don’t insert lines or anything before / between. The reader will never know how I structured this in Scrivener. You could do this even on a sentence level if you wanted.

3 Likes
20

Then my guess would be that the default programming for the compiler is what you have, that you never touched it, and that is why you are getting what you are getting.

All I remember is that the concept of the compiler integrating all docs nested into a chapter folder into a single doc for the reader was something that I did not realize for maybe the first year I was using Scrivener. I think I discovered how to do that by programming the compiler in a way other than the default.

I took a couple courses, so maybe that’s where that came from.

But the important thing here is that this is completely possible, and it is one of the strongest advantages Scrivener has over other platforms, and I highly recommend this for anyone writing conventional chapterized fiction.