Looks ,like you’vhave put a reference to ibooks in the contents file. The validator is complaining about it.
Now,what exactly do I have to delete to make that error go away?
I suppose that ibooks comes from the mac-Version …
Hmm. It didn’t complain about the other types, and it shouldn’t be complaining about this one.
From Apple (https://help.apple.com/itc/booksassetguide/en.lproj/static.html):
Apple Books opens to the first landmark item that contains the epub:type value of “ibooks:reader-start-page”.
Perhaps a validator error?
However, Apple Books can still navigate to this (see the referenced document for its alternate opening preferences), so removing line 71 should work.
It may be from the Mac version, but it’s part of the Apple Books spec. Clearly, something is wrong, either with the validator or with Scrivener (errors should not generate from correct ebook code).
What did you do to generate the ebook? Standard Scrivener epub compile?
I can’t imagine that to be a validator error…
Smashwords flagged it. that’s why I went to look myself
I created the e-book directly with Scrivener, like I used to do with the old Scrivener.
I made two tries with deleting, first only the word “ibook”, then more, but that then was obviously too much. But since I don’t know a thing, I broke the code. Therefore, the question, what exactly I need to eliminate.
Fortunately, this is a preorder and I have still some time before delivering the final file.
Ah, but Smashwords don’t want you to upload epub files. They explicitly tell you to upload a Word file and then let their own software create the various output formats.
Have you read their instructions, in detail?
The entirety of line 71, from
That is, delete this line:
[code]
This is from a test compile of a test project; it had the same error in it. I removed that line from the file, and that error disappeared (epubcheck 4.2).
I think what’s wrong is that this type is not in the standard list. It’s in Apple’s list, and the ebook does not reference that as a prefix list.
Without that line, ibook readers can still recognize the TOC/startpage (because it’s landmarked other ways that ibook readers will recognize).
I don’t see any way to turn off the erroneous code except to delete it, at least for now.
There was a discussion of this last year in the regular forums: [url]Undeclared prefix: 'ibooks'. (ERROR)]
Turns out, deleting that line is the current best way to fix it.
You can omit landmarks, but that activates the “guides” which are deprecated. I’d prefer a little bit finer control, myself, than all or nothing. Another comment for the devs follows.
For the devs (I don’t know where this one is in the queue, or if they know what the issue is):
The issue with this line:
<li><a epub:type="ibooks:reader-start-page" href="body.xhtml">Start of Content</a></li>in an epub is that it requires something like this in content.opf:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:epub="http://www.idpf.org/2007/ops"
epub:prefix="ibooks: http://vocabulary.itunes.apple.com/rdf/ibooks/vocabulary-extensions-1.0">
(This is from https://help.apple.com/itc/booksassetguide/en.lproj/static.html#itc9222f7648)
This is where the ibooks type is declared. Without the correct declaration, the epubcheckers will error on the epub:type=“ibooks…” line. Publishers check epubs for errors, and decline erroneous documents.
The fix for the error in the epubcheck is relatively simple (in concept, anyway): delete the offending ibooks line, or add the declaration. I’m not sure if there are licensing issues in adding the declaration to ebooks not intended for distribution through Apple Books (that’s an Apple question, or a lawyer question).
That was a long time ago that we had no choice.
Besides, it has nothing to do with the fact hat Scrivener did not create a valid file.i StreetLib -wehre you have to have an epub file - rejected it as well.
I did not read their style guide in detail; I translated it into German word by word.
thank you so much. This really helps
No, their website says:
Recommended: Upload a Microsoft Word .doc file, formatted per the instructions in the Smashwords Style Guide . Smashwords will use the Word .doc file to generate the multiple ebook file types listed in Step 7 below.
This error has nothing to do with Smashwords. Scrivener is not generating correct epub code.
That does not contradict that we DO have the choice, which format to upload.
And it has nothing to do with anything.
shaking head
The whole point of the thread is that Smashwords is rejecting the file. So yes, Smashwords’ preferred formats most definitely are relevant, since they provide an alternative way to get your work out there without waiting for a bug fix in a piece of beta software.
Katherine
Smashwords do allow uploading of books in epub format. All of Hague Publishing’s books are routinely uploaded in this manner. Relying on automatic reformatting is risky. If Smashwords have flagged the error then it is of concern.
Missing the point. This is about beta software. There is a defined workaround which is preferred by Smashwords so it seems that trying to get this one minor bug (if it is in fact a bug with Scrivener and not somewhere else) fixed immediately and holding up one’s workflow is counter-productive. Report the bug, use the workaround, wait for the diagnosis and fix. Simple.
Just remember, bugs are features waiting to be developed. Wanted or not.
Aren’t you supposed to file the bug i instead of joining a discussion about a workaround that doesn’t even work with most e-book distributors?
Me personally? Actually no, that’s the Windows developers’ job. But yes, posting in this forum is the way to make them aware of it.
Katherine
What do I know what the tasks of the “support team” are in this forum …
Whoever should have done it, din’t file this bug.
How do you know that?
Probably because there’s no issue number edited in to the title.