Problem Generating Toc

[DiapDealer]

Originally Posted by Hitch

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 just to be clear: by "manually," I didn't mean hand editing the ncx's xml (though that's certainly doable as well). I meant the wysiwyg toc editing dialog. It makes it fairly trivial to point ToC entries to any page/element you like (with or without h tags).

I know you know this, Hitch, I just wanted make sure all participants understand. Auto-generation using h tags is not the only Sigil method for creating/editing a working ToC. It seems not everyone is aware of this.

[slowsmile]

DiapDealer said:
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.

You can certainly create the doc TOC and a Logical TOC(Device toc) using Sigil -- you can even create a multi-level doc TOC. You can also do the same in Calibre -- except you do not have to mark your headers with a heading style first -- in Calibre you just choose a page for each TOC header.

DiapDealer said:
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 majority of ebooks out there are epub 2. And would you really expect an indie author to know how to manually and safely format his toc.nx or content.opf? That's a wide assumption and a bad road for any indie author to take (I'm not talking about developers here). And if you manually edit the xml within say the toc.ncx then Sigil does not automatically update the content.opf sections for epub 2 ebooks. If you use Calibre and if you do manually change the formatting in the toc.ncx or the content.opf then it automatically gets updated everywhere in the epub whenever you click Calibre editor's OK button. I love Sigil dearly, but for both TOC creation and XML editing, I prefer the Calibre way because its easier and faster. My hat off to Kovid Goyal for developing such a useful editor.

[slowsmile]

DiapDealer said:
I know you know this, Hitch, I just wanted make sure all participants understand. Auto-generation using h tags is not the only Sigil method for creating/editing a working ToC. It seems not everyone is aware of this.


Exactly right -- there is more than one way of creating/editing a working TOC in an epub -- I agree with you entirely. But from what she has already posted on this thread, I'm not sure that Hitch would agree with you though. According to her -- the ONLY way you can create a workable TOC is by using html heading tags.

And if anybody sincerely believes that using named paragraph styles for all the headers in your Kindle ebook is not possible -- please have a look at an ebook of mine on Kindle that does not contain a single heading style(ie h1, h2, h3 etc) in it:

Kalapati

[DiapDealer]

Originally Posted by slowsmile

The majority of ebooks out there are epub 2. And would you really expect an indie author to know how to manually and safely format his toc.nx or content.opf?

As I feared: you're totally misunderstanding what I'm trying to say. I am not--as I thought I pretty clearly mentioned before--talking about manually editing the the xml in the ncx or opf file.

Originally Posted by slowsmile

That's a wide assumption and a bad road for any indie author to take (I'm not talking about developers here). And if you manually change the xml within say the toc.ncx then Sigil does not automatically update the content.opf sections for epub 2 ebooks.

Again: not talking about manually editing xml files. Also, there are no edits made to the NCX file that would require updates to the OPF.

Originally Posted by slowsmile

If you use Calibre and if you manually change the formatting in the toc.ncx or the content.opf then it automatically gets updated everywhere in the epub whenever you click Calibre editor's OK button. I love Sigil dearly, but for TOC creation I prefer the Calibre way because its easier and faster.

If you use Sigil's Tools->Table Of Contents->Edit Table Of Contents you will find a dialog that allows you to do the same thing. Create/edit/delete your ToC headings (nest them, unnest them if you like), point them to the page (or ID) you want them to be linked to, click "OK" and Sigil updates the underlying code in the EPUB automatically. Badabing badaboom. You may "prefer" doing it calibre's way, but I'm getting the distinct impression that's only because you don't know there's a similar functionality within Sigil.

[DiapDealer]

Originally Posted by slowsmile

According to her -- the ONLY way you can create a workable TOC is by using html heading tags.

She didn't say that, and it's simply not true. It's the recommended way, but Sigil will allow you to easily create a ToC without a single h tag being present (if you so choose). It's what I've been trying (and obviously failing) to explain for several posts now.

[slowsmile]

