Applying preset to entire manuscript

Okay, so compiling for paperback. I created a preset for linespacing and font size and saved it. I’d like to apply this formatting to the entire manuscript without having to go folder by folder to do it. Does anyone know how to do this? I tried selecting all the folder, but that didn’t work.



One thing to consider is that the compiler is well suited toward this type of thing. In the Formatting compile pane, you can check off the option to override main text formatting at the top, and then use the mock editor in the lower half of this pane to set up the look of the text. The upper half of the pane controls which parts of the outline will be impacted by the formatting. This is key, a folder can have different font settings than a text file, for instance. So be sure to click on the type of icon that holds the manuscript text (probably standard text files), before setting things up in the editor below. Using this tool, you can write using a comfortable font style in the editor, while publishing to a standard like Times New Roman or Courier.

But, if you do wish to alter the editor text itself, the easiest way to do so would be to set up the format in the Formatting preferences pane, then select all of the components of the draft and use the Documents/Convert/Formatting to Default Text Style menu command. This will also make it so new documents you create will use this style by default.

Presets are generally better for local or specific bits of text that deviate from the norm, like block quotes and such.

Okay. Thank you. I’m going to re read that a few times. lol. Basically, I need to work in 12 point font and double spaced for the ebook editions, so that’s why I write in that. The trade paper edition is when I need to switch to the smaller font and paragraph spacing, so I’m going to try what you’ve suggested.

Thanks so much!

What you are describing is why the compiler is designed the way it is. Especially in today’s publishing world, you often need to produce different looking copies of the material you’ve written, based on different standards and such. The compile lets you ignore these details while you write—they don’t really concern the writing process anyway—and lets you defer the decisions regarding appearance until it is time to actually produce a copy of what you’ve been working on. This way, you can use one set of compile settings to make your e-book and another set entirely for the print manuscript. This is roughly what you would do by designing stylesheets in a word processor. Scrivener just takes a slightly different approach that doesn’t alter the working space with the output requirements, if that makes sense.

What you said made perfect sense, and it worked beautifully. Now here’s the funny part; (if you’re not me right now, that is) I formatted everything in compile and it came out great except for 2 details. For some reason, despite having the same font and line spacing, It’s coming out 30pgs longer than the first time I did it. Also, I was trying to do away with the widows and orphans, but they’re still there. I have three nasty ones that it won’t get rid of. The book looks great except for those two black eyes.

I really appreciate you taking the time to help me with this.


Ramon, glad to hear to worked well for the most part! Actually, in some cases, “the most part” is the best we can expect of Scrivener. While it does have a lot of export capability, sometimes a little polish is needed using a program that has been more specifically designed for document creation. Widows & Orphans are one of these, assuming you are going straight to PDF with the compiler. You may have luck by switching the PDF generator to “Proofing”, rather than “Publishing” in the Print Settings compile pane. It supports a few things like widow & orphan control and end-of-page footnotes that our standard PDF generator does not, but as intimated by what we call it, it has some pretty notable flaws that can make it not worth using for final output. This pane describes the various pros and cons of using each engine.

If neither quite does everything you need, I recommend exporting as an RTF (you’ll find the widow & orphan checkbox for RTF in the Layout compile pane), and then open this RTF in a suitable word processor for final PDF production. OpenOffice, Word, Nisus Writer Pro and Mellel are the best four for doing this on a Mac.

As for the 30-page discrepancy, well in a long enough work adjusting the font size and line spacing can make a significant change in the total page count like that. Changing title formatting, especially if there are a lot of sections, can also bulk up a document quite a bit. It’s hard to say what happened, but you might want to run through those checkboxes in the Formatting pane and make sure nothing is enabled that should not be. For instance if you write chapter notes into your folders, you probably don’t want them exporting their text content.


After going over what you’ve shared, and scrivener for dummies, it’s helped a lot. What I ended up doing was compiling in print instead of pdf, bringing the bottom up from 1 to 1.1 above the footer and re-worded a couple things in the problem paragraphs. This pretty much took care of the widow/orphans. Everything worked perfect…EXCEPT


Basically, I uploaded into createspace and my gutters are a little of. I could actually expand the outside margin and bring in the gutter just a bit, that may actually reduce my page count. Now I just wish scrivener had a gutter and outside margin function (or if it does, label it such) so that this would be easier. I’m just going to have to play around with it again. The manuscript was perfect, too. :confused:

Do you mean offset margins to make space for the binding? If so we do support that. Visit the Page Settings compile option pane, click on the Facing Pages tab and enable “Use facing pages”. Here you can also set up mirrored page numbering and so on, but when you have this checkbox enabled, the Left/Right margins will alternate as well. For example, in our Paperback Novel compile preset (which is designed to work well with CreateSpace), we use 1" left / 0.5" right (which will actually alternate depending upon whether the page is recto/verso).

I’m going to record that so I don’t forget. Yes the margins I struggled with for a while until I got it right. I ended up using something close to that, I think. Everything turned out perfect except the widow/orphan, thing. I couldn’t get the ‘keep with text’ function to work, so I went in and reworded some things and made some minor changes. In the end, I ended up with about three widow/orphaned pages. I had to pick my fight, and that was about a stalemate. Everything else turned out perfect, and without me having to use Word for anything. (thankfully)


I use plenty of formatting presets in my document. Because of that, I usually untick the compiler’s default option to overwrite formatting – I just take care of it directly in the editor. I must, really, or I’d get lost in the various formatting conventions. I need Scrivener to be a WYSIWYG tool, in that respect.

If I modify a preset, I do need to see it immediately applied in the entire document without having to select disparate bits of text and doing it manually.

Is there a way to do this, without touching text that is formatted using different presets?

Thank you!

If you need this, then Scrivener is not the right tool for the job, sorry to say.

As stated in the manual:

To elaborate on that a little, a formatting preset is literally just a stored sequence of formatting commands which can be called upon to format text within their remit. They may optionally not impact certain aspects of the text—for example you may have a preset that just colours the font red but leaves everything else alone. You may have formatted this text with another more comprehensive preset that selected typeface and leading attributes. To which preset would this formatted text owe its allegiance, the original, or the red text one?

Now, this is just my personal opinion, but I don’t understand why anyone would need this in Scrivener. It is a writing platform, not a document creator. There are plenty of good tools for creating and tweaking documents. Why can you not just compile out of Scrivener, apply stylesheets to the final output using one of these document processors, and do your fine tuning to the look and feel from there? Or to put it in practical terms: if you decide you want your block quotes to be 10pt instead of 11pt, I don’t see any reason to even bother with that in Scrivener. Scrivener is where you simply say “this is a block quote”. Just export to your preferred word processor, select all of the 11pt block quotes, assign them to a style and then change the style to 10pt.

Thank you for your answer.

While I understand the concept of marking something as being something, and then applying a stylesheet or ten (the entire philosophy behind XML and XSLT is based on that), I have to confess that, when writing a document where formatting matters, I prefer the WYSIWYG approach.

Gone are the days of Wordstar! Where everything was the same font, bold was white, italic was blue, and the only way to see what you were making was a print preview.

With regards to your analogy, I would advocate the approach of all other editors: only let one piece of text be of one preset at any given time. That way, you simply mark the text as belonging to, say, the “Body” preset and maintaining it in real time should be easy – after all, what’s the editor if not a stylesheet applied in real time to changing content?

Well, I would submit that stylesheets fall within the same category as XML and so forth, they are just a more visual and slightly more consumer-friendly way of approaching the problem. They are still ways of pointing to a block of text and saying, this is that and if that changes, make this follow suit.

And sure, if we had a stylesheet system in place, then I would agree that singular assignment would be the only solution.

The problem is: we don’t. I’m not sure how else to say this, but we don’t have a stylesheet system. :slight_smile: At the end of the day this is all academic because we don’t have a stylesheet system. We can’t do the things you are asking for.

We probably never will have stylesheets in the word processor sense. Understand that for most people, they are trying to get away from all of that complexity while writing. They’ve wound up on this platform because the Words and OpenOffices of the world do not make good creative environments for them, and hugely complex style definition systems are just one part of why that is. That is also why Keith set out to make Scrivener in the first place. That doesn’t mean, however, that we are ignorant of the potential issues people face. We do already have a semantic system in place for those that need that, using the MultiMarkdown system. For a long time that was the only solution, but Scrivener is gradually evolving and acquiring more of the roles that were once exclusively in the domain of this alternate system. This will continue to happen, and it is our intention to do so in a way that does not bring the mind-numbing complexity of stylesheets into the mix. Again, they may be easy for you if you’ve taken the time to learn them, but most people haven’t and have no desire to. For most people presets are simple, easy to use and do exactly all they need to do. We do not want to sacrifice that “just let me get on with writing” attitude toward the UI.

Well that’s fine, I don’t see why you can’t use Scrivener for that, so long as the design is not so stylised that it requires page layout—just switch off the compiler formatting. My only comment was that Scrivener doesn’t have anything for stylesheets, so if you really need to adjust font faces while writing, then it’s not the best tool for the job. This is a tool specifically designed for people for whom this doesn’t matter. Knowing that might help illuminate why there isn’t a stylesheet function.

