Check out the 915 page Scrivener manual and its ToC. It was written in Scrivener, after all. You can download the manual as a Scrivener project, if you don’t believe it.
This is leaving out some significant information that I strongly doubt the OP is aware of. Most importantly to the discussion:
- That Scrivener almost has nothing to do with the actual construction of the user manual as a PDF. That project makes use of the LaTeX typesetting engine to do almost everything mechanical that you see being done, including the construction of the ToC, and the much more detailed “mini-tocs” that appear after major chapter breaks, as well as its ability to create cross-references to any isolated piece of text, like figures in the middle of a block of text (something Scrivener cannot do by itself without spamming section breaks and hyperlink bookmarks everywhere, and necessitating chopping up the outline by content rather than by concept).
- Although it is not employed frequently, and by and large the outline structure of that project does drive the heading hierarchy, I can and do insert heading markup in the content area itself. I am not limited by structure to produce a functional heading hierarchy that can appear in ToCs, and can seamlessly blend what is generated by the compiler with what I type into the editor. That is not a capability that is limited only to those using markup and LaTeX, however.
- An implication in all of this (particulars of which software one uses in post aside) is that Scrivener isn’t the best place to be putting together the mechanics of a book. It is very limited for doing so, and unless one never needs to go beyond those limitations, there is no good solid reason for trying to constrain yourself to them. There are far better solutions outside of Scrivener, and arguably the compiler is designed to faciliate a seamless transition to them, moreso than it is attempting to replace them.
ToC Basics for Word Processing
If you already know how to make a ToC in a word processor, you can probably skim right past this and into the practical application stuff below.
So setting aside the technical details of how the manual differs from your average project with font styles and so forth driving appearance directly, there are a few key things to be aware of when it comes to generating a table of contents. These are by and large basic fundamentals for most (if not all) desktop publishing tools and word processors (which again, Scrivener is designed to aid seamless transition into):
-
Functional structural headings are a combination of stylesheet application and the styles themselves declaring themselves as being part of the document outline.
You don’t ordinarily need to mess with detailed settings, as most document designs will include a hierarchical heading structure in its stylesheet—typically indicated by “Heading 1”, “Heading 2”, “Heading 3” and so on. Scrivener is no different.
-
A ToC is a construct that is inserted anywhere into the document which uses, as its data source for constructing itself, the overall use of hierarchical headings throughout the text.
-
In more heavy-duty design environments all of the above is deeply customisable. In Scrivener you have to follow a simple convention, you must have styled headings using the naming scheme described above. It will look for this naming convention and build the outline settings into the stylesheet for you.
Thus in simple terms, to have a document we can add a functional ToC to, our only requirement is to have styled text throughout the document that is indicated as one of these “Heading n” type styles. Most ToC settings will indent the ToC entries based upon that hierarchy, and generate formatting for each line, including dotted lines connecting to the page number, or whatever else one wants.
So long as the final result is hierarchically coherent, it doesn’t matter where the styled text comes from. By coherent, I mean you don’t have Heading 4 following a Heading 2. The heading usage must correlate to logical depth, step by step.
Applied to Scrivener: given that basic requirement, and how all of this works, it does not matter how you get these headings into the output. They can come from the compile format’s Section Layouts, which are applied to outline structure in the Draft folder, and they can also come from styled text in the editor itself, or even exclusively, where the compile is doing extremely little and one is apply the “as-is” layout to everything.
Application of Styles in Scrivener
That is a bit of theory and background, so here are some practical tips:
- Linking to Scrivener’s “no style” default to Word’s “normal” style.: this basic introduction mainly covers how to get “Normal” or “Body” styles applied to body text, but that is a good convention you should consider doing, and the principles here also apply to how you would apply “Heading 1” to a major section heading, and so forth.
- compiling - sections, page breaks, styles: now this post goes more directly into applying stylesheet headings to a document for the primary purpose of generating a ToC, and includes a sample project wired up and ready to be finalised in a word processor.
- How to add TOC to: just another checklist and sample document describing compile heading setup.
A Hybrid Approach of Compiler and Editor Headings
There aren’t as many existing discussions out there for blending that approach with headings in the editor as well, but that’s probably because it’s a fairly simple concept. Let’s say you have your major sections in the binder—perhaps chapter-level constructs, with “Heading 1” being applied to those headings by the compiler. Maybe you also break things down to level two, to the Section level, and have the compiler styling those smaller headings with “Heading 2”.
So given that framework, any headings you create in the editor, within those Section level documents will be “below” that level, or Heading 3, as Subsections. If there are headings in between those, in your text, they would be below that, using Heading 4, or what you’d think of as Subsubsections.
That leaves one final point: any headings you don’t want in the ToC should not use the “Heading n” naming convention. That’s it. Call it whatever you need (like “Subsubsection”).
One last thing pointing out is a feature in the Styles compile format design window:
- Open
File ▸ Compile..., and double-click on the compile format you are using, in the left sidebar, to edit it. - In the Styles pane, take note of the Override Name field. With this, you can take a style you’ve been using in the editor (like “Subsubsection”) and rename it on the fly to “Heading 4”.
Now consider the implications of that in terms of flexible project design. If your styles in the writing environment are pragmatically named, like “Chapter”, “Section” and “Subsection”, then by themselves they won’t actually be useful for generating a ToC. But, that doesn’t matter because we can use this Styles pane to rename them to “Heading 1”, “Heading 2” and so forth, as we require.
The implication is that we can drive the depth of the ToC purely from our compile settings. We don’t have a duct-tape and baling wire approach of changing styles names in the writing environment to suit the output requirements.
At this point in your project, that may be of lesser importance since you are nearing the end of using Scrivener. But it’s something to consider for the future. Styles, like almost everything in Scrivener, can be used in a writing-centric fashion, without having to conform oneself to the mechanical practicalities of output.