JSWolfe said:
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.

That's right on the mark. And since publishers will never tell you their innermost formatting secrets -- which is perhaps fair enough -- then its up to indie authors/developers to find out and broadcast their own solutions in order to help other authors still struggling with these formatting issues.

[slowsmile]

Hitch....No, I'm not going there again with you because there's no point in regurgitating old immovable ground. I've already provided the reasons and the evidence for using named paragraph styles rather than html heading styles on this thread. That should be good enough for all the other posters to individually makeup their own minds on this issue.

Bill

[slowsmile]

DiapDealer said:
If you use Sigil's Tools->Table Of Contents->Edit Table Of Contents you will find a dialog that allows you to do the same thing. Create/edit/delete your ToC headings (nest them, unnest them if you like), point them to the page (or ID) you want them to be linked to, click "OK" and Sigil updates the underlying code in the EPUB automatically. Badabing badaboom. You may "prefer" doing it calibre's way, but I'm getting the distinct impression that's only because you don't know there's a similar functionality within Sigil.

I appreciate your concern but please trust me, I've been using Sigil and Calibre for about 7 years -- I really do understand how to create and generate a TOC in Sigil.

But I think you may have missed my point. So here it is again.

Before you can create any doc TOC or Device TOC in Sigil you must first mark all your epub main headings that will be displayed in the TOC with an html header style(usually h1 or h2).

In Calibre you do not have to use html header styling to mark out your TOC. All you do is click a button to select the page, name the TOC item and the TOC item link to that page is automatically created in Calibre.

So the way Sigil and Calibre create their TOCs is completely different.

[Hitch]

Originally Posted by slowsmile

Hitch....No, I'm not going there again with you because there's no point in regurgitating old immovable ground. I've already provided the reasons and the evidence for using named paragraph styles rather than html heading styles on this thread. That should be good enough for all the other posters to individually makeup their own minds on this issue.

Bill

Yes, William:

It had to be you, because nobody else would state the rigamarole about heading styles and the LITB as fact, or that "everybody knows" or any of that. It's simply incorrect, just as was your repeated heated statements about DPI. Remember that?

I pointed you to myriad books of ours, on Amazon, using heading classes, that look perfectly fine in the LITB. If your theory is right, then ALL of our books should look WRONG in the LITB. But they don't. So, very simply, how do you explain that?

And lastly--for the VERY LAST TIME--I never, ever said that you could "only" build TOC's in Sigil using heading classes. That would be wrong. In fact, we don't use Sigil's built-in automagic TOC maker. We make them ourselves. I do, absolutely, use the automagic NCX maker when we are using Sigil. As we use other methods, including Epsilon, THOSE NCX & TOCs are all written by hand.

So, for the final time on this topic: the only person who INSISTS that if you use heading classes, that the LITB will come out poorly or incorrectly, is YOU. Just as you were 100% incorrect about the DPI/Images issue, you are wrong about this. Period. Yes, sure, maybe it happened To. You. That doesn't mean that it happens to other people.

Hitch

[Tex2002ans]

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.

Originally Posted by DiapDealer

If you use Sigil's Tools->Table Of Contents->Edit Table Of Contents you will find a dialog that allows you to do the same thing. Create/edit/delete your ToC headings (nest them, unnest them if you like), point them to the page (or ID) you want them to be linked to, click "OK" and Sigil updates the underlying code in the EPUB automatically. Badabing badaboom.

Maybe people get confused because in Sigil they are two separate functions:

• "Tools" -> "Generate Table of Contents"
  • Creates TOC using <h1-6>.
• "Tools" -> "Edit Table of Contents"
  • (Doesn't have an icon and many people don't even notice it)
  • Is similar to Calibre's TOC Editor.

where Calibre has the Generate functionality folded into a button in the "Edit Table of Contents" tool.

Originally Posted by Hitch

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.

Next up we are going to get people promoting minus signs instead of hyphens/en-dashes/em-dashes! It looks the same to me! Who needs Text-to-Speech in books?

