TOC for print book has wrong format

This is a bit weird.

I have a TOC for my print book, with page numbers right justified.

Usually, to update it, I simply select all the sections I want to put in the TOC, do a copy special / Copy as TOC, than in my TOC folder I select the whole TOC and do a paste with matching style. Usually, this updates the content, but keeps my formatting.

This doesn’t seem to work anymore.

If I do a paste with matching style, it deletes my style and inserts an ebook style TOC, without any page number.

If I do a simple paste, it insterts a TOC with page numbers, but the style isn’t kept and the lines are too short for the titles.

Has anything changed re TOC in recent versions? Am I not doing it right?



Any chance to get ANY support on this? Thanks.

This is primarily a user supported forum, though we do try to make the rounds as much as we can. If you want direct support, contact us.

Paste and Match style is going to destroy most of the formatting that goes into making the ToC look right, so I wouldn’t recommend that approach. You probably also don’t need to use a style here, but that’s up to you.

I’d say the best approach would be set the ToC binder item to a type that is formatted “as-is” when compiled, that way you don’t have to worry about the compiler changing the tab stops, indents and other settings in here (presumably that’s why you are using a style—but the problem with styles is that they can only store one indent/tab setting, and a ToC might need more than that).

The only substantial change made recently is that when you paste, you’re asked how wide to make the layout and what amount of indent to use for subsections. That should overall make things more flexible than they were in the past.

Hi Amber,

Thanks for the reply. OK I’ll contact you directly next time, unless you mean that I should still do it now that you have replied…

What I don’t understand is that this used to work absolutely fine. I published that book in 2016, and I’ve updated many times that way. It’s only recently that I found out that something had changed.

I’m not even talking about compiling, I’m talking about the even in the binder. My compile options have always been set to “as is” for my TOC folder. This hasn’t changed.

