Uploading epub to Kobo and Nook

shimmering · 08-17-2014, 05:24 PM

I wonder whether this could be useful to some.

ETA: But I wonder whether the replies could be more useful.

I've had a bit of a problem uploading an epub file to nook and kobo. I think it's now solved, in a way that possibly seems obvious in retrospect.

The problem was that after uploading, the TOC (by which I mean the non-html and ever-present TOC coded by an ncx file) expanded to include various undesirable entries that were not present in the TOC of the originally uploaded epub file. Oh dear.

My epub files are html-coded, command-line-zipped. They include one xhtml file for each of the chapters (all included in the TOC), plus (and herein the source of the issue) various further xhtml files that form part of the book but are not required in the TOC (e.g. things like the cover image, the title page, copyright, etc.). Well all these unincluded xhtml files, uploading to Both nook and kobo, spontaneously and disasterously appeared in an expanded TOC. Their TOC entries were pieces of code.

Well the only thing I found that worked to get around this and use the original TOC was to: NOT open the epub file in the previewer that presents itself immediately after uploading. That for both nook and kobo. If I opened the uploaded epub in the dashboard's previewer, then the extra entries appeared and could not be got rid (despite an apparent option to do so in a TOC editing tool for the nook case) of without reuploading the file.

So I think (for the moment) that that's a solved issue for me for the moment at least. Although it's a bit of a workaround and has the obvious issue that previewing is made more difficult if using the previewer wrecks the file. But there we are.

Hope this helps...
Or maybe you already knew. Or am I wrong?

davidfor · 08-18-2014, 03:32 AM

I suspect what is happening for the Kobo is related to their "Kobo ePub" format. This is usually know as "kepub" and is what Kobo use to send to the Kobo devices and apps. It is basically just an epub, but they add some spans for their bookmarking system and a couple of other things. From what I can tell, all files within a kepub have to have a ToC entry. When I have constructed a kepub without this, the devices will read the books, but there can be some strange things shown in the ToC and in the page number area of the screen. For kepubs, the devices show the current chapter name plus the current page within the chapter. That display can get interesting if there isn't a one-one relationship between the ToC entries and the files.

I'm not sure if that is the cause of what you are seeing or not. I'm not an author, so I haven't tried what you are doing.

shimmering · 08-18-2014, 05:00 AM

Thanks for that. That was interesting to hear. What you're describing does sound like it could be part of the same thing I am seeing. Maybe the better solution would be for me to go ahead (or go back) and create a longer TOC with a 1:1 TOC entry/xhtml file correlation.

That way, even if it does mean that the TOC would include things that I would deem unnecessary, at least I can determine how they appear there rather than have some automated system pluck out pieces of code (it seems to choose the names of the itemrefs from the spine in the content.opf) and put them on show in the TOC.

davidfor · 08-18-2014, 08:03 AM

I just remembered a document about the Kobo epub specs. The ToC section has the following:

Quote:

For ePub 2.0.1, Kobo reading platforms populate the ToC menu in the book with the ToC from the file toc.ncx (which is in navMap). However, if the toc.ncx is not present, the TOC menu is populated by the Spine listing in the OPF.

When an OPF-spine item is not listed in the TOC.ncx, the Kobo CMS will create a listing for it using the filename or the opening words from the section. This listing will be displayed to the user in the TOC Menu across all reading platforms. This process may be removed in a future release. ePubs that use a nav.html TOC will not be impacted.

So, yes, it looks like it is doing what you thought. But, I'm surprised it doesn't do that anyway. I'd say creating the ToC yourself makes sense.

dgatwood · 08-22-2014, 04:08 AM

If I'm reading that correct, the only way this should cause problems is if either your spine contains things that shouldn't be in there or your TOC is missing things that should be in it.

The spine should contain all of the main content, in linear reading order, and nothing else. For example, you might leave out end notes if they're in a separate file, or pages that just contain a larger version of a linked image, or other content that isn't part of the primary reading flow. Otherwise, it should be a complete view of what the book should look like if you were going to print it, in order, with no nesting.

However, it is worth noting that the spine contains exactly one entry per physical file, with no access to parts of a multipart file (a chapter with sections, for example). Its purpose is to tell the reader the order in which to glue the files together.

The TOC, in turn, provides the ability to structure the contents of the spine in a nested fashion. For example, you might nest chapters inside parts. The spine would contain the part page, followed by the first chapter in the part; the TOC would contain the part page, with all navPoint tag for each chapter in the part nested inside the part's navPoint tag.

Additionally, if you have sections within your chapter files (e.g. with named anchors before section headings), you can add these in the NCX as separate navPoint entries using fragment IDs (e.g. foo.xhtml#jumptarget). Caveat: top-level navPoint entries should not have fragment IDs for maximum compatibility.

So the TOC should always contain either the exact same entries as the spine or a superset of the entries in the spine (if you're adding links to sections within files), and should never contain a subset of the spine entries. If there are entries in the spine that aren't in the TOC, either the spine is wrong or the TOC is wrong.

dgatwood · 08-24-2014, 08:31 PM

BTW, your spec link is broken (http://[https://...). The correct link is

https://github.com/kobolabs/epub-spec

shimmering · 08-29-2014, 06:00 AM

You correctly describe the scenario that is no doubt behind the issue I am seeing:

Indeed, there are 14 (say) xhtml files that make up the book content.
I have listed all 14 of them in the spine to determine the correct play order
I have listed in the TOC.NCX only the 10 or 11 of them I want to appear in the TOC.

There is nothing fancy with subchapters/images etc. I just don't especially need TOC links to a copyright page, a page with a list of other books by the author, things like that. Irrelevant to the TOC, but still belong in the book. I would prefer them not to appear in the TOC. That is my ideal scenario.

I now understand that the Kobo spec requires that the NCX must include every entry from the spine. (is this different from "standard" epub spec? I mean files built like this validate fine.)

Are you suggesting that it is OK to remove items from the spine so that they will not be force-added to the TOC? This seems very counterintuitive. How will they then appear in the right place in the book?

JSWolf · 08-29-2014, 08:53 AM

You don't need every XML file to be in the ToC. But as for things like the copyright, list of books, and things like that, yes, they should be in the ToC.

goodmorningjulie · 04-16-2015, 04:23 AM

Shimmering - I had this EXACT same situation this week with Nook and Kobo and was banging my head against the wall because the client kept saying there was a ToC problem in the epub. We are skipping the previewer step now, as you recommended, but it is a bit nerve-wreaking to post to a new distributor and hit publish without being able to see a preview on their device. But is there any other way? Any updates on this issue?
Thanks SO MUCH for mentioning that this worked for you!!

Hitch · 04-17-2015, 01:13 AM

Quote:

Originally Posted by shimmering

You correctly describe the scenario that is no doubt behind the issue I am seeing:

Indeed, there are 14 (say) xhtml files that make up the book content.
I have listed all 14 of them in the spine to determine the correct play order
I have listed in the TOC.NCX only the 10 or 11 of them I want to appear in the TOC.

There is nothing fancy with subchapters/images etc. I just don't especially need TOC links to a copyright page, a page with a list of other books by the author, things like that. Irrelevant to the TOC, but still belong in the book. I would prefer them not to appear in the TOC. That is my ideal scenario.

I now understand that the Kobo spec requires that the NCX must include every entry from the spine. (is this different from "standard" epub spec? I mean files built like this validate fine.)

Are you suggesting that it is OK to remove items from the spine so that they will not be force-added to the TOC? This seems very counterintuitive. How will they then appear in the right place in the book?

It would be simpler to just use a fully-fleshed out NCX--as the ever-helpful folks at Nook and Kobo aren't going to allow you to do without one--and simply put (wait for Wolfie to start screaming) a toc.html file in, for the desired graphic effect of not displaying everything.

Quote:

Originally Posted by JSWolf

You don't need every XML file to be in the ToC. But as for things like the copyright, list of books, and things like that, yes, they should be in the ToC.

Wolfie, me darlin', you know that that is solely opinion, sweetie. I think he's asking about technical specs, rather than our input on what we think he ought/oughtn't do.

Quote:

Originally Posted by goodmorningjulie

Shimmering - I had this EXACT same situation this week with Nook and Kobo and was banging my head against the wall because the client kept saying there was a ToC problem in the epub. We are skipping the previewer step now, as you recommended, but it is a bit nerve-wreaking to post to a new distributor and hit publish without being able to see a preview on their device. But is there any other way? Any updates on this issue?
Thanks SO MUCH for mentioning that this worked for you!!

We keep all major devices in-house, for this precise purpose. Nooks, iBooks on iPad, Kobos, Kindles of myriad sizes and shapes, etc. Was your client updating the file in any way? We had an experienced publisher who endeavored to make "just 3 little text edits" at Nook this past week and I had to chide her, for even without this issue, the moment you allow NookPress to do anything--replace a cover, fix one typo--ANYTHING--it will corrupt the ePUB, replacing your own CSS with their "revised" version.

Hitch

JSWolf · 04-17-2015, 08:31 AM

Quote:

Originally Posted by Hitch

Wolfie, me darlin', you know that that is solely opinion, sweetie. I think he's asking about technical specs, rather than our input on what we think he ought/oughtn't do.

I don't like when ePub is infected with Kindle specific formatting. An ePub is not Mobi and should be created as one (format wise). It's up to Amazon to make Kindlegen be able to deal with a proper ePub as a source file.

Notjohn · 04-18-2015, 06:34 AM

My epubs are universal, with the single exception that I don't include a cover in the version uploaded to the KDP. However, I don't use any media calls, having learned my lesson with drop-caps when they became available (not long before Amazon changed the line spacing in the KF8 devices, throwing everything off), so I suppose I am basically just uploading a Mobi 7 file with CSS, and not a Kindle-specific file in your definition.

Hitch · 04-18-2015, 03:13 PM

Quote:

Originally Posted by JSWolf

I don't like when ePub is infected with Kindle specific formatting. An ePub is not Mobi and should be created as one (format wise). It's up to Amazon to make Kindlegen be able to deal with a proper ePub as a source file.

Wolfie, m'dear:

What has this to do with someone deciding to omit items from their NCX? The OP, deciding not to include his frontmatter has absolutely nothing to do with Amazon, how they format mobis, etc. Nothing at all. That's all the OP's determination, for his ePUB--not his MOBI.

So...??? Wassup wit' dat, sweetie?

Hitch

dgatwood · 04-18-2015, 05:20 PM

Quote:

Originally Posted by Hitch

We keep all major devices in-house, for this precise purpose. Nooks, iBooks on iPad, Kobos, Kindles of myriad sizes and shapes, etc. Was your client updating the file in any way? We had an experienced publisher who endeavored to make "just 3 little text edits" at Nook this past week and I had to chide her, for even without this issue, the moment you allow NookPress to do anything--replace a cover, fix one typo--ANYTHING--it will corrupt the ePUB, replacing your own CSS with their "revised" version.

This makes me glad Nook Press's editor can't display my EPUB files. I'm not sure what evil magic is in them that breaks it—maybe the SVG pages.

Hitch · 04-18-2015, 08:11 PM

Quote:

Originally Posted by dgatwood

This makes me glad Nook Press's editor can't display my EPUB files. I'm not sure what evil magic is in them that breaks it—maybe the SVG pages.

Well, if I had to guess, that would be it. I doubt that NookPress is set up to deal with SVG. What happens to your books, though, on the B&N Preview pages, if you can't see them in the Preview pre-publication?

I mean...just viewing the ePUB in the Preview mode doesn't change it; the client/publisher has to make an actual change, for the CSS modification to occur.

So: what happens when they go to display your book for their version of "Look Inside?"

HItch

08-17-2014, 05:24 PM	#1
shimmering Member Posts: 15 Karma: 12698 Join Date: May 2014 Location: England Device: none	Uploading epub to Kobo and Nook I wonder whether this could be useful to some. ETA: But I wonder whether the replies could be more useful. I've had a bit of a problem uploading an epub file to nook and kobo. I think it's now solved, in a way that possibly seems obvious in retrospect. The problem was that after uploading, the TOC (by which I mean the non-html and ever-present TOC coded by an ncx file) expanded to include various undesirable entries that were not present in the TOC of the originally uploaded epub file. Oh dear. My epub files are html-coded, command-line-zipped. They include one xhtml file for each of the chapters (all included in the TOC), plus (and herein the source of the issue) various further xhtml files that form part of the book but are not required in the TOC (e.g. things like the cover image, the title page, copyright, etc.). Well all these unincluded xhtml files, uploading to Both nook and kobo, spontaneously and disasterously appeared in an expanded TOC. Their TOC entries were pieces of code. Well the only thing I found that worked to get around this and use the original TOC was to: NOT open the epub file in the previewer that presents itself immediately after uploading. That for both nook and kobo. If I opened the uploaded epub in the dashboard's previewer, then the extra entries appeared and could not be got rid (despite an apparent option to do so in a TOC editing tool for the nook case) of without reuploading the file. So I think (for the moment) that that's a solved issue for me for the moment at least. Although it's a bit of a workaround and has the obvious issue that previewing is made more difficult if using the previewer wrecks the file. But there we are. Hope this helps... Or maybe you already knew. Or am I wrong? Last edited by shimmering; 08-30-2014 at 01:31 PM. Reason: I wonder whether the replies could be more useful

08-22-2014, 04:08 AM	#5
dgatwood Curmudgeon Posts: 629 Karma: 1623086 Join Date: Jan 2012 Device: iPad, iPhone, Nook Simple Touch	If I'm reading that correct, the only way this should cause problems is if either your spine contains things that shouldn't be in there or your TOC is missing things that should be in it. The spine should contain all of the main content, in linear reading order, and nothing else. For example, you might leave out end notes if they're in a separate file, or pages that just contain a larger version of a linked image, or other content that isn't part of the primary reading flow. Otherwise, it should be a complete view of what the book should look like if you were going to print it, in order, with no nesting. However, it is worth noting that the spine contains exactly one entry per physical file, with no access to parts of a multipart file (a chapter with sections, for example). Its purpose is to tell the reader the order in which to glue the files together. The TOC, in turn, provides the ability to structure the contents of the spine in a nested fashion. For example, you might nest chapters inside parts. The spine would contain the part page, followed by the first chapter in the part; the TOC would contain the part page, with all navPoint tag for each chapter in the part nested inside the part's navPoint tag. Additionally, if you have sections within your chapter files (e.g. with named anchors before section headings), you can add these in the NCX as separate navPoint entries using fragment IDs (e.g. foo.xhtml#jumptarget). Caveat: top-level navPoint entries should not have fragment IDs for maximum compatibility. So the TOC should always contain either the exact same entries as the spine or a superset of the entries in the spine (if you're adding links to sections within files), and should never contain a subset of the spine entries. If there are entries in the spine that aren't in the TOC, either the spine is wrong or the TOC is wrong. Last edited by dgatwood; 08-22-2014 at 04:12 AM.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Help Uploading epub to iBooks	Lola25	Apple Devices	3	11-18-2013 01:08 AM
Uploading Photos to Nook Color	rxmom03	Nook Color & Nook Tablet	4	08-29-2012 09:36 PM
Trouble uploading to Kobo?	Whackatagin	Workshop	0	04-28-2012 12:12 PM
ePub error when uploading to iBookstore HELP!	SHADPUB	ePub	1	12-12-2011 10:12 AM
Problems after uploading RSS feeds to Nook	nook77	Recipes	4	03-05-2011 10:42 AM

08-18-2014, 03:32 AM	#2
davidfor Grand Sorcerer Posts: 24,907 Karma: 47303748 Join Date: Jul 2011 Location: Sydney, Australia Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos	I suspect what is happening for the Kobo is related to their "Kobo ePub" format. This is usually know as "kepub" and is what Kobo use to send to the Kobo devices and apps. It is basically just an epub, but they add some spans for their bookmarking system and a couple of other things. From what I can tell, all files within a kepub have to have a ToC entry. When I have constructed a kepub without this, the devices will read the books, but there can be some strange things shown in the ToC and in the page number area of the screen. For kepubs, the devices show the current chapter name plus the current page within the chapter. That display can get interesting if there isn't a one-one relationship between the ToC entries and the files. I'm not sure if that is the cause of what you are seeing or not. I'm not an author, so I haven't tried what you are doing.

08-18-2014, 05:00 AM	#3
shimmering Member Posts: 15 Karma: 12698 Join Date: May 2014 Location: England Device: none	Thanks for that. That was interesting to hear. What you're describing does sound like it could be part of the same thing I am seeing. Maybe the better solution would be for me to go ahead (or go back) and create a longer TOC with a 1:1 TOC entry/xhtml file correlation. That way, even if it does mean that the TOC would include things that I would deem unnecessary, at least I can determine how they appear there rather than have some automated system pluck out pieces of code (it seems to choose the names of the itemrefs from the spine in the content.opf) and put them on show in the TOC.

08-24-2014, 08:31 PM	#6
dgatwood Curmudgeon Posts: 629 Karma: 1623086 Join Date: Jan 2012 Device: iPad, iPhone, Nook Simple Touch	BTW, your spec link is broken (http://[https://...). The correct link is https://github.com/kobolabs/epub-spec

08-29-2014, 06:00 AM	#7
shimmering Member Posts: 15 Karma: 12698 Join Date: May 2014 Location: England Device: none	You correctly describe the scenario that is no doubt behind the issue I am seeing: Indeed, there are 14 (say) xhtml files that make up the book content. I have listed all 14 of them in the spine to determine the correct play order I have listed in the TOC.NCX only the 10 or 11 of them I want to appear in the TOC. There is nothing fancy with subchapters/images etc. I just don't especially need TOC links to a copyright page, a page with a list of other books by the author, things like that. Irrelevant to the TOC, but still belong in the book. I would prefer them not to appear in the TOC. That is my ideal scenario. I now understand that the Kobo spec requires that the NCX must include every entry from the spine. (is this different from "standard" epub spec? I mean files built like this validate fine.) Are you suggesting that it is OK to remove items from the spine so that they will not be force-added to the TOC? This seems very counterintuitive. How will they then appear in the right place in the book?

08-29-2014, 08:53 AM	#8
JSWolf Resident Curmudgeon Posts: 73,866 Karma: 128597114 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	You don't need every XML file to be in the ToC. But as for things like the copyright, list of books, and things like that, yes, they should be in the ToC.

04-16-2015, 04:23 AM	#9
goodmorningjulie Junior Member Posts: 5 Karma: 10 Join Date: Apr 2015 Device: none	Shimmering - I had this EXACT same situation this week with Nook and Kobo and was banging my head against the wall because the client kept saying there was a ToC problem in the epub. We are skipping the previewer step now, as you recommended, but it is a bit nerve-wreaking to post to a new distributor and hit publish without being able to see a preview on their device. But is there any other way? Any updates on this issue? Thanks SO MUCH for mentioning that this worked for you!!

04-18-2015, 06:34 AM	#12
Notjohn mostly an observer Posts: 1,515 Karma: 987654 Join Date: Dec 2012 Device: Kindle	My epubs are universal, with the single exception that I don't include a cover in the version uploaded to the KDP. However, I don't use any media calls, having learned my lesson with drop-caps when they became available (not long before Amazon changed the line spacing in the KF8 devices, throwing everything off), so I suppose I am basically just uploading a Mobi 7 file with CSS, and not a Kindle-specific file in your definition.