[Doitsu]

@slowsmile:
As Hitch has already pointed out, your idea that the use of headings, as opposed to paragraph styles, creates problems, is plainly wrong. I.e., by using presentational markup instead of semantic markup you're not only shooting yourself in the foot you're also not following best practices.

Originally Posted by slowsmile

The majority of ebooks out there are epub 2. And would you really expect an indie author to know how to manually and safely format his toc.nx or content.opf?

It's certainly true that most devices and apps only support epub2, but you can easily create epub2 compatible epub3 books with Sigil that compile fine with KindleGen. Since Sigil allows you to generate an NCX file from a NAV document, it also fairly easy to manually update the TOC. (Unlike the NCX file, the NAV document is a simple HTML file with list items.)
However, it's much easier to use the GUI for this.

[JSWolf]

Originally Posted by Hitch

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

What I think makes for good eBook code is simplicity. Just use as little code as possible and do it such that you don't have a huge CSS. I've seen the mess some publishes produce and when I get done, it's like it was made by someone else. The other day, I used Calibre to remove unused CSS code and 74 entries were removed. Also, I can take an ePub some publisher made and reduce the size very easily. If it has embedded fonts, subset them. losslessly compress images and sometimes compress again because the compression is too high and you won't notice the difference. Then there is removing the useless files like an internal ToC for an ePub 2. Also, making an ePub 3 the way it's being done also adds bulk because of the excess code that is not needed for an ePub 2.

Good code means less potential problems with programs/apps and/or Readers. I've read of people having problems with some Readers because of some eBook. That's because the code inside is either a mess and/or it's not valid. I've never had an issue like that because I make sure the code is valid. It takes very little time to validate.

One thing I don't get is why most eBooks are made with most paragraphs being like <p class="tx"> when you don't need that class because you can easily define the p class for the most common use?

Also, who decided that using up at least 14% of the screen for a chapter title is a good idea? I could go on, but you get it so I'll stop here for now.

[DiapDealer]

Originally Posted by slowsmile

I appreciate your concern but please trust me, I've been using Sigil and Calibre for about 7 years -- I really do understand how to create and generate a TOC in Sigil.

But I think you may have missed my point. So here it is again.

Before you can create any doc TOC or Device TOC in Sigil you must first mark all your epub main headings that will be displayed in the TOC with an html header style(usually h1 or h2).

As one of the co-maintainers and developers of Sigil (whose knowledge of its features, functionality, and abilities, I can assure you, is quite intimate and extensive), I can say without a shadow of a doubt that your point is patently false. You CAN create a "Device TOC" (by which I assume you mean NCX) and generate an html TOC from that--all without any header tags being present in your epub (and without manually diddling the xml in the NCX file). Please stop saying otherwise.

[Notjohn]

As a legacy from the years when I use H1 etc to size the entries on my title page, I ended with H2 as my go-to style for chapter headings. So I have no H1 headings at all.

Is that ever going to come back and bite me?

Great discussion. Thanks, all!

[Notjohn]

Originally Posted by Hitch

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.

I'm not seeing that at all. It's true that the absurd little dance that Look Inside did when the new version was introduced has at last gone away, so that it now opens at the first text page without skipping wildly through the cover, title page, etc. But of course the e-book has a cover, and the cover is not shown, which IMHO is a huge step backward.

And most books have this weirdness: they start AFTER the chapter head on that first text page. (I know that your books don't, but you aren't formatting most of Amazon's e-books.)

Here is the top Kindle best-seller this morning: https://www.amazon.com/gp/product/B01CGBC7BK

You don't see the chapter title unless you scroll up. Perhaps it was, as you suggest, outsourced to a third-world country. But here's the funny part: it's from an Amazon imprint.

While I was writing this, another book moved to the top: https://www.amazon.com/gp/product/B01DNJMO80/ and it too skips the chapter title.

And of course there's still a subset of books that open at the cover. So Amazon isn't even being consistent in its New Look.