Hard coding of Table of Contents Failing

synosure · 11-06-2010, 11:31 PM

I have a single-file exceptionally clean HTML e-book, with hard-coded TOC included. I'm converting to .mobi (Kindle). My hand-coded TOC works beautifully if I check "Do not add TOC to book". However, Kindle doesn't recognize my TOC as a valid TOC. Calibre claims to be able to handle this if you tell it in the meta data that you're including your own hard-coded TOC, but the documentation doesn't list how to do that in your meta data.

I need Calibre to recognize my TOC and pass that info on to the Kindle. Its already set up with the links and class names that Kindle should recognize. It would be a plus if it could create the toc.ncx file as well, for Kindle location data, I just don't want Calibre to visually add its own TOC at the end of the book. Is there a way to do any of this?

As a side note, I may have found a bug in the TOC Filters. If you set the TOC level 1 filter to look for all tags (*) that have class="toc1", it will ignore any items that are images. If you use an image to start a chapter, it won't make it into the auto-generated TOC. You can create other rules that get around this and make it work, but you have to play with it.

Thanks!

Manichean · 11-07-2010, 06:21 AM

So, from what I understand, you want to use the inline TOC as metadata TOC? To do that, you need to tell Calibre to look for chapter headings via the structure detection part of the conversion settings. It will then add the headings it finds to a metadata TOC. As far as I know, there's no direct way to use the inline TOC as metadata TOC in Calibre. You might have some luck with the Mobipocket Creator, or, if you want to convert some more, Sigil (you'd have to create an ePub, edit that to your liking and convert to Mobi).

Knuckles McGinty · 11-07-2010, 10:23 AM

I'm finidng myself plagued by a similar set of problems. (1) Upon importing my EPUB into Calibre I end up with two covers. What do I do to get rid of the Calibre generated cover? (2) When I convert my EPUB to a MOBI, Calibre adds a second table of contents at the back of the book! How do I get rid of that second Table of Contents?

synosure · 11-07-2010, 10:54 AM

As always, no matter how many hours or days I search for an answer, shortly after I ask for help, I finally find it. I wanted calibre to create the NCX file for me, but gave up on that. The answer is to hand code the NCX and the OPF files. I don't mind the OPF, I just hate the busy-work of creating the NCX, since I know Calibre knows how to do it a heck of a lot faster than me.

Once you've hard-coded the TOC, the NCX, and the OPF, then you can test it by making sure Amazon's kindlegen software runs smoothly on it. However, kindlegen shrinks images and ignores pre-defined paragraph spacing, so Calibre is still required. Zip up the images, text, NCX, and OPF, open the zip file in Calibre, then use Calibre to convert to .mobi.

First bug note - The bug mentioned in the first post still exists. To replicate, create an ebook where chapters are marked with class="toc1", but have some of the tags be h3, and some be img. The images won't make it into the table of contents. (If the TOC search is //*[re:test(@class, "toc1", "i")])

Second bug note - Take a properly formed, hand-coded e-book, as defined in the body of this post. Run it through kindlegen, and it works perfectly, including setting the cover image. Zip it all up and open the zip file in Calibre. The TOC et al work perfectly, but Calibre does not recognize the cover image.

kovidgoyal · 11-07-2010, 11:14 AM

Quote:

Originally Posted by synosure

Once you've hard-coded the TOC, the NCX, and the OPF, then you can test it by making sure Amazon's kindlegen software runs smoothly on it.

That test only tests if your hand coded files work with kindlegen, a completely meaningless test.

Quote:

First bug note - The bug mentioned in the first post still exists. To replicate, create an ebook where chapters are marked with class="toc1", but have some of the tags be h3, and some be img. The images won't make it into the table of contents. (If the TOC search is //*[re:test(@class, "toc1", "i")])

That's not a bug TOC elements need to have text, images dont. If you want to use images as chapter headings, andd a <a id="..." style="display:none">some text</a> after the image and have the Xpath detect that.

Quote:

