Pile On for Look Inside

Interesting blog. The author is so enthusiastic about Vellum that it makes me wonder what kind of business relationship she has with them. But $200 seems like a lot to pay for a tool like that. And I don’t like the deception on the Vellum site, either. It’s free. To download, that is. If you want to actually USE is, well that’s a different story.

As has been pointed out multiple times in this thread, the .mobi file generated by Scrivener (via KindleGen, an Amazon-supplied tool) works fine on Kindle readers and in the Kindle application. Scrivener is providing exactly the capability that it claims to provide.

The issue is not with the .mobi file per se, but with the Amazon web site’s Look Inside feature’s interpretation of it. Which appears to be different depending on which Amazon-supplied tool is used to create it. In fact, as stated up-thread, there have been cases where the Look Inside preview for a book uploaded years ago stopped working, without any intervention by Scrivener or the author.


Post a question here, or to our support address. L&L staff person or helpful forum member asks, “have you tried .epub format?”

You do, it works, you go on with your life.


“The issue is not with the .mobi file per se, but with the Amazon web site’s Look Inside feature’s interpretation of it.”

Is that really the case? Amazon evidently doesn’t think so. They think that Scrivener produces dirty HTML in their mobi files, which is why Look Inside doesn’t work well with that file format. So, how is this dispute going to get resolved? Or will it ever?

They are mistaken. In order to create a .mobi file, Scrivener hands the .epub file it generates directly to Amazon’s KindleGen tool. This is the exact same .epub file that Amazon’s other tools handle correctly. (Hence our insistence that the problem lies on the Amazon side of things.)

How is this going to get resolved? Well, a good start would be for Amazon to determine why different instances of its own tools give different results from the same source file.


OK, I can certainly agree with all that.

But I’ll just go back to my previous point, which at this point is essentially rhetorical… If what you say is true, and I have no doubt that it is, it sounds to me as if you’re waiting for Amazon to get their act in gear and fix the problem, instead of proactively working with them to get it fixed. If this were my product, and there was a problem that kept a group of users from being able to use it because a third party product doesn’t work, I’d get out in front of things and make sure that the other vendor got their product fixed. If you don’t do that, then you’re pretty much saying that you’re OK with losing some of your customers to the Vellums of the world.

No reply is needed. I have the solution to the problem I wrote about, so I’m happy with things. Thanks.

We have always encouraged users to adopt whichever tools meet their needs most effectively, recognizing that Scrivener cannot – and does not attempt to – solve all problems for all people. We’ve done okay with that approach so far.


Scrivener compiles to .mobi, and that works. It doesn’t claim to compile to Look Inside.

Whether the .mobi files Amazon culls for Look Inside work or not is down to Amazon and the culling process it uses. If Amazon corrupts the .mobi files, it should fix them.

If Amazon refuses to rectify the problems it makes, and given that most (?) compiled .mobi files work okay for Look Inside, perhaps a user setting (font, typographic element, image, etc) could be be changed to stop Amazon’s converter corrupting some files.

Appreciate the OP’s frustration, but think the problem rests with what Amazon does when converting for Look Inside.

As an addendum, early poster J. Philip Horne to Joanna Penn’s blog cited above has provided the following suggestion as a cure for the Look Inside issues:

“[In Scrivener] under Compile -> Transformations, check both “Remove Highlighting” and “Remove text color”. That should do it.
It may be that only one of those two is needed… once I got it working, I stopped experimenting.”

I haven’t tested this. YMMV.

Not true. Smashwords distributes to Amazon only by author’s request and only if the book in question has earned at least $2000 USD https://www.smashwords.com/distribution#amazon. These are very few. For the most part, Smashwords .mobi files are sideloaded by customers onto their Kindles.

OTOH, you can’t build your own .mobi for Smashwords; they build it for you from the .doc file you submit to Smashwords so Smashwords, really, is not germane to this discussion.

I just ran into this problem on my very first publication to Kindle – lucky me! :smiley: I’m delighted to find a few possible workarounds in the threads on this subject. I’m sure that Lit&Lat will update their documentation with these suggestions if the problem persists very long.

I’ll also observe that the KindleGen plugin has not been updated for at least THREE years (I had a manuscript I was going to publish in 2013–but chickened out–and so installed it then. I re-downloaded last week; it’s the same plugin.) So it’s neither impossible nor surprising that the Amazon tools have fallen out of sync with each other.

You seriously over-estimate the amount of attention Amazon will give to third-party software vendors pointing out problems in their toolchain. It’s not like L&L have a special business relationship with Amazon that gives them a direct pipeline in to the development side of the house (in one of your earlier posts you called it a partnership, which in the business worlds has specific implications that do not appear to apply here). In fact, they probably have less pull – because it is Amazon’s customers (the people uploading book files for sale) that Amazon is going to listen to (and that level of attentiveness varies wildly by all accounts).

The most efficient way to get Amazon to fix the problem is for every author who is affected to open up a customer service case with Amazon and work with them to get it fixed.

Just an FYI:
I am have the same issue with books that are several years old. These books’ “Look Inside” was properly formatted for years, but now their formatting appears completely out of whack. I used the mobi/kindlegen 2.9 in the original conversion. Now it seems that kindlegen 2.9 no longer formats correctly as a repair. After several hours of fiddling and reformatting my Scrivener docs, I was able to get two of them to look acceptable in “Look Inside”. One book stubbornly continues to look badly in “Look Inside”. In all proofing software such as Calibre, Kindle app, and the upload proofing tool, all my books look exactly how I want them to appear. Amazon’s coders must have changed their upload conversion process. Curse you coders, curse you…

I’m still having issues with Look Inside and it’s hit and miss for my back catalogue. I’m launching a book tomorrow while still waiting for the Look Inside to update - at the moment it’s showing all the text centred. I’ve had to put a note in the blurb to warn that the formatting isn’t representative of the book itself. Very disappointed and am considering other options for future releases as I can do without this extra stress.