Keith even made some changes to improve TOC behaviour following a request of mine (see , and these changes have been working fine ever since.

Again, what I’ve always done is copy as TOC, then paste and match style. That used to keep my formatting in the existing TOC.

It looks like whatever changes that was made with the “paste” version and the new indentation broke the way “paste and match style” used to work. Please could you take a look, or suggest a way to achieve what I want with the new implementation?

I simply want the style of my TOC to be kept as it is, and I want longer lines. The default line length is way too short, so half my section titles show up on two lines, which is very ugly.

I don’t want to have to reformat my TOC every time I update it simply because paste overwrites my styles. By the way, it’s not only the line length, paste also replaces the font.

Thank you!

Just to clarify as I’ve tried a compile since, the line length isn’t an issue when compiling, as I select “aligned with right margin” so the compiled lines are as long as they can be. It’s only in the binder that they look shorter, which doesn’t really matter (though I don’t understand this new behaviour).

My main issue is therefore that “paste and match style” doesn’t work anymore. The fonts are different and all the lines are bold when I use this. When I do a simple paste, the font is kept but my TOC formatting is lost.

One of the main reasons why I paste and match style is because I have some titles in bold in the TOC (but they are not bold in the book itself), to emphasize some section.

I don’t want to have to reformat the TOC every single time I update it.

I am a little unclear on what you mean by how a ToC looks in the binder, normally such a thing would be pasted into the main text editor, not the binder. Maybe that is what you mean though.

I have, but without an understanding of where you are coming from, it’s very hard for me to know what you mean. To my eye everything looks to be working precisely as it should. I also don’t understand how any changes to indents would impact Paste and Match Style, since that command strips all indents and every other type of formatting, such as bold.

What you’re describing could just be a matter of how wide your editor is, or if you use Page View or Fixed Width, how narrow the display area is within the editor. It may not have anything to do with formatting, especially if you use Paste and Match Style. But I guess maybe you could be pasting into a formatted block that is too narrow. Have you checked the Ruler in this section to ensure it is how you want?

Well again to clarify what this command does, it strips all formatting which means that the pasted content inherits everything about how it looks from the formatting that exists around the paste point. Paste and Match Style is equivalent to pasting your text into TextEdit with plain-text mode enabled, and then copying and pasting from there into a rich text editor. There is no bold, no fonts, no indents, no line lengths coming in—all that comes in is the alphabetical characters themselves. Any formatting you see comes from what already exists in the editor.

Hopefully that makes more sense. I really don’t understand how you are making a ToC with Paste and Match Style though to be honest. :slight_smile: That command strips the hyperlinks out as well, so all you’d have left is raw text that isn’t connected to anything. It would be less a ToC, and more a simple line by line listing of titles.

Hi Amber.

Yes, when I say the binder, I mean the text editor in the binder, in opposition to compile.

Okay, let’s forget about what I was doing and the way it used to work perfectly.

Let’s try to see how I can achieve what I want:

  1. I copy special to TOC all the titles I want in my TOC.
  2. I paste them in my TOC folder. I keep the defaults to page width and default indent size.
  3. The result is a TOC with each title as a clickable link and a <$p> at the end that shows the correct page number when I compile. Each line is max width on the page when compiled.

I think we agree that this is the correct way to generate a TOC for a PDF/Print interior, correct?

Now, here is what I’d like to be able to do but can’t do:

  1. I’d like to not have the trailing dots between the end of the title and the page number. I can’t find a way to get rid of them in the manual.
  2. I’d like to format some of my titles in bold in the TOC, and keep them in bold when I paste an updated TOC, but I guess that this is not possible
  3. I’d like to keep the font selected for my TOC (typeface, size) when I paste an updated TOC so that I don’t have to reformat everything from scratch.

I’m hoping that at least 1 and 3 are possible. I understand that 2 might be difficult, I think I had to do it manually previously.

As paste and match style doesn’t work at all (wrong format, no link, no <$p>) I have no idea how I managed to achieve the above with previous versions. It’s been a few months and the changes have thrown me.

But let’s forget about how it used to work, and let’s try to see how I can achieve the above with the current version.


Yup! That all sounds right and proper.

There is no way to do that—though that is the kind of thing that would be relatively easy to make optional if Keith were inclined. A checkbox in the paste panel, for example, would be one approach.

Correct, and that would be pretty much impossible to do as the source it is copying from is a list of plain-text fields (binder titles) and underlying document ID numbers—what Scrivener uses internally to know which binder item is which, to create the hyperlinks.

It should be using whatever font is already in the ToC file. Are you not simply selecting the old ToC and pasting over it?

Well that aside, one thing I can think to do is use the Character Style to handle the font and underscore matter. Earlier I said styles wouldn’t work so well, but I was thinking of paragraph styles since you were wanting to change indent (line widths) and such. With a character style you’d only modify the font family and underscore stye, leaving the only task left the one only you can do: apply per-level formatting like bold.

By the way, have you considered leaving this step for the stage after you compile? If you take a look at the ToC in the user manual PDF, I don’t generate that in Scrivener and mess around with indents and settings every single time I compile. You can see I’m using a bold/regular distinction between Part & Chapter level entries as well, along with precise horizontal placement instructions for numeral, title and page number. But I’m using typesetting tools to make that, not Scrivener.

While my precise methods are probably of no interest to you (Markdown → LaTeX), the same principal applies to word processing workflows! Just use “Heading 1”, “Heading 2” style structures where you need ToC entries, and then open the RTF file in Word and insert a ToC using a menu command (or ribbon button or whatever, I don’t know anything about Word :slight_smile: ). You can control how it looks in great detail, and procedurally rather than having to select each line and make it bold, or whatever.

Scrivener’s ToC tool is meant to make your proofing printout more useful as a proofing tool. It’s not meant to substitute for a proper ToC feature or typesetting environment. It seems like much of the friction you are running into is centred around that difference between usage intent and design intent. It doesn’t have a complicated procedural configuration (like bold this level, regular that level, italic 10pt third level) because one isn’t supposed to really be too bothered about how their proof ToC looks.

Yeah I don’t know either! It’s odd because nothing has changed with this feature in quite a long while. The last change in fact was to add the sheet that gives you the width and indent options—and that was going on nine months ago.

Thanks a lot for the detailed reply.

You are correct, a lot of the friction comes from the fact that I plan to use Scrivener to generate the final interior PDF, not just the proof.

I couldn’t have done this with my last book (470 pages, lots of infographs etc), so I exported to .rtf and did the interior design in InDesign, so none of this was really an issue.

But my next book is only 200 page, no infographs, and Scrivener does a VERY good job as handling 99% of what I need it to do to be able to create my interior directly.

This is very useful because it allows to have just one master file (the scrivener project) for ebooks and print, have Scrivener to generate the PDF interiors, and upload them to KDP directly.

I do update/correct my books often and I’m really trying to streamline the workflow, especially for print (ebook is super simple and very efficient, as only Scrivener is involved).

I don’t need a fancy formatting of the TOC, and I don’t mind bolding manually a few chapters headings in the TOC whenever I update it, which isn’t that often.

However, I can’t output these trailing dots, they don’t look professional enough. Maybe if they were underscores (a continuous line) it would work.

So if Keith would kindly consider adding an option when pasting the TOC, so that we could select trailing dots, trailing underscores or nothing, that would be fantastic.

The only showstopper I have apart from this is that when you select a headed section in compile, you can only select the font style for the main header and the text. If there are header2 or header3 styles applied in the text, there is no way to specify their style in the compile section, and the style selected in the text editor isn’t used either.

For example, my main header in the section is centered, but I need the header2 to be left justified, so they are formatted like this in the text editor, but when I compile a random style is applied to header 2 (different font and size) and they appear centered, not in the font I want.

I guess an option would be to select “as is” in the compile options for this section, but that defeats the flexibility of the new compile section styles, which I really like.

Any suggestions?

I understand what you are suggesting re formatting an exported RTF file, but that’s exactly what I want to avoid :slight_smile:.

I don’t think you should assume that Scrivener should only be used to generate proofs, even for print editions. Given that you can select the correct paper size (6" x 9" in my case), that you have a wide variety of formatting and design options, having a single master file (the Scrivener project) for both print and ebook is a very appealing prospect.

I wasted a lot of time with my last book having to maintain two master files: the Scrivener project for ebooks and my exported word file for print editions, and then I had to use my designer to make all the corrections from a word file showing the differences into InDesign. Apart from the cost, it was a logistical nightmare, it was slow and error prone. I decided that I’d do everything I could to avoid that in the future.

So hopefully we’ll get there, given that there are only a few minor things that would prevent this at the moment. :slight_smile:

I think it would be a real USP for Scrivener if you could pull this off. I’m sure I’m not the only one who wishes they could have a single masterfile for all their editions and to be able to generate with Scrivener the final PDFs for both ebook and print interiors. The workflow is so efficient with ebooks that I just want the same with print books :slight_smile:.

If I understand you correctly (and I am a bit fuzzy, since nothing in Scrivener would actually apply a “random” style), you can add “Header #” styles to the compile settings for the inserted heading itself. So in case that’s what you mean, here’s a simple way to achieve a good stylesheet structure in your compile settings:

  1. Starting from RTF and the “Modern” format as an example, with the “Chapter” Layout in use for level one headings, double-click on the preview tile in the middle column of compile overview screen to edit it.
  2. You’ll see the “Chapter One” sample text in the mock editor, click into that to inspect its formatting using the Format Bar. If you click on the Styles button, you’ll see no style is applied to this text.
  3. Select “Heading 1” from the Style dropdown menu in the Format Bar. You shouldn’t see any formatting changes, but now this text will be compiled using “Heading 1” style, making it visible to ToC generators in word processors.

You could go on to do the same for all of the Layouts that generate the different levels of headings in your book. As you can see, we’ve set things up to make converting to that workflow as easy as possible. The compile format has these styles already configured and matched to the raw formatting used by default, so it’s just a matter of applying them.

One thing of note: once you do apply named styles to your Layouts, only adjust their formatting from the central Styles pane. The Layouts will all track that central format automatically, but if you make direct formatting adjustments in the mock editor, it will break the style link automatically.

Well hopefully the above addresses the primary issue here, but to add a little to that point specifically: you can blend the “as-is” concept with more complex Layouts. To continue with the above example, you could create a “Table of Contents” layout pretty easily:

  1. Click on the “Titled Section” Layout in the design interface.
  2. Click the + button to duplicate it, and call it “Pre-formatted Front Matter”.
  3. Do the same trick of setting the “Section Title” to the “Heading 1” style.
  4. Disable the Override text and notes formatting checkbox below the mock editor. Alternatively, click the paintbrush icon to the right of that and make sure both options are ticked (as a ToC may need both).

With the first approach, you’ll need to ensure your ToC font settings are in parity with the global look established in your Section Layouts otherwise. With the second approach you can have the compiler keep the ToC’s fonts uniform, but the special indents and tabs that make it look nice will be retained. And meanwhile the compiler inserts “Table of Contents” as a Heading 1 styled headings in the output, so all you have to do is paste the ToC into the right binder item when it requires an update.

Either of these methods would work for what you want (bold is ignored by formatting override for obvious reasons), so it’s more a matter of preference and what you need. And meanwhile that Layout should be useful for a variety of purposes. With its alignment exclusion, it could handle dedication page, and it could even handle more text-based stuff like a preface.

I mean, it’s not really an assumption, it’s the design scope. :slight_smile: We’ve always said that if Scrivener does everything you need for that phase, then it’s probably good enough (though you’ll always get a more professional looking result using pro tools). But if it doesn’t do stuff you need, it’s good to keep in mind this is a writing tool, not a publication tool. That statement doesn’t negate that one could use it for that purpose, it is rather a way of drawing a line in the sand, and saying everything over this conceptual line here leads to bloat and feature sprawl. You’ve got to draw lines like that all around software to avoid it becoming a monster.

Thanks again for the detailed reply, much appreciated.

[nonsense deleted to save your time]

Sorry please ignore the above. You are correct, there are no random styles in the compiler. For some reason the styles that I had selected in the “styles” panel in the compiler weren’t saved. Now that I have saved them, I can format my “header2” in compile the way I need to, so problem solved :slight_smile:

Thank you for your patience. If you could ask Keith to consider the option of replacing the trailing dots by underscore or nothing when pasting the TOC, I think I’m sorted :slight_smile:

I haven’t seen any new compile option in the latest Scrivener release in relations to the trailing dots issue in the TOC, so I was wondering:

  1. Have you forwarded to Keith the minor feature request of having the option to remove the trailing dots in the TOC, so that we can actually use Scrivener to create the print book interior? Any chance to see this implemented?
  2. Is there any way to replace the trailing dots using a compile replace option? I was able to replace the tab characters with nothing for the ebook TOC, so I was wondering if maybe it would be possible to do a replace in compile to replace the trailing dots by trailing spaces.


Sorry, I might have misunderstood you before. I didn’t realise you simply wanted the lead lines entirely removed. You can do that easily enough after pasting, by selecting the whole thing and toggling underscore off (you’ll need to do it twice as the first time switches them to solid scores).

Thanks for the quick reply. :slight_smile:

Where is the underscore off option?

I tried right clicking after selection, and looking in the most likely menus, but I couldn’t find it.

Found it: I selected underline (in format / font). It was already set to none, but I clicked that and all the dots disappeared.

That was easy :slight_smile:

Thanks again.