Second bug note - Take a properly formed, hand-coded e-book, as defined in the body of this post. Run it through kindlegen, and it works perfectly, including setting the cover image. Zip it all up and open the zip file in Calibre. The TOC et al work perfectly, but Calibre does not recognize the cover image.

[/quote]

Again the fact that your hand coded files work with kindlegen is completely meaningless. calibre is not a kindlegen clone.

synosure · 11-07-2010, 12:24 PM

I can appreciate the argument that Tables of Contents require some text. As for the second issue, I would argue that running Kindlegen isn't a completely meaningless test. While Calibre obviously isn't a kindlegen clone, the success of kindlegen does, to a certain extent, prove that my OPF file defines the cover properly. Calibre is still ignoring that tag in the guide section of the OPF file. Not a major problem, but it is a minor oversight that should be noted.

Still, it's a great program, and we all really, really thank you for your hard work.

kovidgoyal · 11-07-2010, 12:36 PM

Quote:

Originally Posted by synosure

I would argue that running Kindlegen isn't a completely meaningless test. While Calibre obviously isn't a kindlegen clone, the success of kindlegen does, to a certain extent, prove that my OPF file defines the cover properly.

No, it proves that it defines it properly for kindlegen, not the same thing at all.

synosure · 11-07-2010, 02:31 PM

While I appreciate the theoretical concept behind that statement, I'm afraid it doesn't change the bug report. The cover jpg is defined properly in the OPF's manifest, then assigned properly in the OPF's guide, as defined by the Open Packaging Format 2.0 Final Specifications.

Ignoring all other (non-cover-related) lines, the OPF code looks like:
<manifest>
<item href="BookCover.jpg" id="frontcover" media-type="image/jpeg"/>
</manifest>
<guide>
<reference type="cover" title="Cover" href="BookCover.jpg" />
</guide>

When the book is added to the calibre library, Calibre doesn't get the cover reference.

kovidgoyal · 11-07-2010, 03:01 PM

The OPF specification has no defined way of specifying a cover. A guide element specifying the cover is purely optional and no reading system is required to follow it. Nor are its semantics defined in any unambiguous way.

What you are asking for is that when a zip file is added to calibre, calibre should look inside the ZIP, read the OPF and then open and read the cover. No specification mandates this behavior for ZIP files.

And just to illustrate the complexities of doing something like this, there at least 3 common ways an OPF inside a ZIP file can specify a cover:

1) A <meta> element of type 'cover' that points to the id of the cover image in the manifest

2) A <guide> element as you described

3) Expecting the reading system to render the first element in the spine and using the first 'screenful' of that as the cover.

EPUB for example (which is just an OPF in a ZIP file) uses a mix of all three of those strategies.

The last time I checked kindlegen supports only the second.

I haven't bothered to implement that complexity when importing ZIP files as frankly I have no idea why anyone would go to the trouble of creating a ZIP file with an OPF and not just make it an EPUB.

When dealing with EPUB, calibre supports all 3 strategies. So I would suggest you make an epub of your zip file and import that to calibre.

synosure · 11-07-2010, 07:41 PM

While OPF has no specific defined method for defining a cover, the word 'cover' is only mentioned in one place in the entire specification for OPF, and that is when placing the definition in the guide. It does not suggest or offer any other method for defining a cover.

synosure · 11-08-2010, 12:29 AM

Well, I took my files and created a proper epub file. The OPS file within the epub has the cover defined in its guide, as shown above. When the epub is imported into the latest version of Calibre, it still does not recognize the book cover. Instead, it makes the cover the first page of the manuscript.

kovidgoyal · 11-08-2010, 11:37 AM

Yes, in EPUB, calibre will use the first page of the manuscript in preference to the <guide> element (this is in accordance with the EPUB spec), unless for some reason the first page cannot be rendered.

If you want to force the use of a raster image, add the following to your EPUB:

<meta name="cover" content="id of cover image in manifest"/>

inside the <metadata> element.

And if you want your EPUB to work across all EPUB readers, you should ideally insert a simple HTML file as the first item in the spine that includes your cover image.

synosure · 11-08-2010, 11:52 AM

