Searching through previous posts told me a lot about using styles to create a table of contents, but nothing about styling a table of contents. By this I mean increasing the font size, adding color or perhaps other options to distinguish between various semantic levels in the ToC.
Perhaps it’s not fair to burden Scrivener with this. But when I exported to Word and selected a new style for the ToC, the Scrivener-generated ToC disappeared. Trying to update the new style threw an error message: “There is no Table of Contents.” I don’t want to go down a Word rabbit hole as well.
I’m not sure how you generated the TOC in Scrivener, but from recollection it is simply text generated from the contents in the binder. Probably best to read first about TOC generation in Scrivener in the “Scrivener Manual” rather than rely on posts here.
Also, keep in mind that in Microsoft Word, TOC’s are actually Word fields which are created normally by taking the page numbers of the text marked with Heading styles. I recall there are other ways, but after many years I no longer have a Word license to check for you. Microsoft has a short explanation at Insert a table of contents - Microsoft Support
I am not at all sure that Scrivener puts a Word TOC in place for the TOC it generates when it creates a compiled DOCX file. Others can comment or you can look.
Certainly this only partially useful, but a start.
It’s actually somewhat mysterious to me, perhaps someone could explain.
The ToC didn’t touch the Binder at all (I’m aware of the “Copy Special as ToC” and then pasting that in the text.
Here, I wrote headings in Markdown syntax and compiled with the settings as shown in the following:
These settings give me almost what I need; the trick here is that there is no Markdown setting for “Volume” or “Book” so I have to make these stand out in the ToC. I’m already using Title (#), Part (##), Chapter (###) and Article (####). Maybe Title could substitute for “Volume,” but I have to be careful as the text cannot be altered unless there is an obvious error.
You can always just add the Part <$R> bit to the title prefix, as you normally would. That’s what I did when I created a Pandoc ebook format a while back. Title prefixes change the text of the title, so anywhere that title would be printed (such as the ToC), that is how it would appear. Markdown has no formalisation of “Parts” and “Chapters” because these constructs are mostly cosmetic when you think about it. They vary in how they are presented (pure formatting) and how we talk about them (text), but other than that there is no such thing as a “chapter” in the ePub specification. Scrivener doesn’t have these things either, it’s all just words used to describe things.
As for the formatting of the ToC itself, while these instructions are for Scrivener’s generator, the basic concept applies since both Pandoc and Scrivener generate a standard navigation table. You should be able to copy that CSS and tweak it how you want it to look. The main difference is that it would be placed into the Pandoc Options compile format pane, rather than a dedicated CSS pane, in the Format Designer window.
One thing to be aware of though is that when you leave the CSS blank (as it is by default, for this very reason), Pandoc generates some prefab styling for the ebook. So for the most consistent results you would want to open up the .epub in an ePub editor and copy and paste the prefab CSS into your compile settings, and then add whatever additional CSS you want for the ToC.
Of course if you do not want any of that and wish to design it yourself from the ground up, you can skip the step of copying the prefab CSS out of Sigil or whatever. I do mean ground up though—an ebook without any CSS is going to look very vanilla.
Here is a how-to on best practices for manipulating text flow on the screen. I have no idea what a “horizontal rule above a page break character” means in terms of Markdown conversion to ePub. That doesn’t sound like a clean solution to me, more like the proverbial broken watch showing the right time.
As to the rest, I don’t really know. I can’t explain why 1,2,3,4 comes outs as 3,1,2,4 when you compile. As always I recommend looking at what Scrivener actually creates, by compiling to .md and opening that in a text editor. That sounds to me like the topic of another thread though—probably a bug report if you can demonstrate how to compile the incorrect order without settings design to do that on purpose (Collections as compile group).
