|
"Exactly one 'toc' nav element must be present"
Hi, folks. I'm working on some code for a client which crates EPUB 3 files. The books are working fine in iBooks and Calibre, but now we're trying to upload the file to Google's book store and getting stuck with the lingering error:
"EPUB/toc.xhtml:2, 203: Error while parsing file 'Exactly one 'toc' nav element must be present'." But there is most definitely exactly one 'toc' nav element in the TOC file, and it matches the spec in other ways as well, as far as I can tell. I presume there's something different that I'm just not seeing, even after comparing this TOC file with a few others from other EPUB files, but I still can't see it and I'm about to start flipping tables. Maybe it just needs to be seen with a fresh pair of eyes, so if someone could have a quick look at this and see if they can spot something wrong, I'd greatly appreciate it. It's quite long, but I presume the error lies somewhere near the beginning. (The code below has been run through "xmllint --format" to make it more readable; the "real" file is a bit messier. But that shouldn't make a difference, right?) Code:
<?xml version="1.0"?> |
Most likely the properties="nav" attribute is missing in the <manifest> section of the .opf file.
Double-check the entry for toc.xhtml and add it if it's missing. |
Quote:
Thanks for the suggestion. Unfortunately, that doesn't seem to be the problem here. Here's the line for the TOC file in the manifest. Code:
<item id="toc" href="toc.xhtml" media-type="application/xhtml+xml" properties="nav"/> |
Quote:
For example: Quote:
Quote:
If you don't get any error messages, there might be a problem with the Google validator. |
Doitsu:
Thanks again for your reply, but again, this is not an issue with the manifest. (Though, as far as I can tell, it's not an issue with the actual TOC, either…) That IDPF validator is also complaining about "Exactly one 'toc' nav element must be present." It provides the line and character position of… the start of the nav element. Argh. Starting to wonder if it's parsing the TOC file twice for some reason… |
Quote:
Code:
<nav xmlns:epub="epub" epub:type="toc" id="toc"> |
Holy crap. I didn't think that could possibly be the problem, and that bit was being added by my XML library anyway so I assumed it was correct…*but I tried it anyway using some simple string replacement on the serialized XML, and… it works. That's insane, but it works.
Thank you! |
Quote:
Technically, the validator looks for "{http://www.idpf.org/2007/ops}type" attribute, but your XML has "{epub}type" instead. |
I know this thread is 3 years old. But it's one of the very few hits anywhere for this epubcheck error "Exactly one 'toc' nav element must be present"
So I thought I'd add this anecdote. The error was indicated at the end of the "<body>" line of the nav file. Eventually I worked out the problem was the epub namespace, but in the html line at the top, which was: <html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2011/epub" lang="en" xml:lang="en"> Changing this to <html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" lang="en" xml:lang="en"> and all was good. I previously tried rebuilding the nav file, by using Sigil's "Edit TOC" and "Generate TOC" functions. While these made new file, they preserved the original headers. That's usually a good thing, if like me you paste in CSS styles to make the nav look nice and use it as the visible Contents page. But doesn't fix any errors in the header. Sigil won't let you delete the nav and make a completely new one. But if you open the epub as a zip and delete the nav file Sigil will create a new clean one from scratch on opening (interestingly, without any message that it is doing so). So that might be easier than trying to work out exactly where the syntax is wrong in the old one and quicker than extracting all the HTML, etc and importing all to a new epub. |
| All times are GMT -4. The time now is 08:01 PM. |
Powered by: vBulletin
Copyright ©2000 - 3.8.5, Jelsoft Enterprises Ltd.
MobileRead.com is a privately owned, operated and funded community.