Thanks for the tip. Again, it's a great program, and us users truly appreciate all your hard work!

11-06-2010, 11:31 PM	#1
synosure Member Posts: 13 Karma: 10 Join Date: Jun 2010 Device: none	Hard coding of Table of Contents Failing I have a single-file exceptionally clean HTML e-book, with hard-coded TOC included. I'm converting to .mobi (Kindle). My hand-coded TOC works beautifully if I check "Do not add TOC to book". However, Kindle doesn't recognize my TOC as a valid TOC. Calibre claims to be able to handle this if you tell it in the meta data that you're including your own hard-coded TOC, but the documentation doesn't list how to do that in your meta data. I need Calibre to recognize my TOC and pass that info on to the Kindle. Its already set up with the links and class names that Kindle should recognize. It would be a plus if it could create the toc.ncx file as well, for Kindle location data, I just don't want Calibre to visually add its own TOC at the end of the book. Is there a way to do any of this? As a side note, I may have found a bug in the TOC Filters. If you set the TOC level 1 filter to look for all tags (*) that have class="toc1", it will ignore any items that are images. If you use an image to start a chapter, it won't make it into the auto-generated TOC. You can create other rules that get around this and make it work, but you have to play with it. Thanks!

11-07-2010, 10:23 AM	#3
Knuckles McGinty Member Posts: 22 Karma: 10 Join Date: Oct 2010 Device: Kindle	Too Many Covers, Too Many T O C's I'm finidng myself plagued by a similar set of problems. (1) Upon importing my EPUB into Calibre I end up with two covers. What do I do to get rid of the Calibre generated cover? (2) When I convert my EPUB to a MOBI, Calibre adds a second table of contents at the back of the book! How do I get rid of that second Table of Contents?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Table of Contents	peterinnes	Sigil	1	09-29-2010 03:03 AM
Help with my Table of Contents	Skylinefranc	Calibre	0	03-19-2010 12:55 AM
How to: table of contents	wizzofoz	Sigil	1	10-08-2009 08:22 AM
Migrating Calibre from a failing hard drive - mangled my Collections data	lconover	Calibre	4	03-13-2009 08:25 AM
only the table of contents	wang960	Sony Reader	3	08-29-2008 12:45 PM

11-07-2010, 06:21 AM	#2
Manichean Wizard Posts: 3,130 Karma: 91256 Join Date: Feb 2008 Location: Germany Device: Cybook Gen3	So, from what I understand, you want to use the inline TOC as metadata TOC? To do that, you need to tell Calibre to look for chapter headings via the structure detection part of the conversion settings. It will then add the headings it finds to a metadata TOC. As far as I know, there's no direct way to use the inline TOC as metadata TOC in Calibre. You might have some luck with the Mobipocket Creator, or, if you want to convert some more, Sigil (you'd have to create an ePub, edit that to your liking and convert to Mobi).

