Problem Generating Toc

[DKCrotty]

I have just downloaded Sigil a few days ago, so its the latest release for Windows (64bit). I had issues, but finally got I all the HTML the way I wanted it. Then I noticed that the TOC was out of whack. It had lost its way when I deleted some pages. It seems like everything slid up, now the last few entries just give errors. SO I tried generating a new one.

No Luck at all. The generate toc window pops up,, but
There are no entries.
Clicking on either left right buttons do nothing, but since nothing is there, that may be right
Show Toc items Only does nothing, again, nothing there
The dropdown has only one entry Select Headings to include
Click ok and you end up with empty Toc .. so it did nothing.

There was one generated before and worked fine till I deleted some pages.
Its probably a new user error, but I cant find a way get it to work.

******2
Rather that open a ticket .. I want to add one more thing.
I spent at least a couple of trying to get to work. I put an image in and am making the Sigil window smaller expecting the image to shrink. Did a few things and it worked. Then it wouldn't. etc. I finally figured out.... if the Find and replace window is open, it will not resize smaller than that window. Close it and it works. So, it may be something you want to address. I doubt many people would have noticed, but I have a talent for stumbling on odd issues.

[Toxaris]

You might want to consider using codeview instead of bookview, just an advice. It will give you much more control.

There is a menu option Generate TOC. That should get you on its way, as long as your TOC entries are specified as headers.

Also, you probably need a ncx TOC and not an HTML TOC.

[Turtle91]

Hello,
What Toxaris said is key: "...as long as your TOC entries are specified as headers."

You must use <h1> - <h6> tags around the items you want to show up in the auto-generated TOC.

eg.
<h1>Tile of the Book</h1>
<h2>Part 1</h2>
<h3>Chapter 1</h3>
...

etc...

[DKCrotty]

Hum.

Well, I thought there was some Sigil magic or something going on. The headers were defined in something another way, but were working until I did that generate TOC.

Thanks

[DiapDealer]

There's only one way to define headers, and that's with "h" tags. Generating a toc automatically is always risky if there's a prexisting one. Sigil will replace the existing one (working or otherwise) with one it knows how to build--and that's one built from the existing h tag hierarchy. So if you auto-generate with no h tags (or some missing h tags), the generated toc will be empty (or incomplete).

[Notjohn]

DK, the generate TOC sub-tool is the greatest thing going, but as posted, it depends on your having set up a hierarchy of headings using <h1> and so on, down to <h4> in some instances. The tool then allows you to include all or or only some of them. And note that this tool creates only the NCX or virtual TOC, not the html or actual TOC in the front of the book.

For the latter, you can use Create Html Table of Contents, but of course you must use the same hierarchical headings. Personally, I prefer my own layout, so I write this in advance. Sigil changes the links as I break the book into individual chapters and sections.

If you have used paragraph styles for your headings, just do a search & replace. And ensure that you have the heading styles defined in your style sheet.

Tools > Table of Contents IMHO is one of Sigil's greatest features.

There's an (outdated) Sigil user's manual that I can no longer seem to locate online. This appears to be it in PDF form: http://peterloveland.com/development...2.0-Manual.pdf

And here is the downloadable epub: https://github.com/Sigil-Ebook/Sigil...ide_0_7_2.epub

[DiapDealer]

If you don't use header tags, you can also build the ncx manually using "Edit ToC". Just define the individual entries and link them to any xhtml chapter or id/anchor you like.

[slowsmile]

The other way of generating an epub TOC is by using Calibre. Just load your epub into Calibre, right click on the ebook image and choose Edit Book.

A nice interface will come up which actually allows you to choose the individual pages for your TOC. Using this method, there is no need to mark your epub main headings using html heading tags. Just click on the 'T' button and pick and choose your own pages for the TOC, then save it back to your epub and export it to your Desktop and your done. I'm not even going to describe how to use Calibre's TOC editor because it's so easy.

[KevinH]

You do understand the purpose of semantic tags like h1-h6 in html markup, right? You can of course use CSS to make the headings look virtually any way you want, but using the proper heading tags allows automated reading system to auto-detect structure for those who need accessibility help.

KevinH

[Hitch]

Originally Posted by KevinH

You do understand the purpose of semantic tags like h1-h6 in html markup, right? You can of course use CSS to make the headings look virtually any way you want, but using the proper heading tags allows automated reading system to auto-detect structure for those who need accessibility help.

KevinH

