I had an all caps lead-in working for a while, and now it’s disappeared. The preview box shows ALL CAPS. My settings indicate ALL CAPS. But when I compile, there are no all caps.
Using Run-in titles
Merge the last part of a title into the first line of the following paragraph with the option [Insert title as run-in head], located at the top left of the Title Options tab. The last part could be the suffix used or the title itself. Scrivener will use the font, font size and character attributes of the title, but the line height and ruler settings of the first paragraph. Preview the result in the Tiles shown in the Compile Overview window.
So, you got to have a title or a suffix for a run-in head to show up…
Thanks for your reply. But I’m not looking for run-in titles. (Though I’ve now just learned about running heads/run-ins. 
)
There is an option for Number of opening words to make upper case. I select four words. The result should be that the first four words should be uppercase. This shouldn’t require a workaround. It’s a function of the software and nowhere does it state it’s dependent on anything else.
(Also, for my first few compiles it was working. But I noticed it stop working after I started using styles.)
EDIT: I just did a test with some extra sections that have No Style and the ALL CAPS lead-in is working for them. So using a style is cancelling out that function.
CSS rules for e-books.
Yeah, I get that. But the software is failing to perform its stated function, is it not?
That is the reason that setting up a ‘Normal’ or ‘Body’ style in Scrivener causes more trouble than it’s worth. Scrivener styles are there for any stretch of text that differs from the default. It’s called “No Style” because there are no style parameters attached to it, so any ‘styling’ can be added at compile time.
Hence you can write your text in any font and size that you are comfortable with and at compile it can be output using appropriate font and styling for the target format.
A defined style overrides that ability. Or rather, you need to include or define your styles in compile. So if you have a ‘normal’ style, you need to re-define it for every single compile format that you use.
And, as you have found, styles don’t include capitalising the first x-number of words. I haven’t tried it, but a workaround might be to see if you can set up an “ALL CAPS” character style, for your current situation.
HTH
Mark
Hmm… okay, so what is the point of using “editor styles”? Why not just style everything in compile?
Maybe to use editor styles like “preserve formatting” in Scrivener 1, if they take precedence over compile?
But thanks for the heads up! I duplicated my draft and made it all No style, then formatted it during compile with no problem. (Man, I wish I didn’t waste hours trying to solve this!) 
You can set up paragraph styles without character information. That acts like ‘Preserve Formatting’ in v. 1, but you can change things like line-spacing, indentation, etc. and the changes will propagate to all paragraphs with that style, unlike ‘Preserve Formatting’.
So, say you have three levels deep with the document titles set to compile as headings as ‘Heading 1’, ‘Heading 2’ and ‘Heading 3’ respectively, you can create a ‘Heading 4’ style to use within the editor, but then you need to set it up in your compile format.
Mark
Okay, thanks. I had actually imported my custom style “Body Text” (to see a difference from Body) to the compiler styles as I thought I needed to have the editor match the compiler.
I guess it’s good to set styles to text as way of “tagging” it, but it doesn’t really matter what the style attributes are, seeing as it’s styled in the compiler.
But assigning styles in the editor will still cancel out the compiler option to capitalize x # of words at the start of each section. (And unless I’m missing something, I regard this as broken.)
Cheers
The Compile command isn’t allowed to change Styles unless you explicitly redefine the Style as part of the Compile settings. From Scrivener’s point of view, the whole point of a Style is to say “this text is special, treat it as such.” So the behavior you describe may be unexpected (to you), but it is consistent with how Styles are “supposed” to work.
Yes, “tagging” text is a primary function of Styles, especially in the Editor.
Yes, one of the major purposes of the Compiler is to define the appearance of your final output.
1 Like
There are a couple of reasons.
-
Some people submit work that requires specific formatting (including fonts) that would b e very unpleasant for them to look at day-in, day-out while they’re editing. If my eyes like having 64-point pink Comic Sans as my editing font on my 4K monitor, then I can set my default formatting in the Scrivener editor to this combination. During Compile, Scrivener will sensibly change all the default formatting to whatever the default is my compile format tells it to. If I have used any specific editor styles, and set up corresponding compile styles, then Scrivener will override the styled text as well. Decoupling the editing environment this way helps keep Scrivener comfortable to use for a larger number of people while requiring only one-time setup for each new style that is introduced.
-
Some people have a workflow where they will regularly change their default text formatting (for whatever reason) – it helps them look at their text in a new way and spot mistakes, they are doing a round of revisions and want to track what text has been revised, etc. These people are easily able to implement these kinds of workflows in their editor without requiring changes to the Compile format.
-
Some people produce multiple formats of output from the same source document, and they can have wildly different format requirements. By having multiple Compile formats available, they can have a single source project that can easily produce these kinds of output without requiring any changes to formatting in the project. Think about how you’d do this in a traditional WYSIWYG word processor – you’d have to produce one set of output, then change all your styles, etc. Since having the split between editing and compiling makes this possible, we get the ability to style the editor separately for free.
Thanks for your reply. I think the behaviour may be unexpected to a few more people than just me.
If you’ll bear with me, I have three questions/points for clarification.
FIRST, the Compile Screen gives three options:
- Text and notes use default paragraph formatting
- Text and notes use custom formatting
- Text and notes use editor formatting
I assume these mean:
- the default style in the compiler
- the user-selected style in the compiler
- the user-selected style in the editor
By selecting #2, the compiler styles should override the styles applied in the editor. No?
SECOND, the “uppercase lead-in option” on the New Pages tab in compile, says nothing about styles. The existence of the option and its WYSIWYG preview window in “Section Layouts” implies that’s exactly what it’s going to do. (Why have a preview window if that’s not how the text is going to look? That’s not a preview.)
THIRD, is there an option in the Editor styles to make “X number of opening words uppercase”? If not, then I fail to understand how to use this formatting option unless using No Style in the Editor. But then, I can’t use styles. Do you see the conundrum?
BONUS FOURTH QUESTION: I just noticed faint grey text on the New Pages tab stating: These options are only applied to sections after page breaks. However, they’re being applied just fine to my sections after line breaks, not page breaks (when using No Styles in the editor).
As @kewms mentioned above, the Editor Style takes precedence over the Compile Style, so it won’t override anything. Or… by “corresponding compile styles” do you mean styles that have the same name in Compile as they do in Editor?
For example:
I want my my subheadings to be Trade Gothic LT Std Bold 36pt, but I don’t want to be looking at huge 36pt subheadings on my screen while I’m writing. So I create an editor style called Sub-TG36, but make the font size 12pt. Then I import the Sub-TG36 style to the compiler window, but change the font size to 36pt.
Is this how it’s working or am I still way off base?
PS: I totally get your other points and understand the reason for styles. I think styles are a very welcome addition. It’s the execution of them I’ve been having trouble with since my battle with the “all caps lead-in option” on the New Pages tab.
Yes. Per section 24.4 in the manual:
It is not necessary to build out a list of every style you use in your project. Think of a Format’s stylesheet as being a list of exceptions, or clarifications on how your styles should be exported. If the Styles pane does not list a project style by name, then the compiler will protect the applied formatting from most processes the compiler would otherwise use to reformat text. This is a selective behaviour: a style that does not address font families could have its font overridden by the compiler, but not its paragraph alignment.
And:
Names matter. The only tool Scrivener has at its disposal for matching styles you use in your project is by name. Matching styles will have their attributes modified as set up in this pane.
If you require a different style name, as stored in the final document (say to match with an import template in another program), you can use the Override name option, for those formats that support named styles in the output.
Hence the use of styles to capture differences instead of having to have a style for every bit of text. You set up your default formatting in Scrivener (or per project). You create and apply the styles in the editor to tag text that needs to be different. Set these up for your comfort and convenience.
When you compile, your chosen compile format will apply its transformations to all the text, excepting the specifics that are defined by your editor styles. If you need to override the editor styles you also create a compiler style in the format of the same name, and specify the additional overrides. Style names will be passed through; if you need them to match style names in your output (say you have DOCX and a custom Word template from your publisher) you either name the styles accordingly or use the name override to change the style name that gets passed into the compiled document. (This also allows you to have multiple styles that all compile out to the same output style, BTW, since your compile formats and styles don’t have to be project-specific.)
2 Likes
@devinganger Nicely explained. Thanks for taking time to write that out.
One last question. (The one that started all this.) Regarding the Number of opening words to make upper case option in the “New Pages” tab, how do I get it to work with styles? As far as I can tell, it only works with “No Style”.
Since “upper case” is not a unique font (like bold or italic), you’ll need to apply capitalization directly in the Editor.
Okay, thanks.
So, the “Make x words upper case” option in the compiler only works with No Style. (I’m not a programmer, so not sure why it can be applied to text with No Style but not to other text, but if it can’t be done, then it can’t be done.)
Scrivener might want to add another sentence after “These options are only applied to sections after page breaks” also stating that “These option are only applied to sections with No Style.”
@drcwright You’re already well beyond this point in your understanding, so this is a little late for you, but for anyone who has skimmed this thread, the general principles underlying the design of Scrivener Styles are nicely summarized in the user manual. See section 17.1 Think Different.
Best,
Jim
1 Like
Yes, but still worth reading a few times. 
Especially:
So that is the first principle to understand: with Scrivener, styles are for exceptional cases in which we definitely want the text to look a certain way. In most cases you should see scattered uses of it in your work, rather than hundreds of contiguous words assigned to one style after another.
The point is to do lots and lots of things for special cases … but that doesn’t mean every paragraph needs a style.