Keep in mind, you may denigrate it, but there are a lot of writers that would use WordStar or WordPerfect for DOS if they still could. Most writers, as a matter of fact, do not even need basic formatting while they are typing. They feel that all of that junk just gets in the way. Scrivener is one of those tools that was made by and made for people like this. Do we really need to take a tool designed for that type of writer, and turn it into yet another big complicated Word clone? Don’t we already have enough of those on Earth? I hope that doesn’t come across as confrontational—it’s just a little off-putting to have someone saying that your preferred tools and ways of working are inferior and old fashioned. If I sound defensive that is why.

We understand that not everyone thinks that way. Some people prefer to write in a word processor with all the frills and a precise preview of what will come out of the printer while they type. That’s fine! We don’t need to sell Scrivener to everyone. :slight_smile:

Whoa, talk about being defensive! :slight_smile:

I love Scrivener, the only thing I’d need to make it perfect for would be a way for presets to be automatically applied when they’re changed… If I’ve already applied them to a paragraph last month, it stands to reason that automatically applying them to the same paragraph again today should not be all that difficult. Forget about stylesheets. I don’t need stylesheets.

Me, I don’t miss Wordstar, though I completely understand your point. I’m just not the sort of writer who can separate form from content. I’m selling them both together. People who buy my product pay for form and content together. Doing one and then the other is a little hard for me.

I’m certainly not denigrating Scrivener, which has indeed helped my productivity manyfold. It’s just that when I really try to use it as a WYSIWYG editor (which, indeed, it’s not being made for), I bumped into this thing and by the looks of things I’m not the only one.

Thank you for all your assistance!


To reiterate we do have plans for a more dynamic system in the future. What that looks like is still under design, and how extensive it will be is still unknown. What I can say is that we definitely want to avoid the stylesheet tropes like having to assign “body” to everything that isn’t already something else, and having complex palettes, triggers and cascades. All of that stuff is nice for those that want to learn it, to be sure, but it’s all part of why most people avoid it and just use the ribbon to style their text directly. We don’t want our solution to this problem to be more complicated than formatting presets, or even just using the format ruler—while also providing an advancement in workflow for people that need a dynamic system, like yourself. If that is mainly what you want of it, and not all of the arcanum that full stylesheets preset, then I think you will be pleased with what we come up with.

It will be a while though, don’t get your hopes for anything soon. This really is a huge project that requires a lot of careful thought and implementation.

That’s totally understandable, and when I’m creating something like that, I’m in InDesign, Photoshop or Illustrator. When I’m writing the user manual though, I’m using MultiMarkdown as saying “this is a menu label”, “this is keyboard shortcut”. I don’t care what these things look like in the end, I just need to describe the feature and move on. To rephrase my earlier statement, when I said that Scrivener isn’t the right tool for this I didn’t mean to suggest it wasn’t the right tool for you, just not for this particular task.

Glad that Scrivener is overall a boon to your work. :slight_smile:

I sum up this thread as follows:

  1. User employs many different styles in his MSS.
  2. For this purpose he has many presets.
  3. He (apparently) changes his mind frequently as to how each or many of these presets should look.
  4. Thus he would like some way to have a preset change apply to all previously-marked preset paragraphs of that style.
  5. And there is no way Scrivener can do this natively.

However, taking AmberV’s first response, Scrivener does offer a way around this via MultiMarkdown.

Remember that MMD passes through, untouched, all HTML markup. So the workaround is to mark, manually in the text, what sort of preset each paragraph is. A Notes'' paragraph would begin with [less-than]p class="notes"[greater-than] … and a Really Important’’ paragraph would begin with [less-than]p class="reallyimportant’[greater-than] … and so forth.

And you would have to do this with each and every paragraph in general, though there are a couple ways around this:

  1. The standard paragraph does not need any such additional markup
  2. For long passages of a custom paragraph style, you could surround them with a [DIV class=“this style”] and a [/DIV] paragraph.

Beyond this, all the usual rules for creating a MS in MultiMarkdown apply.

– all of which becomes rather tiresome IMO. So the simplest way to approach this in Scrivener, it seems to me, would be either:

  1. Follow the advice to work through Word, LibreOffice or another full-featured word processor to clean up the MS before going on to final output, or

  2. Deciding once and for all, within any given MS, what the format of your many paragraph styles will be, set your presets accordingly – and stick with them to the bitter end (at least so far as this one project and MS are concerned).


Thanks, those were my conclusions precisely. No point using a drill to cut wood. :slight_smile: