Formatting TOC

Scrivener Scrivener for macOS
1

Hi,

I’m having some issues formatting a table of contents for an ebook. I have it set up as a structured link list, but I would like there to be blank lines between the front and back matter and the main text. So, e.g.:

Front matter 1
Front matter 2

Main text

End matter 1
End matter 2

But every time I put in blank lines, the compile process strips them out. I’ve tried everything I can think of, but I can’t seem to find a way.

Would anyone be able to advise, please?

Thanks,

Gareth.

2

This isn’t something you would do with formatting in the editor—it’s really better to think of the contents link list as just that, a list of links, one per line, that will be used to construct the internal navigation structure of the ebook—because that is much more like what they will end up as in the book, as opposed to some kind of formatted page.

Here is an example what that is going to look like in the contents.xhtml file (indented for clarity):

<nav epub:type="toc" id="toc">
    <h1 class="heading-1" id="doc2">Contents</h1>
    
    <ol>
        <li><a href="body1.xhtml">Chapter One - Red Book</a></li>
        <li><a href="body1.xhtml#doc4">scene a</a></li>
        <li><a href="body1.xhtml#doc5">scene b</a></li>
        <li><a href="body2.xhtml">Chapter Two - Black Book</a></li>
        <li><a href="body2.xhtml#doc7">scene c</a></li>
        <li><a href="body2.xhtml#doc8">scene d</a></li>
    </ol>
</nav>

You could, if this were the very end of the editing process, copy and paste the result out of the source and into Scrivener, setting the block to a style named “Raw HTML Block” (we have a built-in style for the Ebook compile format that will, when used, pass what you type in straight through to the output). Naturally if you so much as add a preface or shuffle a chapter, it’ll have to be regenerated though, since the internal files are dynamically generated and numbered.

But, with that approach, you could do something like this in the editor:

<nav epub:type="toc" id="toc">
<h1 class="heading-1" id="doc2">Contents</h1>
    
<ol>
<li><a href="body1.xhtml">Chapter One - Red Book</a></li>
<li><a href="body1.xhtml#doc4">scene a</a></li>
<li><a href="body1.xhtml#doc5">scene b</a></li>
<li class="toc-separator"><a href="body2.xhtml">Chapter Two - Black Book</a></li>
<li><a href="body2.xhtml#doc7">scene c</a></li>
<li><a href="body2.xhtml#doc8">scene d</a></li>
</ol>
</nav>

So now you have a classed <li> element in there that you can visually accentuate with CSS. Dropping something like the following into your compile format’s CSS pane would add a single line of space above that line:

.toc-separator { margin-top: 1em; }

This technique has a lot of flexibility, naturally. You could indent hierarchical entries, change font sizes, colours, etc. For best results, stick with using classes on the given elements though, the rules for what go into the element are fairly strict, but ebook readers won’t care how you modify the visual presentation of the list.

Attached below you will find a working demonstration of the concept to play with.

3

Hi Amber,

Thank you so much for your detailed response. I’ll investigate what you suggest, as that will provide more options.

However, I did actually find a workaround eventually. Among the separators options in the TOC section of the compile I unchecked “ignore blank lines using styles” and then as a custom blank line separator I put a return (ALT + Enter on Mac). And this seemed to work. I was hoping there might be a code or tag for that, (like
in html) but I couldn’t find one.

Another workaround I’ve found that works is to add an image as a custom separator, using a transparent PNG or GIF as a spacer. Though this isn’t ideal.

Thanks!

Gareth.

4

OK, it seems my workarounds messed up the ebook index, so I’ll go with yours!

I’ve got it to work by compiling the book, then editing the HTML in Calibre, which is quite simple, and has a live WYSIWYG. Can’t get it to export the raw HTML sytle so that it compiles properly, though (it just displays the HTML code in the ebook).

5

Yeah, I was going to say, definitely run validity checks when trying stuff that inserts actual elements into the HTML!

I noticed, when I was playing around with it, that it seems to be incorrectly parsing tabs as a request for verbatim text. I was getting 

… wrapped around the block. If I removed all prefix whitespace from the sample so every line started with an element, then it worked fine.


This is probably similar to a bug we spotted recently, where headings beginning in 1. 2. 3. numbering format end up being interpreted as a Markdown list by the conversion engine (which uses MultiMarkdown to generate the HTML5 output). Prefixing whitespace is Markdown-speak for “make this a code block”.
6

Ah, I see - so remove white space and it should work. Great. Well, I have two methods now that work, so I’m good to go!

Thanks once again - and have a good Xmas/holiday!

Best wishes,

Gareth.