ePub formatting wonkiness in latest beta


I’m running Scrivener 2.4.5, build 24052, and am running into a problem with ePub formatting. The ePubs generated during Compile — regardless of the settings — all validate fine, but when loaded into an eReader app of some kind (be it iBooks on my iPad or BookReader on OS X), the formatting is ALL kinds of screwed up. What’s more interesting is that the weird, messed-up formatting only seems to happen once you change the Contents. For instance, if you deselect a file in the Contents pane of compile, you get one version of the ePub, with one set of formatting . . . do it again and you get something entirely different. In either case, most of the time, the formatting doesn’t adhere to what’s specified in the Formatting pane of Compile — not even close. My question is, what’s going on? This will be a hard one to reproduce, for sure, because it seems to depend on a myriad of different factors. Any ideas?

Hmm, yes there must be some other factor involved here because I am not getting any kind of strangeness by changing the “Include in Compile” checkbox (which is tied to the Contents compile option pane) for sections. I set up a simple test document with some gibberish text and then used the “E-book” compile format preset to get some basic formatting. Are you using any of the advance options in the Contents pane, such as front matter, filtering, or changing the compile group as opposed to just compiling the whole draft folder?

It sounds to me as though there may be some other issue though, because although it cannot be guaranteed that everything will appear 100% identical to the Formatting pane on account of differing interpretations of formatting codes between e-book readers, it should still look roughly like what you see here. So perhaps if there is something being requested of the text in the Formatting pane that is causing an overall issue with e-book formatting, it could be exacerbating or even causing the problem.

I’d give the stock “E-Book” preset a whirl and see if things normalise (saving your current settings as a project preset in the meanwhile). If they do, that would indicate that potentially something in the compile settings themselves is causing the problem, rather than in the content of the project. If you find it does work fine with stock settings, if you could attach a copy of your compile settings to a response so we can test them that would help.

Well, I feel really stupid. As it turns out, my eBook reader software (BookReader on OS X) was caching the files, so that it when it “opened” the ePub file from Scrivener, it wasn’t actually opening the latest version; hence, the formatting wonkiness I was telling you about. Basically what happened is that Scrivener was doing its job correctly — the book reads fine on iBooks on my iPad — but the eReader software on the computer wasn’t doing its. Sorry for the false alarm.

However, there is a new wrinkle. When I take my Scrivener-generated ePub file and run it through http://validator.idpf.org, I get this:

WARNING | OPS/toc.ncx | meta@dtb:uid content ‘7851D37C-8084-4B2E-81C0-1F3C2ABC4B9F’ should conform to unique-identifier in content.opf: ‘urn:uuid:7851D37C-8084-4B2E-81C0-1F3C2ABC4B9F’

Which is weird, no? Any possible happy ending to this story? For reference, I’m enclosing my ePub file as well as my compile settings for the project below. Hope we can find an answer for this one!

Archive.zip (456 KB)

Argh, sometimes caching can be such a pain, even though it saves us a lot of time in the long run.

UUID thing: that is a fairly minor warning (as opposed to error), something that at the moment is only of interest to one ePub validator (and of course any tools that use ePubCheck jar, which are none of the major vendors to my knowledge—at least not the newest version where this check was introduced). Most validators do not, and it definitely shouldn’t be causing any e-readers to fail to load the book.

But, if you are like me and do want to fix it and have a clean file, just open the .epub in Sigil and edit the NCX file so that it has “urn:uuid:” in front of the string of numbers you see here (the meta field is “dtb:uid”). This has already been fixed for the next revision of Scrivener (and in fact I think you might even be able to get around it by loading the public beta), I’m not sure about that though because it isn’t in the release notes.

Thanks for the reply! I would like to fix this error — since SmashWords says your book must pass their validator with a 100% clean slate, and I just want to make sure I dot my i’s and cross my t’s properly, y’know? I will do as you suggest, though, and go in and change things with Sigil.

Also — as far as I know, I am indeed running the latest public beta of Scrivener (v. 2.4.5 build 24052, right?). Is there a newer one than that?

Ah, there is not a public version with the fix yet, then (it’s working in the more recent in-house build I’m using). Good to know that SmashWords has updated their copy of ePubCheck internally, though (meaning I should probably write a how-to on fixing this by hand).

…Which he did, and you can find instructions for correcting the issue here.

Thanks for all the information here. I’ve been tearing my hair out (not that I have much) over this problem for a while. Should have come to the forums sooner.
Aren’t forums great? Where would we be? Or should that be fora? Anywat, thanks for the fix and look forward to the next update so we can all forget about this.