Error in ePub regarding XML

Really struggling to get an EPUB3 file output from scrivener for upload to Ingram Spark for an eBook! Continues to have some strange “error” that doesn’t seem fixable by the end user - me, and is preventing me from getting my titles on Ingram Spark. Can anyone help me??
Here is the error:
(ERROR)OPS/body54.xhtml: 13,152: value of attribute “I’d” is invalid; must be an XML name without colons.

The error you’ve given provides a file name “body54.xhtml” and a line number (13) as well as a character position (152). So you should be able to look this up in the source file itself and get a better picture of what it is talking about. That should be generally true for most ePub errors.

There are two good ways of going about that:

  1. In the compile overview screen, under the General Options tab on the right hand side, enable the Save source files in a folder with exported ePub file. With that enabled, you will get a folder with a bunch of files in it. The files like “body#.xhtml” will be found within the OPS folder. There will also be a file with instructions for created an updated .epub file from any edits you make to the source here.
  2. Using an ePub editor like Sigil or Calibre’s built-in editor, you can browse the source file contents of an .epub file and even make changes to the book right then and there, fixing any problems you spot.

Lastly, it has been reported that the Optimize for Kindle conversion setting does not pass IngramSpark’s validator. Make sure that is turned off (though it doesn’t look like the kind of errors I’ve seen when it is on).

Moderator Note: moved your post to a new thread, since it has nothing to do with creating PDF files.

(As an aside, there have never been any problems with my files created through Scrivener when uploading to Amazon/Kindle).

Thanks for that info. I have tried the things you suggested (plus the Optimized for Kindle was already NOT checked). This still seems like coding/programming/outside the normal user type of interfacing. I don’t really understand what it is that I am looking for (or how to identify something that is “wrong”). I don’t even understand how to find the “location” or whatever is identified in the error.

I tried just compiling it as a PDF through Scrivener and then “converting” it to an EPUB with Calibre…but when I uploaded this to IngramSpark, it came back with a million errors (instead of the just one error from the original Scrivener EPUB file).

Is there anyone at Scrivener who understands this internal language-world that can help me correct this document? So over my head, and it doesn’t seem like something an end user should be messing with anyway.

I have to disagree. The developer creates the software but the end-user is responsible for its use. It’s sort of implicit in the term “end-user”.

Most errors that appear when people compile for specific publishing platforms have to do with there being something special inside the projects that cause the errors. Many times the problem can be solved by reading and carefully following the instructions on the publishing platform.

Yeah, and to put that another way, I would say the internal design and construction of the ebook is most certainly something and end user can (and sometimes even should) mess with—considering in this case that “end user” means: someone who is handling the role of book designer. That is your book, and as you grow in how proficient you are in understanding how they work, so will your books become richer and more unique in their design and construction.

Scrivener is designed to facilitate that process in fact, with its compile settings being capable of generating HTML structure and customised CSS. Whatever the case, the construction of an ePub file should not be feared, nor considered something “off limits”. An ebook is something you can quite literally write all by yourself with nothing more than a text editor and a zip compression tool (epubs are just zip files).

Philosophical points aside, what I’m mainly getting at here is that given the huge variation in what can be done with Scrivener alone—it is entirely possible to create a compile format that produces a mess of broken syntax—it’s very difficult for us to just look at an error line and tell you what is wrong. If you don’t know enough about HTML yet to read what is wrong, we may be able to help, if you provide snippets from the problem area indicated in the error message.

