manual Table of Contents broken for docx Compile

[Mac m1 Big Sur, Scrivener 3.2.2]

The project compiles perfectly for PDF, but page numbers are broken in the docx on Mac and Windows. I’ll post in the Windows forum separately.

[attachment=0]Mac pdf.png[/attachment]

[attachment=1]Mac docx.png[/attachment]

Question marks in a word processor usually mean the fields need to be recalculated. Have you done at least a print preview, which is usually enough to regenerate page token fields?

How do I do a print preview in Word?

I have no idea! Searching the web, it seems like ⌘P ought to be enough?

Physically printing pages 2 to 4 didn’t fix it.

On Word on Windows, F9 is the key to Update Field for all selected fields, so you usually do a Ctrl-A to select all, then F9. I suspect the combo will be fairly close in Word for Mac, assuming you’re on a relatively recent version (2013 or later).

I have Word on the Mac, not Windows, and F9 does nothing. Ditto for FN-F9, Ctrl-F9, and everything else F9. SOMETHING I did put “repeat update fields” in the Help box as if I had managed to execute it … but the ToC didn’t improve any.

I do have a new oddity in the Footer of every page, on the other hand, but Alt-F9 dismisses it. One of my attempts at updating fields revealed them.


Okay, F9 is the correct key in Word for Mac, but it does nothing to the ToC. That’s because the ToC entries are not links to chapters in the Word document. They’re links to documents in the project. Such a thing clearly cannot resolve to page numbers.

⌥F9 reveals codes, and here they are:


The problem occurs in Compiles from the Mac, not just form Windows, but in the Mac documents ⌥F9 doesn’t reveal hyperlinks or any other field codes in the ToC (only in Footer page numbers).

Yeah, that doesn’t look right at all. You shouldn’t have Scriv hyperlinks in the compiled document.

I certainly should not. I’m surprised the Mac and Windows versions have the same bug … though expressed a little differently.

In the settings tab (gear icon) of the main Compile screen, have you checked the option to “Convert document links to link back to Scrivener?”

If so, uncheck it. That option facilitates editing for people who work back and forth between Scrivener and Word, but obviously isn’t what you want for a ToC.


It isn’t checked in Windows, and it isn’t checked on the Mac.

If someone wanted page numbers AND a few Scrivener links they’d be SOL either way, I think. It’s an all-or-nothing checkbox.

In case it matters, I think I had a couple things switched around in my comments. I see “?” (no fields) in the Mac export and “XXX” revealing to Scrivener links in the Windows export.

Would it be possible for us to take a look at the project? This probably isn’t a common problem – we’d have heard before now – but it’s worth digging into in more detail.


Sure, no problem. Note I’ve reported another bug (Windows only) that conceivably could be related even though this is a Mac and Windows problem.

In the chapter suffix I have {<$label>}, which resolves to an image. That works in the chapter headers on both platforms and works in a PDF table of contents on the Mac but not on Windows.

That’s broken all right.

Could you open a support ticket with this project, please? I’d do it myself, but if you do it it’s easier to keep you in the loop as we sort it out.


WIll do. Thanks.

I think not a lot of people do a manual table of contents, and even fewer do the compile replacement trick with <$img> resulting in the prefix or suffix.

Don’t have Word.

The ToC in the docx fails when opened in Pages because there is no style (other than “body” used throughout) to create a ToC from.

Assigning a style to the chapter headings in Scrivener and compiling to docx allows Pages to create a ToC. See image attached: the front-matter items are missing as I only used this as a proof of concept on the chapter titles. The style would just need to be applied to the front-matter items as well.

Would the same approach work for Word?

Good luck with the book.