I've seen a lot of disdain about structure and heading classes recently, as I toodle along on the Net, visiting various forums. Those people, for example, who are having issues in the LITB at Amazon are being told to change their heading classes into paragraph classes, for some oddball reason (by civilian posters at the forums, mind you, not support personnel or professionals).

One just cannot seem to explain WHY structure matters to folks. It's just...I dunno the problem, but my inability to explain the importance of doing something correctly, over simply solving one quick problem by doing that same thing improperly, frustrates the hell out of me. Falls entirely on deaf ears. It's like trying to explain why a hand-coded book is different or better than one made automagically. If they can't SEE it, fuhgeddaboudit.

Hitch

[JSWolf]

Most people do not care about the underlying code. All they care about is how it look on screen.

Me,I care about the code because if the code is a real mess (I'm looking at you Phoenix Pick) then it's not as easy to make changes. Yes, I do make changes because publishers think they know how to format when really, they don't. They do the same sort of stupid shit that needs fixing all the time.

[Hitch]

Originally Posted by JSWolf

Most people do not care about the underlying code. All they care about is how it look on screen.

You are preaching to the choir, Wolfie, mon sweet. We all know it is so, and I certainly know it very, very well. I have had to suppress my inner b***h, when I am now seeing all the crying about how the new LITB is "wrecking perfectly good books" over at Amazon. My little imaginary Schnauzer, Schadenfreudie, has been barking about those, naughty thing that she is. After all...that's now displaying what the books really look like--when the HTML isn't being suppressed by, tamped on, and conformed by, Amazon. (Down, Schade! Down! Naughty doggie...) As, finally, how the book looks in the inside DOES get seen.

Me,I care about the code because if the code is a real mess (I'm looking at you Phoenix Pick) then it's not as easy to make changes. Yes, I do make changes because publishers think they know how to format when really, they don't. They do the same sort of stupid shit that needs fixing all the time.

Well, we all know that you would be one seriously tough taskmaster, Wolfie. I doubt that there is anyone alive on this forum who wouldn't know that. :-)

Hitch

[slowsmile]

@Kevin...It's certainly true enough what you say if you are talking about Sigil only -- because the only way that you can insert a TOC and create the relevant and associated XML structure in Sigil is by formatting and marking all TOC headers with h1, h2, h3 etc. But this is not the only way to create a TOC and xml structure in an epub.

You certainly don't have to format headers with html heading styles with certain other apps like Scrivener. Scrivener will generally output all text and headers with a simple indexed CSS text style name like scrivener15. There are no html header definitions (no h1,h2,h3 defs) in the scriv-generated css. The Scrivener-generated CSS doesn't even distinguish between headers, spans or para styling. Scrivener can do this because, on export to epub, it always creates a toc and xml structure using a different method that is entirely based upon the scriv Binder structure and the pre-compiler Contents settings.

But why would anyone want to avoid html heading styles in their epub? Because using pre-defined html heading styles in your epub can and will cause strange header spacing problems on conversion to Kindle within the Look Inside version. This problem is well known on forums like the KDP Forum -- lots of indie authors complaining about the Look Inside header spacing problems there. These header spacing problems -- as well as Look Inside text align and text indent issues -- are all caused by Kindle overrides(via cascading stylesheets) overriding your styling within the CSSwithin the Look Inside version. So that's really why it is advisable to use simple named para styles for all your headers for Kindle conversions because the Kindle overrides will not be able touch or change the spacing attributes on your para styles in the Look Inside html version. Lots of mainstream publishers are now also adopting this same formatting tactic in order to particularly avoid these header spacing problems in Kindle's Look Inside. All you have to do to see this true is to download a Kindle sample from a publisher's gallery and back-engineer their Kindle ebook to an epub using the KindleImport plugin for Sigil and do it that way. Try Polgarus Studio(Hugh Howey uses this publisher) or eBook Pioneers. These well-known publishers do not use html headers at all in their ebooks.

And please don't get me wrong, I really love Sigil like no other app. IMHI it's simply the best epub app out there bar none. I always use it, in the final stage, to fix errors and to put on the final touches to my epub styling.

[DiapDealer]

Originally Posted by slowsmile

@Kevin...It's certainly true enough what you say if you are talking about Sigil only -- because the only way that you can insert and TOC and create the relevant and associated XML structure in Sigil is by formatting and marking all TOC headers with h1, h2, h3 etc. But this is not the only way to create a TOC and xml structure in an epub.

You DO know that you can create and edit the ncx (or nav in an EPUB3) using Sigil's TOC editor, right? The proper header structure is only necessary if you want to generate the NCX (or nav) automatically. But just like calibre, there's a ToC editor you can use in Sigil.

The Sigil ToC editor may not bring up a file dialog to allow you to directly choose which html file you want the chapter entry to link to (like calibre's), but you can still create/delete/edit/nest ToC entries and point them to any page (or any page element's id/anchor) you like. No one HAS to use semantically correct headers to build the ToC (though they really should).

It seems as though you believe h tags are the only way a working ToC can be created using Sigil's tools.

[Hitch]

Originally Posted by slowsmile

@Kevin...It's certainly true enough what you say if you are talking about Sigil only -- because the only way that you can insert a TOC and create the relevant and associated XML structure in Sigil is by formatting and marking all TOC headers with h1, h2, h3 etc. But this is not the only way to create a TOC and xml structure in an epub.

You certainly don't have to format headers with html heading styles with certain other apps like Scrivener. Scrivener will generally output all text and headers with a simple indexed CSS text style name like scrivener15. There are no html header definitions in the scriv-generated css. The Scrivener-generated CSS doesn't even distinguish between headers, spans or para styling. Scrivener can do this because, on export to epub, it always creates toc and xml structure using a different method that is entirely based upon the scriv Binder structure and the pre-compiler Contents settings.

Scrivener is a writing program. That's not the same thing as an XML-checker, or an ePUBchecker, etc. Its job isn't the same as that which is needed or expected or used by a program like Sigil. Sigil is an ePUB-generation program, for experienced users who know how to work in HTML and CSS. Worlds apart.

But why would anyone want to avoid html heading styles in their epub? Using html heading styles in your epub can and will cause strange header spacing problems on conversion to Kindle within the Look Inside version. This is well known on forums like the KDP Forum -- lots of indie authors complaining about the Look Inside header spacing problems there. These header spacing problems -- as well as Look Inside text align and text indent issues -- are all caused by Kindle overrides(via cascading stylesheets) overriding your styling within the CSS. So that's really why it is advisable to use simple para styles for all your headers for Kindle conversions because the Kindle overrides will not be able touch or change the spacing attributes on your para styles in the Look Inside html version. Lots of mainstream publishers are now also adopting this same formatting tactic in order to particularly avoid these header spacing problems in Kindle's Look Inside.[/quote]

No. I'm sorry, that's wrong. It's not a "well-known" problem on the KDP forums. The idea that the use of headings, as opposed to paragraph styles, creates problems with the LI is a theory that is promulgated by ONE POSTER over there. A theory shown to be incorrect. Repeatedly. And just because a BPH puts out an eBook with paragraph styles used incorrectly as headings is no reason to jump off the same cliff. ALL the BPH's outsource their eBook work to India, and take the fastest, least-expensive results. This isn't rumor or other nonsense, it's fact.

Is it possible, if someone just uses whatever H1 style that comes along, that the resulting heading display could be weird? Yes, of course. But we've done thousands of books, all with heading styles, and somehow, they don't have mangled headings in the LITB.

Because there are some folks over at the KDP that are lemmings, they are repeating this as though it's gospel, but just recently, that same poster finally agreed--after MONTHS of angrily disagreeing with another long-time author there, that he was completely and utterly wrong about the different "dpi" of images. So...as we are all human, we are all imperfect. Yes, HIS headings may have had issues at the LITB, but...that doesn't mean it's a bug, or a glitch. It means simply that HE had problems.

And please don't get me wrong, I really love Sigil like no other app. IMHI it's simply the best epub app out there bar none. I always use it, in the final stage, to fix errors and to put on the final touches to my epub styling.

What Scrivener uses, or doesn't, really has nothing to do with this discussion. It's comparing apples and oranges. Scrivener's job isn't to ensure that an eBook is properly created; its job is to do the best it can to give a DIYer a viable eBook that can be uploaded.

Whether or not a writing plrogram uses headings, versus a program dedicated to XHTML...that's not the same thing. Scrivener only cares about getting you something you can use. The Sigil guys like to try to make sure that the files are coded correctly.

As mentioned earlier in this thread, you can build an NCX or TOC manually, by going through it and indicating which pages, with what paragraph-faux-heading, you want in the NCX/TOC.

And folks should bear in mind--when accessibility starts being checked by Amazon--which most surely, sometime soon, they will start to do--you can bet your booties that using the wrong class of element, to do a job, is going to become a problem about which the self-pubs will come to care. Just like the fact that typos, poor formatting, etc., all of which was blown off, before, have now come home to roost with the far-more-stringent Kindle Quality standards.


Hitch