I understand finding the problem is part of what has yet to be learned, so here is a short how-to on that:

  1. First, it sounds like you have a tool already that can help you with this, Calibre. So go ahead and use that. There is a nice feature about it that you might be able to use without any further configuration: when you compile your .epub file, there is an option at the bottom of the file dialogue to open the book somewhere. Enable that, and then click the drop-down and look for an entry to “Edit Book”. This is a tool provided by Calibre, and it will enable you to go straight to editing without having to first import the .epub file in the Calibre library, edit from there (and presumably later on delete it from the library to keep things clean). But if you don’t see that entry, follow that procedure I just described.
  2. Okay, you should see a large window open up with your ebook ready to edit. This is a live editor—you can make edits to the text, save it, and that will be your .epub. It is editing that file directly.
  3. So now to learn how to understand the error message. The first part of it reads: “OPS/body54.xhtml”. That is a directory and file name. You don’t have to worry about the directory because Calibre Editor makes this a little more friendly. You will be looking for an entry called “body54.xhtml” in the Text section of the sidebar. Double-click on it to edit.
  4. The next part of the error message reads: “13, 152”. That is a line and character reading. It tells you this problem is on line 13. And it will be 152 characters from the left of the line (roughly, these things are sometimes not perfectly accurate). By default you should see line numbers in the text editor, so finding “13” should be very simple. For cases where the error is quite a ways from the start, you’ll find a Search ▸ Go to Line… command.
  5. Calibre doesn’t have a character indicator in the footer bar, so you’ll just have to estimate.

But in this case, feel free to copy and paste that line (and preferable the line above and below it, since as I say these things sometimes aren’t pin-point accurate) into a code block in the forum here. If there is text you’d like to obscure, do so carefully, without changing any of the punctuation marks.

Alternatively, Calibre has a built-in checker. Now there is caveat here in that the last I checked it still isn’t perfectly up to ePub3 specifications, and will print errors that don’t matter. Mostly you will see a bunch of “CSS” errors. But the nice thing about this tool is that you can double-click on the error line to open the problematic file and jump directly to the line in question.

Yeah I wouldn’t recommend ever doing that for anything other than personal use. PDF is, with the possible exception of graphics files that need to be OCR scanned, the worst format to start from when creating an ebook. :slight_smile:

Amber V,

Thank you for your very detailed and compassionate help. I have to disagree with Lunk… People use numerous software programs everyday, all day long, and have no idea about the internal language/coding, or how to make those programs run. I can’t believe I would have to learn coding of HTML in order to publish an ebook.

That said, I followed your instructions and was able to find the line of code (line 13). It appears the character at position 152 is a /. Here is the exact line of code from line 13:

All that is on this page is my author picture (which this line seems to be connected to), and a very simple author bio. I don’t have any idea what is “wrong” here. sigh Grateful for any further advice if you happen to have time. Otherwise, I’m dead in the water.

Jackson E. Graham

Okay, I see the problem: your image name starts with a numeral, and since image names are used to create the internal ID (or anchor point, which links can point directly to) that is a problem since IDs cannot start with numerals.

You should be able to simply rename the image to avoid the error. This was a pretty esoteric problem, I just happened to know that arcane rule off of the top of my head. But now you know!

I myself wouldn’t conflate how software is made, itself, with what we use software to create. For example if I use TextEdit to make an RTF file, I might be capable of reading the internal coding of an RTF file to a degree sufficient enough to find problems in it. But I know very little of how TextEdit itself is put together, and even if I did, that knowledge wouldn’t help me out much in understanding the .rtf file.

I suppose how I would put it is: you may not need to know what an ebook is to publish one (assuming you have a template-driven program that obscures all of that sufficiently), but publishing ebooks sometimes means fixing them when they are broken—and that definitely benefits from knowing what they are.

And on the beneficial side, knowing what they are and how they tick will make it possible for you do things that software doesn’t let you do. For example, say you want drop-caps at the top of every chapter. Scrivener doesn’t have a feature for that, but it has the features that let you make one if you know a little HTML and CSS.

But that’s just my opinion—informed by how many people I see struggling and spending weeks on problems that they probably could have fixed in ten minutes after skimming through HTML for Dummies or something. :slight_smile: It’s actually a pretty simple markup system (calling it “code” is a bit much, though I am aware that has become common parlance), especially once you know a few basics. And CSS is practically plain-English. You can probably guess what this does:

blockquote { font-size: 14pt; margin-left: 20px; }

You needn’t be an expert to figure out how to change your block quotes back down to 12pt to match the body text—and that’s the kind of little stuff that can help you go from hours of wresting with software templates to just… fixing it. :slight_smile:

Amber V: You have solved all of my problems!!! THANK YOU for all the time you invested in me (and for your patience and good humor). I will pick up a copy of the Dummies book for reference. Wishing you a blessed weekend!

Jackson E. Graham