11-07-2010, 10:54 AM	#4
synosure Member Posts: 13 Karma: 10 Join Date: Jun 2010 Device: none	As always, no matter how many hours or days I search for an answer, shortly after I ask for help, I finally find it. I wanted calibre to create the NCX file for me, but gave up on that. The answer is to hand code the NCX and the OPF files. I don't mind the OPF, I just hate the busy-work of creating the NCX, since I know Calibre knows how to do it a heck of a lot faster than me. Once you've hard-coded the TOC, the NCX, and the OPF, then you can test it by making sure Amazon's kindlegen software runs smoothly on it. However, kindlegen shrinks images and ignores pre-defined paragraph spacing, so Calibre is still required. Zip up the images, text, NCX, and OPF, open the zip file in Calibre, then use Calibre to convert to .mobi. First bug note - The bug mentioned in the first post still exists. To replicate, create an ebook where chapters are marked with class="toc1", but have some of the tags be h3, and some be img. The images won't make it into the table of contents. (If the TOC search is //*[re:test(@class, "toc1", "i")]) Second bug note - Take a properly formed, hand-coded e-book, as defined in the body of this post. Run it through kindlegen, and it works perfectly, including setting the cover image. Zip it all up and open the zip file in Calibre. The TOC et al work perfectly, but Calibre does not recognize the cover image.

11-07-2010, 12:24 PM	#6
synosure Member Posts: 13 Karma: 10 Join Date: Jun 2010 Device: none	I can appreciate the argument that Tables of Contents require some text. As for the second issue, I would argue that running Kindlegen isn't a completely meaningless test. While Calibre obviously isn't a kindlegen clone, the success of kindlegen does, to a certain extent, prove that my OPF file defines the cover properly. Calibre is still ignoring that tag in the guide section of the OPF file. Not a major problem, but it is a minor oversight that should be noted. Still, it's a great program, and we all really, really thank you for your hard work.

11-07-2010, 02:31 PM	#8
synosure Member Posts: 13 Karma: 10 Join Date: Jun 2010 Device: none	While I appreciate the theoretical concept behind that statement, I'm afraid it doesn't change the bug report. The cover jpg is defined properly in the OPF's manifest, then assigned properly in the OPF's guide, as defined by the Open Packaging Format 2.0 Final Specifications. Ignoring all other (non-cover-related) lines, the OPF code looks like: <manifest> <item href="BookCover.jpg" id="frontcover" media-type="image/jpeg"/> </manifest> <guide> <reference type="cover" title="Cover" href="BookCover.jpg" /> </guide> When the book is added to the calibre library, Calibre doesn't get the cover reference.

11-07-2010, 03:01 PM	#9
kovidgoyal creator of calibre Posts: 43,864 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	The OPF specification has no defined way of specifying a cover. A guide element specifying the cover is purely optional and no reading system is required to follow it. Nor are its semantics defined in any unambiguous way. What you are asking for is that when a zip file is added to calibre, calibre should look inside the ZIP, read the OPF and then open and read the cover. No specification mandates this behavior for ZIP files. And just to illustrate the complexities of doing something like this, there at least 3 common ways an OPF inside a ZIP file can specify a cover: 1) A <meta> element of type 'cover' that points to the id of the cover image in the manifest 2) A <guide> element as you described 3) Expecting the reading system to render the first element in the spine and using the first 'screenful' of that as the cover. EPUB for example (which is just an OPF in a ZIP file) uses a mix of all three of those strategies. The last time I checked kindlegen supports only the second. I haven't bothered to implement that complexity when importing ZIP files as frankly I have no idea why anyone would go to the trouble of creating a ZIP file with an OPF and not just make it an EPUB. When dealing with EPUB, calibre supports all 3 strategies. So I would suggest you make an epub of your zip file and import that to calibre.

11-07-2010, 07:41 PM	#10
synosure Member Posts: 13 Karma: 10 Join Date: Jun 2010 Device: none	While OPF has no specific defined method for defining a cover, the word 'cover' is only mentioned in one place in the entire specification for OPF, and that is when placing the definition in the guide. It does not suggest or offer any other method for defining a cover.

11-08-2010, 12:29 AM	#11
synosure Member Posts: 13 Karma: 10 Join Date: Jun 2010 Device: none	Well, I took my files and created a proper epub file. The OPS file within the epub has the cover defined in its guide, as shown above. When the epub is imported into the latest version of Calibre, it still does not recognize the book cover. Instead, it makes the cover the first page of the manuscript.

11-08-2010, 11:37 AM	#12
kovidgoyal creator of calibre Posts: 43,864 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	Yes, in EPUB, calibre will use the first page of the manuscript in preference to the <guide> element (this is in accordance with the EPUB spec), unless for some reason the first page cannot be rendered. If you want to force the use of a raster image, add the following to your EPUB: <meta name="cover" content="id of cover image in manifest"/> inside the <metadata> element. And if you want your EPUB to work across all EPUB readers, you should ideally insert a simple HTML file as the first item in the spine that includes your cover image.

11-08-2010, 11:52 AM	#13
synosure Member Posts: 13 Karma: 10 Join Date: Jun 2010 Device: none	Thanks for the tip. Again, it's a great program, and us users truly appreciate all your hard work!

Advert

Advert