Compile overrides some of my style font selection but not others. Why?

Some of my style selections, like Code Block, determine what font will be used in my compiled book. Other styles do not. I have two questions that I was not able to solve after 30 minutes of searching the web and reading the manual. I know I SHOULD have found these answers myself, but please help:

(1) How do I edit a style to change (on or off) whether compile should override the font family choice?
(2) How do I change the default font family that compile is using?

Please note (regarding my question #1) that in the format style command, I have gone to the redefine from selection command and tried selecting both save paragraph style and save all formatting. Neither choice preserves the font.

The rest of this note is just me, lettering off steam, irrelevant to my questions above.
Scrivener is such a wonderful tool to write with, but whenever I am about to do something I rarely do, I know I might as well set a side a whole day for frustration. Will there ever be a scrivener 4? Will its many, many, many features be easier to find?

Here’s a whole 'nother way to let Scrivener frustrate you: Load the manual as a PDF and try to search for something. I tried this today, searching for “style”. OF COURSE there is no master ToC at the beginning of the manual, so the dozens of hits I got for the word style did not make it easy to find the section discussing styles. I had to guess where that section was so that I could find the correct index, and I got it right on the second try.

I know the world has to be like this. Before I retired, I was writing Windows programs. The documentation of Windows functions and the library that enwraps them, and how to use them, is a lot more abstruse than Scrivener. Still…I dream for a future in which it is easier understand how to modify compilations.

If you got this far, thanks for reading.

The Mac Scrivener manual has both a master ToC at the beginning and a detailed ToC in the sidebar that you see in Preview. I use both constantly.

To your specific question, Styles are generally passed through the Compile command unchanged, unless you specifically redefine them. See Section 24.5 in the manual for instructions on how to do this. The default font family can be changed using the setting at the center of the main Compile screen, but Styles that explicitly define a font will not be affected.


Katherine, thanks, you definitely answered my second question, and you’ve helped me to refine my first question. Here’s my issue:

When I compile, I can see a few styles, including “code block”. Code block is a style that, during compile, specifies a font and overrides the overall font selection for the compile. Using the Format Style command, I created a new style that I use to put part of a section in Courier font. During compile, my choice of Courier is overridden, which I do not want. I don’t know if it makes any difference, but please note that I cannot see this style in the compile interface. (I believe the compile interface does not show me any of the format styles I have created.)

I’m sure there is a way to create a style, and apply it while editing, to preserve a choice of font in a section. You referred me to section 24.5, but that is the compile section, where my format style does not seem to appear. What am I missing?

Thanks in advance for your help.

Please note, the mac os manual that I can see by using Scrivener’s HELP menu begins with a 2-page ToC that only lists the big topics. The word “Style” does not appear in this ToC. It does appear n the ToC for the Writing section, many pages later.

The Table of Contents from the Scrivener for Mac manual, version 3.2.2 (no page numbers, but the section numbers help when searching for specific titular items)…

Moderator Note: lengthy post content removed at request of original poster. Please refer down-thread for links to the full text in a downloadable file.

That list is wonderful, thanks. It really helps.

The Styles pane in the Compile format allows you to redefine styles as needed. That’s the one I referred you to. This pane lists exceptions: the Styles that you want the Compile command to change, which is why it may be empty in your project.

What format are you compiling to, and how are you inspecting the resulting file?


Your heart is in the right place, but please consider putting such a long list in an attachment, or directing the OP to the Mac OS Preview application’s sidebar where they can see it for themselves. Dumping the whole thing in this way makes the thread rather difficult to read.


Scrivener manual 3.2.2

Table of contents

Plain text file, suitable for a quick search.

[attachment=0]Scrivener Manual 3.2.2.txt[/attachment]

The sidebar in Preview has its uses, but never found a way to limit searches just to the sidebar itself. A global search for a word like “keyboard” (as a random example) brings up a huge list of entires throughout the entire PDF. This way it is at least possible to search titles only, which—in my experience —helps to hone in on specific targets.

PDFs are user-unfriendly on so many levels. Hope L&L moves away from the PDF format as the medium for its manuals.

Welcome. Plain-text version linked above.

RTF version in a Zip… (the plain-text version mentioned above got deleted during an unsuccessful forum edit).


Please note that I am still hoping for an answer to this question:

How do I create a style that will preserve its font choice in a compile? I might, for example, want to make a few lines of my text look like they came from an old-fashioned typewriter in Courier. Note that when I use the format menu selection to create a style, I see no option for doing this.

Thanks in advance for your help.

In most formats, Styles are preserved by default. Since you’re seeing different behavior, what format are you compiling to, and what are you using to inspect the output file?


That’s odd, you should definitely be seeing two checkboxes that relate to font settings, when creating or redefining a style. They are right below the control where you can select between character or paragraph style. Refer to Figure 15.14, the two checkboxes in the “Formatting” section.

Now granted, the compiler is the ultimate authority on what a style may end up looking like. In this way you could use whatever fonts you wanted while writing, and enforce them as part of the writing environment, but still use a compile format like Manuscript-Courier that forces the issue.

To make sure that is not the problem, go into the compiler, and in the left sidebar double-click on the Format’s name to edit it. In the Styles compile format pane, make sure the style you are trying to use isn’t in the list as an override, or if it is being overridden for a good reason, that at the least its font checkboxes are disabled along the bottom of this pane.

For the most part, this is all meant to work without any fiddling. You make a style, and if you want fonts, you check the boxes, and it compiles the way you set it up. The main exceptions are when using stock style names that are commonly overridden. Hopefully that principle helps explain what is going on. If you use “Block Quote” and then compile with Manuscript-Times, and try to make block quotes use Arial from the editor side of things, yeah you’re going to have a hard time unless you change what makes Manuscript-Times convert everything to TNR 12pt on purpose. So maybe the alternative is to name your style “Quotation” instead, and dodge the assumptions that serve most people well.

[size=100]Off-Topic PDF Rant[/size]

I don’t necessarily agree (obviously), but I also don’t disagree entirely either.

First, and as an aside, while the source is a little out of date (having been held up by the Windows editing process), I would say that by a very large margin, the best approach is to use Scrivener’s documentation in Scrivener. I live in that project, it is very easy to get around in and find stuff, because it must be. I could make it even better for many minds, given time—use keywords and maybe build user-centric collections instead of the editing-centric stuff—but I barely have time to edit it, let alone embark on such a project. It’s something to consider for the next time around maybe: designing a project from the ground-up to be more useful as a reference tool itself, it’s just, well in the heat of it when you’re spending nine, ten hours a day just writing furiously, messing around with keywords you’ll never use isn’t top of the list. :laughing:

But with PDF navigation, generally, I’d say a substantial problem is that most PDF readers default to a less useful thumbnail sidebar rather than showing the ToC. If a PDF has a ToC, it seems more sensible to me to always prefer that view over small thumbnails. The other problem is more specific to this PDF and is design related, with this notion of having a short broad-strokes ToC in the page flow itself. Given that the number one complaint (by a very large margin) about the 3.0 manual is how it is hard to find topics, hopefully that will be reconsidered next time around. The sidebar ToC being more detailed was the answer, but that this constantly comes up is evidence that most people are not aware that such a PDF feature even exists.

Otherwise, format choices are difficult. There are preferences people have, but to say PDF is objectively worse than others and user-unfriendly seems a bit overboard to me. Some for example suggest ePub, but I don’t really understand the appeal. I have yet to meet an ePub reader that exceeds a well-designed PDF reader for reference level reading. Obviously, for laying on a sofa on a Sunday afternoon and reading a novel, I’ll pick up my Kobo. But if I’m programming, or looking up some detail on the software I use, I would very much rather a tool like Skim, over some thinly featured ePub reader that seems more preoccupied with emulating the limitations of paper than creating a solid software-based referencing environment.

The other alternative is online, in a web page. These are usually even less useful than ePub readers, as we now barely have any software at all, but whatever conveniences the documentation itself struggles to bring to bear. Plus, you often have to be online for that, which is a huge downside for how I work.

Then there are OS level help tools—Windows is slightly better on that score, but Apple’s is—bad. Take everything bad about reading documentation in a browser, and then remove 95% of the browser’s features for working with web pages, and then make the window obnoxiously float on top of everything else and finally, only capable of showing one software’s documentation at a time, and you get an answer the neatly underscores a number of things Apple gets wrong about what a professional working environment should look like. Hilariously, you also often have to be online for it to even work, which leads one to wonder why there wasn’t just a URL provided so a proper browser can at least be used. Apple Help is so bad I’ve uninstalled demos if that’s all they offered, and weren’t compelling enough otherwise.

What’s left? man pages? :slight_smile:

I guess I mean to say, there are a lot of flaws with all of the popular approaches to documentation out there. It is easy to drag out significant downsides to any one of them, including PDF, I just didn’t dwell on that because I’m sure you already have them in mind.

For myself, I look for documentation in this order: if the tool is knowledge related, I look for documentation in the software itself. To my mind that is always a really good sign, when the docs are hosted in the software. It means the developers are confident in the software being capable of its intended design, and that they eat their own dog food. Failing that, I look for a downloadable PDF if I get sent to a web page. Failing that, I grumble and set up a wget configuration to batch mirror the web site to my local machine. Now that, in my subjective opinion, is what can be safely referred to as user-unfriendly—especially since most people don’t know what that means, and just live with the downsides of losing 100% of their documentation when going on a trip.