08-17-2014, 05:24 PM | #1 |
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-18-2014, 03:32 AM | #2 |
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 |
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-18-2014, 08:03 AM | #4 | |
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 just remembered a document about the Kobo epub specs. The ToC section has the following:
Quote:
Last edited by davidfor; 08-24-2014 at 10:47 PM. Reason: Fixed link |
|
08-22-2014, 04:08 AM | #5 |
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. |
08-24-2014, 08:31 PM | #6 |
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 |
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 |
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 |
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-17-2015, 01:13 AM | #10 | |||
Bookmaker & Cat Slave
Posts: 11,460
Karma: 158448243
Join Date: Apr 2010
Location: Phoenix, AZ
Device: K2, iPad, KFire, PPW, Voyage, NookColor. 2 Droid, Oasis, Boox Note2
|
Quote:
Quote:
Quote:
Hitch |
|||
04-17-2015, 08:31 AM | #11 |
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
|
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.
|
04-18-2015, 06:34 AM | #12 |
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.
|
04-18-2015, 03:13 PM | #13 | |
Bookmaker & Cat Slave
Posts: 11,460
Karma: 158448243
Join Date: Apr 2010
Location: Phoenix, AZ
Device: K2, iPad, KFire, PPW, Voyage, NookColor. 2 Droid, Oasis, Boox Note2
|
Quote:
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 |
|
04-18-2015, 05:20 PM | #14 | |
Curmudgeon
Posts: 629
Karma: 1623086
Join Date: Jan 2012
Device: iPad, iPhone, Nook Simple Touch
|
Quote:
|
|
04-18-2015, 08:11 PM | #15 | |
Bookmaker & Cat Slave
Posts: 11,460
Karma: 158448243
Join Date: Apr 2010
Location: Phoenix, AZ
Device: K2, iPad, KFire, PPW, Voyage, NookColor. 2 Droid, Oasis, Boox Note2
|
Quote:
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 |
|
Thread Tools | Search this Thread |
|
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 |