My editors have pointed out an odd inconsistency, which I can verify on my own Kindle. In random cases throughout the book, the default indent for a new paragraph is not respected.
I think this might be a setting in conflict with the first line of paragraph setting for no indent (you can see the second line highlighted in the new para is flush left).
I’m not sure why only SOME paragraphs within a paragraph are not respecting the setting, but I can’t seem to fix it. It looks fine in the manuscript itself (there’s no extra tab or weird formatting). I’m trying to just redo the hard return, but that doesn’t seem to work.
Is there a way to fix this in settings or figure out why it’s happening?
The space between your two highlighted paragraphs seems different too.
Which leads me to think that perhaps you have a style on “He woke up,” said John, and perhaps your layout, in the settings tab at the bottom, has “remove from […] following other elements” checked. ??
I am not sure if a style can trigger this, I’ll run a test.
But that different spacing is odd. And most likely related.
The “He woke up” issues is the main problem though, yes. There are just random new lines like this - sometimes at the end of a scene, but not always - that do not get the default indent.
As for the style settings - there IS a body paragraph style. But of course due to how Scrivener works (which is a thing that really bugs me) I can’t just choose that and edit to look at the settings like a normal text editor would allow.
Anyway, if I look into the “tabs and indents” settings on any body paragraph, this is what I see. So there’s no reason why any first line shouldn’t be indented.
A style overrides whatever is set in the section layout’s for a formatting.
So as far as this paragraph is concerned, that is your issue.
Either redefine the style with the first line indent you want, or add it to the style panel of your compile format and tweak it there.
Or don’t use a style at all, (I can’t see why you’d need it from your first screenshot anyways.)
As for the first line indent of first paragraphs, that is set in the settings tab at the bottom of your compile format’s layout panel. Pick your layout from the list in the top half, and it’ll be the last tab on the right in the bottom half.
(I can’t currently produce screenshots, sorry.)
If you want your chapter to NOT have a first line indent to its first paragraph but you have sub-scenes for which you DO want a first line indent, then they can’t be assigned the same section type/section layout.
You’ll have to create a section layout that mimics the first one but without a title, and without having the first paragraph’s first line indent removed.
Not sure I was clear - the style image I showed there must be what the Body style does for all paragraphs, and that is what I want. To be clear, the style DOES have the first line indent I want. That’s the setting that shows when I go into the para indents menu (as I said, there’s no way to just look at a style’s settings, apparently - which I find insane.)
If I go and look at one of the lines that is NOT showing right in Kindle, it STILL says the same thing. .25 first line indent - except that it’s not respecting that setting.
Try as I might, I can’t find that compile format layout panel that you mention. I grabbed this screenshot from Google, which is what I think you refer to - I just can’t figure out how to get there.
That screenshot you speak of is not a style’s settings at all.
That’s just how your body text looks in the editor, and that the compile format will OVERRIDE during the compile process.
If in the editor the text looks as you want it, you can compile as-is, or at least uncheck “override text and notes formatting” at the bottom of the layout that causes an issue. Plus, in the settings tab of the layout, set the first line indent to “Do not change”.
Ok, I do remember this now. So the ONLY way to look at settings for a format is to duplicate it? I just don’t understand the thinking here, why you can’t view/edit things in Scrivener in a straightforward manner.
So if I save this, I will have two version. Delete the old one to ensure the right one gets used?
Looking at my section text - it appears to have the indent. It also appears to have the remove indent on first line of section. I removed the body text style, I will see if that was the culprit.
One thing you should do is Show Invisibles in the Editor pane in Scriv and check to see if there is a genuine carriage return before “He woke up”. You might find you have a newline character there instead of a carriage return – which would explain the anomaly.
Here is a behavior I don’t understand. Here is an example of how a particular Scrivener style I use appears in the Editor:
And here is the exact same paragraph compiled to epub and viewed in ‘Apple Books’ on a Mac.
It changes the font to Georgia. I’m fine with that. Georgia is as good a font for fiction as the font I use. The line breaks in a bit different place, of course, and that is normal (so the second line has different words displayed).
But look at the indent. I have it indented about the entire width of the small-case letter ‘m’. That’s what I want it to be. ‘Books’ indents it almost an entire four letters. Not what I have in mind.
And I have a similar style with nearly the same indentation. For that style, ‘Books’ gets it much closer to what I am asking for.
So I am not a fan of what e-readers do to my formatting. It seems needlessly arrogant to me.
Every line in the Editor version title (with the exception of the first lines of dialogue) is configured with the same exact style, with the font size saved as 12 pt., with all formatting saved in the style.
But ‘Books’, in its infinite wisdom, keeps the chapter title itself (and the visible separator) at 12 points, like the dialogue, yet for some insane reason it wants to blow up the chapter number line, to 18 pt. I mean WTF?
And this is part of a trilogy. In another volume in that trilogy, using the same exact formatting, ‘Books’ doesn’t do that.
I need some sort of magic trick to get ‘Books’ to behave the way I want.
Probably because people would make changes to the defaults and sometimes not be able to work their way back to the standard. Enforcing duplication for changes means there is alway a ‘clean’ version to fall back on.
Secondly, the changes you want to make (if any) to the standard version may not be applicable in the next project you do. It’s the same reason you can’t edit the built-in project formats, I think.
