Easily remove unwanted ToC entry from auto-generate HTML ToC: add "Include in ToC" tick box to text/folder element.

Scrivener Wish List
1

Every part of creating and formatting my ebook was something I could figure out. I got the book looking exactly how I wanted. I was very happy with what I could do. Much appreciated.

Generating a ToC manually has been pretty painful. I still can’t get it done, and I’m going on 40 hours trying to figure it out. Maybe it’s a bug or maybe I have some setting screwed up, I’m not sure. I’ve posted already and am waiting for additional help (thank you!).

Either way, if there was an option to untick a “Include in ToC” checkbox (ticked by default), then it might remove or at least significantly reduce the need to create a manual ToC for anyone in my situation.

I’ve used the section breaks to create separate sections for images. Otherwise the images tend to get separated from the captions frequently. I’d rather just have a single image on a “page” (section) - and increase the chance of the caption staying with it, than having the image float around with or without its caption.

(BTW, if there’s a better approach to handling images, I’m open - I haven’t found another strategy that gets closer to the outcome I’d like.)

I’m suggesting adding a tick box to each text or folder element rather than at the section formatting level. It may make more sense with how the program functions/is programmed to add it to the section formatting.

Absent that understanding (as a user), am suggesting the option be placed at text/folder level because there may be more than one section type that a user wants removed from auto-generated HTML.

The hassle of creating another section type to format it so it is not included in the auto-generated HTML–when all the other elements in that formatting are the same as another section–seems unnecessary.

If this last part doesn’t make sense, will be happy to clarify if you’re considering the adoption of this wishlist item :slight_smile:

2

Glad to hear you managed to get most everything done with the available tools! The following depends upon modern approaches, with KF8 and ePub3 source—I’m not sure if the techniques will even work in older formats, and may even invalide them if the CSS codes are not recognised.

Have you tried using the CSS controls for managing page breaks, both for suppression between elements, and to cause them to be inserted before elements? I would say in most cases that forcing the issue with structure and hoping ePub readers display that structural approach the way you want isn’t going to be a solid approach, particularly if the reader doesn’t even use a page break in the first place for section breaks, or uses section breaks for something you might not be anticipating, like chapter skipping navigation or overview navigation tools.

Although written for a specific method of production in Scrivener you likely are not using (Pandoc Markdown to ePub conversion), this forum post goes over some techniques for handling layout as formatting (as opposed to structure as layout).

As in most things that involve layout, CSS is the best approach for doing so. And the best way to figure out how to employ CSS to achieve a look you want is to get a feel for the HTML Scrivener produces itself. This is easily done, and with a result that can be loaded into your preferred HTML/CSS editor (although if prefer editing epubs directly with an editor like Calibre’s or Sigil, feel free to take that route instead):

  1. Compile your project, setting the Save source files in a folder with exported ePub file setting.
  2. Navigate into the compile folder, drilling down into the source/bookname/OPS subfolder, and open one of the section files that contains an image.

You should see something like the following, if you see something different, my specific strategy here may not work, so you’ll need to adapt it acccordingly:

<figure>
    <img src="images/testing.png" alt="This is the caption" id="testing" style="height:111px;width:110px;" />
    <figcaption>This is the caption</figcaption>
</figure>

So there are a few different approaches here that we could employ:

  • Ultimately we want captions to stick with images if at all possible.
  • Failing that, we want images to cut to a new page so that the above happens naturally.

For the first goal, we can see that the image comes within a figure element, which contains both the image and the caption. So one potential approach is this CSS:

figure { page-break-inside: avoid; }

This is kind of like the “Keep With Next” code in the word processing world, but it is a block level directive instead of per paragraph. To test, put that at the top of the ebook’s CSS file (in source/OPS/css/stylesheet.css), save it, and run the “make-epub” script in the source folder. Test the .epub file that will be created into the source folder (the one at the same level that was compiled by Scrivener won’t be updated by this script). In my testing, this method works in iBooks and Adobe Digital Editions and Kindle for Mac (so probably other modern Kindle viewers & devices as well). But if in your testing it does not work well everyone, you can try adding a page break instead:

figure { page-break-before: always; }

In case you are unaware of where to put this code, edit your compile Format, and in the CSS pane you can set it to use custom CSS (it does by default, and provides some stuff based on your styles and other option choices). You can paste either of these directives into the left side and compile another test to make sure it all works the same as the source folder test.

3

Use the <figure/> element to keep the two together, as @AmberV posted before.

Use the Sigil ebook Editor software to remove unwanted ToC items using checkboxes.
In the Sigil Tools menu are Options to generate and edit the ToC.

Hope this Helps

4

Still in Sigil, you can directly remove elements of your ebook from the TOC that is internal to the ereader.
By that I mean the TOC that is not appearing as a list of links to sections at the beginning or end of your book, but rather the one that ends up in the menu of the ereader.

image
image835×601 62.1 KB

You just delete from this list what you don’t want to be part of it.

5

To get back to the original question (which was posted four years ago, it’s worth noting), what section breaks were being used for here is not best practices. If one wants figures and captions on their own page, then that is a matter for CSS to handle, not inserting navigational points into the ebook that you then later have to hack out with Sigil (or spend a lot of time managing a custom ToC page in Scrivener). There is a reason that is a clunky and annoying way of working: it’s working against the grain of the technology.

And if the only reason you’re putting figures on a full page is to avoid breaking captions between screen refreshes, that is also a matter for CSS.

It’s also worth noting that there is intended design for withdrawing a Section Layout from the ToC as a high level decision. So one could create a “Figure” layout that generated sections that were invisible to the ToC in output. That feature has not been added yet to Windows, but once it is, there would be very little reason to go about manually editing the ToC like this after compiling.

Still, that’s not the best way to handle the question of: how do I make this one element a full page element purely for display preferences. In an ebook format I designed recently, I don’t even cut chapters into physical sections. Rather each part is one section, and chapters are contained within the part HTML file. One wouldn’t know that from the output though, because I’m using CSS to control the page flow.