epubcheck errors regarding NCX - can you help me translate these? - Page 2

Hitch · 06-03-2011, 04:21 PM

Quote:

Originally Posted by JSWolf

But, I would want to return any ePub that had an internal ToC (totally useless) and not an external ToC. I just wish publishers would stop putting in an internal ToC when they have a perfectly good external ToC.

@JSWolf:

This will continue to happen (dualling TOC's {groan, bad pun alert}) for so long as mobi requires that you link an html.toc via the Guide, IMHO, for Kindle. It's a PITA, commercially-speaking, to make two books (like what we're all going through with making "Apple-compliant" epubs as opposed to REALLY compliant/valid epubs for everyone else) instead of one.

Hitch

JSWolf · 06-03-2011, 07:56 PM

Quote:

Originally Posted by Hitch

@JSWolf:

This will continue to happen (dualling TOC's {groan, bad pun alert}) for so long as mobi requires that you link an html.toc via the Guide, IMHO, for Kindle. It's a PITA, commercially-speaking, to make two books (like what we're all going through with making "Apple-compliant" epubs as opposed to REALLY compliant/valid epubs for everyone else) instead of one.

Hitch

But you do get a ToC. It's just not at the front. It's at the back. And it is linked via the Table fo Contents link. So really, an internal ToC is useless and a waste of space. I really dislike when the chapter titles are linked to the ToC.

As far as I am concerned, let Amazon fix their conversion software to deal with toc.ncx hoever they want so we don't have to infest the ePub with an internal ToC.

Dusk · 06-04-2011, 02:35 AM

JSWolf wrote:

"I just wish publishers would stop putting in an internal ToC when they have a perfectly good external ToC."

Different people have different reading habits. I appreciate a table of contents within the file, especially if it includes blurbs for each of the chapters (as mine does). I agree with you, though, about the usefulness of the external table of contents.

Hitch · 06-04-2011, 05:43 AM

Quote:

Originally Posted by JSWolf

But you do get a ToC. It's just not at the front. It's at the back. And it is linked via the Table fo Contents link. So really, an internal ToC is useless and a waste of space. I really dislike when the chapter titles are linked to the ToC.

As far as I am concerned, let Amazon fix their conversion software to deal with toc.ncx hoever they want so we don't have to infest the ePub with an internal ToC.

@JSWolf: we may be speaking at cross-purposes. Having an ncx in an epub and dropping it on KindleGen doesn't create a user-visible toc, at the back or elsewhere. While the 5-way button may be able to make use of the ncx, to jump from chapter to chapter, the human reader can't "see" an NCX in a Kindle device through the simple expedient of running it through KG or Previewer (unless someone is running it through Calibre). Only a MBPC-created TOC (which is still an html.toc) shows up at the back in a quasi-automated fashion. That's the TOC that's linked via the TOC link--that IS an html.toc; the ncx is not directly linked to the TOC "button" or menu item, as bizarre as that all sounds. The TOC that is linked to the TOC menu button is an html-toc--NOT the toc.ncx, FWIW.

HTH,
Hitch

JSWolf · 06-10-2011, 09:50 PM

Quote:

Originally Posted by Hitch

@JSWolf: we may be speaking at cross-purposes. Having an ncx in an epub and dropping it on KindleGen doesn't create a user-visible toc, at the back or elsewhere. While the 5-way button may be able to make use of the ncx, to jump from chapter to chapter, the human reader can't "see" an NCX in a Kindle device through the simple expedient of running it through KG or Previewer (unless someone is running it through Calibre). Only a MBPC-created TOC (which is still an html.toc) shows up at the back in a quasi-automated fashion. That's the TOC that's linked via the TOC link--that IS an html.toc; the ncx is not directly linked to the TOC "button" or menu item, as bizarre as that all sounds. The TOC that is linked to the TOC menu button is an html-toc--NOT the toc.ncx, FWIW.

HTH,
Hitch

We should not have an internal ToC just to appease Amazon. They could design KindleGen to take toc.ncx and generate an internal ToC. No reason they cannot. And Calibre generates a linked ToC. Sure, it's at the back, but that's OK. An internal ToC (at the front) just makes us have to turn more pages to get past it.

eping · 06-11-2011, 12:22 AM

Your navmap part of NCX code may like this

Code:

<navMap>
    
</navMap>

It's a blank NCX file without TOC, such epub can be read properly
on ADE and iPad, but can't pass epubcheck, which will report

element "navMap" incomplete; missing required element "navPoint"
first playOrder value is not 1

ePub Maker before 1.2 also generates such code if there's no TOC in Word,
also received such error code from epubcheck.
I guess Smashword also has such a problem.

You may have to insert a navpoint manually to suppress this error, or you may use another tool to convert.

By the way, the error tip from epubcheck is generally weird, misleading or meaningless.

Hitch · 06-12-2011, 10:36 PM

Quote:

Originally Posted by JSWolf

We should not have an internal ToC just to appease Amazon. They could design KindleGen to take toc.ncx and generate an internal ToC. No reason they cannot. And Calibre generates a linked ToC. Sure, it's at the back, but that's OK. An internal ToC (at the front) just makes us have to turn more pages to get past it.

@JSWolf:

I don't use Calibre to create mobi files, firstly; but more importantly, all Calibre does is create an internal toc--an html.toc--which it links via the Guide; it does exactly what you are saying we should NOT have to do to 'appease Amazon.' Calibre isn't magically utilizing the ncx sans an html.toc; it uses the ncx navmap to create an html.toc and linking it to via the Guide items. The TOC "at the back" to which you refer (is also not due to Calibre; it's due to KindleGen/MobiGen) is the very TOC you're saying we don't need.

So, call it by any other name, but the "Calibre TOC" that you're saying is sufficient is the selfsame "internal TOC" that you're saying we should not create to appease Amazon. More importantly, and more relevant to the discussion, if you're using Calibre you ARE "infesting the epub with an internal TOC;" you're simply allowing Calibre to do it for you. The "perfectly good external toc" you're referring to, a few posts ago, does not exist for Mobi/PRC; if you are discussing those created by Calibre, those have INTERNAL TOC's, created as I've described.

My point was, and still is: any user who simply has an epub with an ncx solely will NOT get a user-viewable and usable TOC via KindleGen or MobiGen sans an html.toc that is linked via the Guide. NOT the ncx.

Hitch
(Please check out SHAKEN: STORIES FOR JAPAN--Great reads, great authors, great cause; 100% of all royalties go directly to tsunami, earthquake and radiation victims in Japan.)

JSWolf · 06-13-2011, 09:56 AM

I think you've got it somewhat wrong. ePub can have two different ToC. One internal and one external. The NCX file it the external ToC. if your ToC is in the NCX file, you don't need the internal ToC.

When you convert ePub to Mobi, the NCX gets converted to a linked ToC that is at the back of the Mobi. If you have both an NCX and an internal ToC, you may or may not end up with two ToC in the Mobi. But if the requirement is to have an internal ToC near the front of the Mobi, there there is no reason at all that Kindlegen could not manage that by using the NCX file. The fact that the NCX gets relegated to the back is not my concern. My concern it to get rid of any internal ToC. And the worst ones of all are when the publisher links the ToC headers back to the internal ToC. That's just wrong for an ePub.

What does Kindlegen do with the NCX? I knwo what Calibre does with it. It creates a linked ToC at the back of the Mobi.

DiapDealer · 06-13-2011, 11:21 AM

Quote:

Originally Posted by JSWolf

When you convert ePub to Mobi, the NCX gets converted to a linked ToC that is at the back of the Mobi.

By what software?? Kindlegen certainly doesn't create a "linked ToC at the back of the mobi" from the NCX file. Nor does MobiPocket Creator. Calibre will do it if you tell it to, but it's quite easy to check the box that will stop that behavior. You might be the one that's confused here.

JSWolf · 06-13-2011, 01:55 PM

Calibre will do it without having to tell it to...

Code:

ebook-convert file.epub file.mobi

And from there you will get a linked ToC at the back of the Mobi and no other ToC if the ePub has no internal ToC but only a ToC in the NCX.

Hitch · 06-13-2011, 02:38 PM

Quote:

Originally Posted by JSWolf

I think you've got it somewhat wrong. ePub can have two different ToC. One internal and one external. The NCX file it the external ToC. if your ToC is in the NCX file, you don't need the internal ToC.

When you convert ePub to Mobi, the NCX gets converted to a linked ToC that is at the back of the Mobi. If you have both an NCX and an internal ToC, you may or may not end up with two ToC in the Mobi. But if the requirement is to have an internal ToC near the front of the Mobi, there there is no reason at all that Kindlegen could not manage that by using the NCX file. The fact that the NCX gets relegated to the back is not my concern. My concern it to get rid of any internal ToC. And the worst ones of all are when the publisher links the ToC headers back to the internal ToC. That's just wrong for an ePub.

What does Kindlegen do with the NCX? I knwo what Calibre does with it. It creates a linked ToC at the back of the Mobi.

@JSWolf:

I'm sorry...but you're simply incorrect. What you see, via Calibre, is nothing more than an internal TOC created via the use of the navmap in the ncx.

I'm really very well aware of what an ncx is versus a Guide-linked html.toc (what you are calling an "internal toc"). What Calibre does is create a Guide-linked internal, html.toc; it is doing EXACTLY what you say we should not do to kowtow to Amazon. That toc displayed by Calibre is absolutely not some dynamic, created-on-the-fly usage of the ncx; that is a plain old internal toc, created by Calibre, linked via the Guide, as per the Amazon specs.

Just because Calibre creates it doesn't make it something it isn't. That's an internal toc, just like Amazon wants. That is NOT an ncx (aka "external TOC"). It simply takes the navmap, makes an internal toc, which, via use of KindleGen, gets popped in the back of the book.

HTH,
Hitch
(Please check out SHAKEN: STORIES FOR JAPAN--Great reads, great authors, great cause; 100% of all royalties go directly to tsunami, earthquake and radiation victims in Japan.)

DiapDealer · 06-13-2011, 03:00 PM

Quote:

Originally Posted by JSWolf

And from there you will get a linked ToC at the back of the Mobi and no other ToC if the ePub has no internal ToC but only a ToC in the NCX.

You're making absolutely no sense now.

There's an inline TOC (xhtml) that's completely optional in either epub or mobi. It's part of the ebook's text. And there's an internal/structural TOC (NCX for ePub and OEBPS) that you will never see by turning pages. It's part of the ebook's structure.

Calibre is the only conversion software (I know of) that will turn the internal (NCX) TOC of an epub into an inline (XHTML) TOC and add it to the back of the mobi—and you can easily tell it not to do that. So it makes no sense to blame an ebook having two TOC's on any particular conversion software. It's simply a choice or an oversight on the part of the creator.

JSWolf · 06-14-2011, 09:58 PM

Why isn't anybody understanding?

Calibre takes the NCX and generates a ToC from it for the Mobi. It is put at the back. Yes it's HTML and not NCX. I didn't say otherwise. And yes it is guide linked. What it isn't is near the front of the eBook.

Mobipocket Reader doesn't deal with the NCX file properly when t converts an ePub. I'm guessing Kindlegen botches the ToC as well.

I blame publishers for kow-towing to Amazon. Because if not for Amazon's botched conversion software, there would be no need for an internal ToC in an ePub.

06-11-2011, 12:22 AM	#21
eping ePub Maker Posts: 120 Karma: 16 Join Date: Dec 2009 Location: Mordor Device: iPad,Kindle 3, Nook 2	Your navmap part of NCX code may like this Code: <navMap> </navMap> It's a blank NCX file without TOC, such epub can be read properly on ADE and iPad, but can't pass epubcheck, which will report element "navMap" incomplete; missing required element "navPoint" first playOrder value is not 1 ePub Maker before 1.2 also generates such code if there's no TOC in Word, also received such error code from epubcheck. I guess Smashword also has such a problem. You may have to insert a navpoint manually to suppress this error, or you may use another tool to convert. By the way, the error tip from epubcheck is generally weird, misleading or meaningless. Last edited by eping; 06-11-2011 at 12:26 AM.

06-13-2011, 01:55 PM	#25
JSWolf Resident Curmudgeon Posts: 73,970 Karma: 128903378 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	Calibre will do it without having to tell it to... Code: ebook-convert file.epub file.mobi And from there you will get a linked ToC at the back of the Mobi and no other ToC if the ePub has no internal ToC but only a ToC in the NCX.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
how to translate Sigil ?	bionet	Sigil	9	06-02-2011 04:07 PM
beginner needs help with epubcheck errors...	jeanina	ePub	10	01-25-2011 08:49 PM
Can I have a Tag that doesn't translate to a category?	jjansen	Calibre	6	03-26-2010 01:47 AM
Web-based epubcheck upgraded to epubcheck 1.0.5	kjk	ePub	4	02-09-2010 09:53 PM

06-04-2011, 02:35 AM	#18
Dusk Member Posts: 11 Karma: 10 Join Date: Jan 2010 Device: None	JSWolf wrote: "I just wish publishers would stop putting in an internal ToC when they have a perfectly good external ToC." Different people have different reading habits. I appreciate a table of contents within the file, especially if it includes blurbs for each of the chapters (as mine does). I agree with you, though, about the usefulness of the external table of contents.

06-13-2011, 09:56 AM	#23
JSWolf Resident Curmudgeon Posts: 73,970 Karma: 128903378 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	I think you've got it somewhat wrong. ePub can have two different ToC. One internal and one external. The NCX file it the external ToC. if your ToC is in the NCX file, you don't need the internal ToC. When you convert ePub to Mobi, the NCX gets converted to a linked ToC that is at the back of the Mobi. If you have both an NCX and an internal ToC, you may or may not end up with two ToC in the Mobi. But if the requirement is to have an internal ToC near the front of the Mobi, there there is no reason at all that Kindlegen could not manage that by using the NCX file. The fact that the NCX gets relegated to the back is not my concern. My concern it to get rid of any internal ToC. And the worst ones of all are when the publisher links the ToC headers back to the internal ToC. That's just wrong for an ePub. What does Kindlegen do with the NCX? I knwo what Calibre does with it. It creates a linked ToC at the back of the Mobi.

06-14-2011, 09:58 PM	#28
JSWolf Resident Curmudgeon Posts: 73,970 Karma: 128903378 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	Why isn't anybody understanding? Calibre takes the NCX and generates a ToC from it for the Mobi. It is put at the back. Yes it's HTML and not NCX. I didn't say otherwise. And yes it is guide linked. What it isn't is near the front of the eBook. Mobipocket Reader doesn't deal with the NCX file properly when t converts an ePub. I'm guessing Kindlegen botches the ToC as well. I blame publishers for kow-towing to Amazon. Because if not for Amazon's botched conversion software, there would be no need for an internal ToC in an ePub.