How to *KEEP* indents in the first paragraph of a new ePub3 section

Using Scrivener 3.0.3, macOS 10.13.6, Compiling to ePub3.

I want my scene breaks to look like:

Screenshot_2018-10-21_16_41_46.png

Instead they look like

Screenshot_2018-10-21_16_44_21.png

To be clear, we are talking about two instances of “Section Text” butted up against each other, with a non-standard separator, “* * *” I am happy to provide more detail. And I would really prefer to not have to learn CSS or …mess… with CSS at all in order to do this. Not that I can’t learn CSS, but I decided when I retired that I would never learn another computer language in my life if I could possibly avoid it.

I am sufficiently annoyed (with the universe, not any particular company or individual…) that I am tempted to give up some nice formatting on my title page and run my story through Smashwords Meatgrinder to get an INDENTED follow-on section.

Do you have the FLI option set to remove indents after separators? Does it work if you turn that off?

Slàinte mhòr.

Okay… thank you, JoRo. I was expecting this to be under section layout settings (as it is for other compile targets).

Does this mean (as I have every reason to suspect now) that this is NOT controllable on a section layout by section layout basis? That this is an ePub3 global setting? If so, that …stinks. I’ll work around somehow but I set up my compile thinking it was a layout by layout thing. It’s too late to figure it out tonight…

Welcome.

I believe the setting is global, but someone more knowledgeable than me will be able to answer for certain and, perhaps, offer a solution.

Could you fudge the few instances by manually adding in the asterisks in the editor (and running the sections into one document) so that things don’t get changed during compile?

I expect Keith or Ioa or Nontroppo or Brookter et al will have a swanky solution for you. Anything but the Meatgrinder… that is such a loathsome and disrespectful term for any company to use when dealing with the hard-won outpourings of an author’s soul. What were they thinking?

Slàinte mhòr.

Hm, no swanky solution from me at least. I would possibly be able to fix this with CSS, but you don’t want to go that route (CSS is not a Turing complete programming language, but a declarative styling format so perhaps you can exclude it from your “computer language” category? :laughing: )

Wow, I’m sorry to hear you think it “stinks”. I spent an hour and half first thing this morning implementing a setting that removes the indents only from the first regular paragraph of a section in ebooks just to help you with this, which will be in the next beta. Right now, though, I’m going on holiday for a week. With internet. I think I need it. :unamused:

Well it might be worth seeing if the next beta fixes this for you. But for the sake of demonstrating the technique, here is how indents can be controlled more precisely.

CSS looks like a programming language with all of the brackets and semicolons, but it’s more along the lines of a JSON file in that it has some rules to follow, but the content itself is declarative rather than logical. If you’re dipping into ebook construction, it’s a very useful thing to know the basics of, as you can get quite far with a little knowledge—especially if you have a strong stylesheet to start from rather than making your own from scratch.

I’ll grant this is a slightly more complex case than changing something like the following:

h1 { color: red; }

If we want a blue heading 1, it’s a straight-forward fix. But to control certain aspects of global formatting on a per-Layout basis, you want to first give your Section Layout a CSS class name, in the Settings tab, like “scene-text”. This will cause the HTML content for this section to be inserted in a div, and to give that div a class name. This will grant us specificity in doing things with the contents of that div while leaving the rest of the formatting elsewhere in the ebook alone. To take the above simple example, if we put the h1 inside of a named div, then we could make it blue, while leaving all of the other h1 headings red:

h1 { color: red; } .scene-text h1 { color: blue; }

Moving over to the CSS pane: what we have in the stock settings are a set of paragraph indent formatting rules that are adjusted by the settings you make in the Text Layout pane. These rules are added at the very top of the CSS in the “Default Stylesheet” column. Here is what they look like with default settings (all enabled):

.separator + p { text-indent: 0em; } .separator + div > p:first-child { text-indent: 0em; } .br + p { text-indent: 0em; } .br + div > p:first-child { text-indent: 0em; }

A couple of those are rather advanced cases of selectors (what we call the part before the curly brace). In natural language, the first line means “all paragraphs following something that calls itself a separator”. How a thing calls itself something is with classes—or what we added to the Section Layout itself. The second selector means, “the first nested item within a div that is also a paragraph, where the div itself follows something calling itself a separator”. (Whew!)

Let’s take the two simpler examples first. If we want to change how paragraphs work inside of a class (which again, we’re adding to the whole Layout), then just like with our simple blue h1 example above, we tell the CSS engine to only apply the rule to matched stuff falling inside that class. Let’s take the first line as an example:

.scene-text .separator + p { text-indent: 1.5em; }

Now we are saying, “all paragraphs following something that calls itself a separator, that are both nested within something calling itself scene-text”. Note we’re also setting the text-indent here to non-zero, you’d want to match your settings with that part. Here are the rest of the lines:

.scene-text .separator + p { text-indent: 1.5em; } .separator + div.scene-text > p:first-child { text-indent: 1.5em; } .scene-text .br + p { text-indent: 1.5em; } .br + div.scene-text > p:first-child { text-indent: 1.5em; }

So the only major difference between the two types of selectors here is that one set looks for how to format stuff inside the “scene-text” Layout div, and the other checks around the div for breaks, so the “scene-text” part gets added to the div selector in the middle. If we put it at the very front like the other examples, it wouldn’t work because the two different possible forms of HTML here are:

Simple case:

[code]


First line of scene…


* * *


First line of scene…

[/code]

Complex case:

[code]

* * *

First line of scene...

[/code]

So for that second case we need “the first nested item within a div (that calls itself ‘scene-text’) that is also a paragraph, where the div follows something calling itself a separator”.

If you have multiple layouts that need this treatment, you can add multiple selectors before the curly braces, separated by commas. Here is an example (it can be on one line, but I’ve broken it out for clarity):

.scene-text .separator + p, .other-layout .separator + p { text-indent: 1.5em; }

You want to put these overrides at the bottom of the “Custom Stylesheet” column in the CSS pane.

Please enjoy your well-deserved holiday, KB! I was referring to needing to re-think my compile strategy, not to your excellent software (and my diplomacy module, definitely one acquired in a 99 cent store, goes offline at 1am. My apologies!) As I said, I’ll need to re-think my compile strategy—not practical at 1am, either. Thanks for your efforts at making this easier! I look forward to trying out your implementation after your holiday.

@JoRo, yes, “Meatgrinder” is a horrible name, but the actual software does a decent job of converting a simple Scrivener .doc output into several different ebook formats (epub, .mobi, PDF and HTML are the ones I use). The epub output is perfectly serviceable and is what I sell on Apple Books, Kobo, and Nook, but since Smashwords doesn’t distribute to Amazon, I have a separate compile format for the Big A, with a lovely title page that’s likely too much for Meatgrinder to digest.

I wouldn’t try Meatgrinder on Word output, though. :smiley: Scrivener puts out a much cleaner .doc.

@nontroppo, thanks for the info on CSS. I may yet need to learn it :neutral_face: .

@amberv, Thanks for the detailed lesson! I’ll try it later today when I can sit down at my Mac (on my phone right now.)

@amberv, thank you again for the CSS lesson. I was able to perpetrate my perverted formatting without a hitch. @KB, I look forward to (possibly) being able to do this without CSS in the next beta. I’ll certainly check it out.