I just want to doublespace the “No Style” (body text) of my manuscript when I compile it.
I’m able to effectively set line spacing on text with a custom style at compile time.
I’m not able to find a way to do this for text marked, “No Style”…
I can do “Document > Convert”, but that doesn’t make sense as there’s a whole feature set around compiler automation/override and [Document > Convert > Text to Default Formatting] requires a bunch of other hoops like selecting documents and options.
I can export to Pages/Word where “No Style” is being output as the style “Body,” and convert there, then save to .pdf, but again, seems like a workaround for something that should be simple and part of the compile.
I can create a style called “Body”, but I’ve read a number of people saying not to do that. This actually makes the most sense, because the compiler overrides work and so does the [Format > Style > Redefine Style From Selection] option is a regular part of my workflow.
I’ve tried mucking with section layouts and applying section types, “Chapter,” “Section,” etc, and then overriding those styles, but that didn’t make sense and had no effect.
There is a default “Body” style in many of the compile examples, Manuscript (Courier), for example. “No Style” converts to “Body” when exporting to .doc/docx. It would really make a lot of sense if “No Style” used the “Body” style under the compile profile.
Creating a “No Style” style in the compile profile doesn’t affect “No Style” text.
In the Compile dialog, when you assign a Section Layout to each Section Type that includes text, or if you have already done that go to each such Section Layout in turn (this is the layout assigned to each of my Text sections):
Click in the text in the bottom pane so that the cursor is visible in the text area, then click on the button for the Text Spacing dropdown and choose “2.0”:
That will assign double spacing to all the text set to No Style in all the sections with that layout assigned; the effect will be immediately visible in the pane.
Mark’s reply is very complete. The part I’m learning to remember is: formatting you see in editing is for your use only. How it outputs is a second layer in compiling.
I write in single-space text in the standard system font, and the Manuscript Times New Roman format is the magic that turns what I see into the preferred output.
So if it’s a matter of changing what you edit: styles in the editor panes.
If it’s a matter of what you get out the other side: as Mark describes, with section mappings to compile formats.
That sounded okay, except for the above part. I think the primary reason for Styles in Scrivener is so you have some way to tag passages of text or paragraphs so that they can have a different presentation in one’s output. What precisely the styled passages are to look like in output is controllable in Complie or can simply be passed on from their look in the Editor.
one would use any styles in Scrivener is precisely to be able to make those passages present differently in the output.
There’s overlap. If I bold something in the editor, I expect it to float through to the compile with minimal fuss. Semantic styling is where I am still breaking bad habits. Maybe instead of bold, I should define a Very Emphasized style for the editor, and make sure that’s styled appropriately for the compile format.
What I was clumsily dancing around was: there’s two layers of style, one for you in Scrivenings, and one for compiling into (whatever.) They may be congruent or not, but Scrivener is not a WSYIWYG editor, like Word. Don’t get too attached to style appearance in the editor.
On the flip side, this means also don’t worry about style appearance in the editor. I’ve really taken to using the style highlight color so I can see when I’ve marked (or missed) a passage that will get special treatment later. Text I will output in small-caps I have highlighting in a garish pink in the editor, so I can really spot it. I don’t have to worry about it coming out pink on the opposite side in a compile
Styled text only change at compile if (and only if) the said style is listed in the styles panel of the compile format, and set there to be formatted differently.
Otherwise it’ll compile just as you see it in the editor.
Exactly. And as handy as my garish pink “style” is, the rendering is small-caps on compile. Or the editor style I used to wrap @online_handles so I could apply CSS on the other side to ensure the @ isn’t broken by a line or justified spacing.
WYSIWYGUYSIUTW
What you see isn’t what you get, unless you set it up that way.
I think the standard compile formats have reasonable mappings for the default editor styles out of the box. Custom styles require action or will likely be “No Style” during compilation.
