I am not really a Scrivener power user, but I love Scrivener because, while I’m a minimalist, it does what I need.
HOWEVER, with the upgrade the Scrivener 3.0, one of the things that’s changed is the persistence of italics. And this is a problem if I use the emphasis character style as well.
Every paragraph return clears either the italics or the emphasis. When I’m writing short sequences in italics, I have to reapply either the style or the command-i every time I start a new paragraph.
According to the user manual: “It is also possible to select the same style you are creating with the “This Style” option. This will be useful for styles that tend to span more than one paragraph or line, such as code blocks. Since character styles naturally persist from one line to the next, this option is unavailable to them and will be disabled.”
Which I took to mean: character styles persist between paragraphs. But neither italics or emphasis does. And it is hugely distracting for my personal writing process >.<.
Am I doing something wrong? Is there a setting I should have switched on?
Hm I just tested and it is working here—multiple returns do not unset emphasis or italics here. You are probably also applying a paragraph style which doesn’t span lines (Next Style in the paragraph style settings) , if I use a non-spanning style I can reproduce your issue (the green background shows a paragraph style where Next Style is different)
So you must either use “No style” as the base before applying emphasis/italic or a paragraph style in which “Next Style” is the preserved…
I’d set the default to be a paragraph style for the entire document in the project preferences, in which case “Next Style” seemed superfluous >.>.
But adding the paragraph style to “Next” worked, and when that’s done, the emphasis is preserved. So tomorrow’s writing will involve less hair-pulling.
You’re welcome. The recommendation is that you should use no paragraph style by default, as this generally makes the Compile process a bit more flexible…
If ‘no paragraph style’ is the default in a project, but a paragraph style–say NameStyle-- is manually set while composing, the whole document is still going to be styled with NameStyle rather than ‘no paragraph style’. If a style is created and the option of Next Style is chosen, isn’t the only (theoretical) different the very beginning of a chapter/document, when a style has to be manually chosen and applied?
Present difficulty with emphasis aside, how does the compile process than see these two things differently? (Serious question - I never use styles/stylesheets in any other app because I’m a dinosaur. If I’m sent a Word .docx I try not to mangle the styles already embedded.)
The basic idea is that styles should be in addition to the default formatting you set up as default. Everything unstyled (ie in ‘No Style’) is passed through to the compiler transparently: everything styled is seen as an explicit design choice which you want to keep (or which you want to do something special with in compilation).
Say you like writing in green Comic Sans 14pt but you don’t think the publisher wants you to submit the manuscript in that format. If you’ve changed the default ‘no style’ to be comic sans, the compiler will automatically adapt it to Courier 12pt (because it’s just applying the format’s default font etc to your default text format).
But by default the compiler pulls in all the named styles from the project and passes them on intact — so if you applied ‘Body - Comic Sans’ to your standard paragraphs, that’s what it will use and you won’t get to see the format’s basic Courier 12pt. In effect you’ve made your whole document ‘As Is’ as far as the paragraph formatting is concerned.
Of course you can override that in compile, but that’s a manual task which complicates the whole process and there may be areas where there are unwanted effects. Worse, every time you compile your document to another format (Epub, say), which has its own built in default paragraph style, you’re going to have to repeat the process of style allocation in compilation. All that additional complexity is avoided by using ‘No style’ as the default in the editor.
The other main issue is that the very useful ‘Convert > Text to default formatting’ command in the editor works around the concept of ‘unstyled = default formatting’.
There’s a useful section in the manual (S15.5.1) dealing with this if you want any more detail.
If you write linearly and set all your “Next Style” to the same style then yes everything will be that manual style. If you use a project default or apply manually, the compiler will not be able to tell the difference, it only knows what style, not how it was applied. If every paragraph has an assigned paragraph style, then the cascade of applying compile settings is one step more complicated (as brookter more clearly identifies), but it isn’t a major issue, justneeds manual tweaking largely unnecessary for most workflows. If this is a concern you can use “No style” (⌘⌥0) to unset the styles that “leak” everywhere. But honestly for most users I doubt they would write so linearly that this would ever be an issue…
I have always used and strongly advocated for styles, and have thought people who don’t use them consistently in word are insane — and yet I’ve now adapted to using paragraph styles only when they identify something as “different” in Scrivener 3, and use “No Style” as the default. If I can get off my semantically styled high-horse, anyone can
At way too early in the morning, I was playing with compiling - which is the one part of the process that sometimes gives me hives. I now understand what you mean. I’m working on something short now - probably less than 50k words - but am part-way through, so for the next actually novel (or any other project document), I’ll manually set the font/paragraph/etc. in the ‘No Style’ paradigm.
I don’t do very much processing in Scrivener. I did use it for early ebooks (there were tears), but I’m an older (non-power) user who used Scrivener to draft, for my first submission and for the revision submission; I get sent Word docs with line and copy-edits for everything else.
(And the reason I started using Scrivener, which will sound ridiculous to at least one of you, is because I wrote in Word, with a separate file per chapter. My publisher at that time - or the managing editor of DAW- was willing to take emailed word chapters and print them out at their end. My second publisher, however, was not - they wanted 1 manuscript file with all the chapters. So a smart person would have figured out how to merge the chapters, right? But! There was Scrivener 1.x. And I could write one chapter at a time, export one chapter, and also compile at the end. So, I write with 1 document per chapter, no separate scenes, and then compile when done.)
But… I love Scrivener because everything I want from it works, and I want Keith to make a living at it so it will always be available and so I always upgrade the minute a new for-pay release comes out, which is why you get people like me who… don’t use the 30 day trial, etc. And then flail a lot.
And thank you so much for making the transition less panicked!