Quote:
Originally Posted by MoReader92019
Well, yeah, but if the object code Sigil saves has embedded information that confuses Nook, what can Nook do but slow down, make an if mandated decision to go with a default thumbnail? And if two thumbnail options are there, what does Nook do, a timeout pick and choose? I'll just start from scratch, learn how to do epub right and upload a clean copy of my files that cannot possible have embedded stuff from previous files. I have only tried this with the last several of my files anyway. My last epub used Smashwords with a few flaws that I could have fixed with Sigil, but even these seem to fool NOOK.
|
There's no object code involved. Sigil saves a zip archive that contains xhtml/xml/css/image files. I'm not sure what "embedded information" you're referring to. I don't know the least little bit about how Nooks work, but I DO know Sigil. And there's no embedded anything anywhere (that somebody didn't put there themselves).
You have some crazy long file names that in turn result in crazy-long links, but other than that, there's nothing hiding in that epub anywhere. There's a couple of small html files, a reasonably sized css file and a gigundous cover image that's comprised entirely of text.
Maybe it's not the size, but some of the image metadata. Should be easy enough test. Replace the existing cover-image with a much, much smaller one (or get rid of it even) and see how the epub performs on the device.
5000x5000 ppi to display an image full of text is a bit much. Drop the resolution a little. I know for a fact that some RMSDK-based renderers will barf on images that have a side much longer the 2000 pixels. Your image is 2050x3050 pixels. I don't know how much ram a Nook has available, but this image is occupying way more of it than it needs to.
EDIT: I also notice that image itself is not tagged with the "Cover" property. That's not spec-related so much, but perhaps the Nook relies on that particular bit of OPF metadata?