Kindle formatting not surviving upload to KDP

Scrivener Scrivener for macOS
1

This is an incredibly infuriating issue that I also discuss in this thread. I love Scrivener with every ounce of my heart and soul, so it pains me to say that the mobi files generated by Scrivener you may as well just throw in the trash for as useless as they are. One of the main reasons I purchased this software was the ease of compiling ebooks that I could upload to platforms such as KDP, but the mobi/epub files generated by Scrivener DO NOT RETAIN THEIR FORMATTING when uploaded to KDP. I lose all the indentation and any CSS applied somehow gets ignored when looked at on the Kindle app, in Kindle Cloud Reader, and when downloaded from Kindle Store.

In this thread, the one I posted, and in tech support with Literature and Latte they have passed the buck onto Amazon, saying it’s something on their end. But I have to call them out a little bit on that. If that’s the case, why does Calibre seem to work just fine? Taking a Scrivener-genearted mobi or epub into Calibre and saving back out as mobi creates files that work absolutely perfect. The question becomes, what is Calibre doing RIGHT with their mobi files that Scrivener is doing WRONG? They seem to have it figured out just fine…

Also, suggesting that us users should contact Amazon to get this bug fixed is mildly insulting. I went ahead and did it anyway, to no luck. But isn’t that the developer’s job, to figure out why their code is busted?

Again, I LOVE this software, and I REALLY don’t want to seem like an entitled jerk here. But one of the absolutely positively most important features is not only completely broken, but sent me through hell and back in trying to figure out what was going on / diagnosing it / running tests and eventually coming back with a crappy, annoying workaround using other software and a shrug from Literature and Latte that it’s somehow Amazon’s fault. But if they can’t fix the glitch, then they should ABSOLUTELY take responsibility and disclose in the documentation and on their website that this important feature WILL NOT WORK CORRECTLY. That is the ethical thing to do, and may save hundreds of users just like me from having an insanely frustrating experience.

2

Probably because Calibre wrote their own code to generate mobi files and Scrivener compiles to epub, then uses Amazon’s KindleGen tool (a tool developed by and maintained by Amazon) to convert the epub to mobi?

Now, depending on which version of KindleGen you are using, you may have a very old version with quite a few bugs that hasn’t been updated in years. If you just try to download KindleGen directly, you’ll get this version (assuming it’s still available). However, if you remove that version from your system, then download Kindle Previewer, it comes with a newer version of KindleGen. It would be interesting to see if you experience the same problems after doing that (if you haven’t already).

3

Sorry you’re not happy with the results you get, but there seems to be some confusion over the topic at hand. The thread you posted this in was about taking the .mobi file that KindleGen or Kindle Previewer creates, and loading it directly onto one’s iOS device for proofing. This is not the approach recommended by Amazon, and expected formatting can be observed once the proper file type is used on iOS.

What you are describing is a very different and larger problem, and one that we should probably investigate separately; I’ve consequently split your post to a new thread.

Firstly, I would second devinganger’s advice. Make sure Scrivener is up to date, as well as your Amazon conversion tools.

⠂─────── ⟢⟡⟣ ─────── ⠂

If that all checks out, and you’re still having difficulties, then to start with that, it would help to have some clarity on how you’ve got things set up. Your two specific points are that all indents are lost, and that no CSS is used by the Amazon publication tools. This can be very easily verified with a baseline test, which can be facilitated with the attached sample project.

A simple test like this can be useful in determining differences in settings and feature usage. To that end, it uses extremely basic settings so as to make certain the .mobi file passes the basic criteria you’ve highlighted. It has some sample text, two paragraphs of which have been given a custom style. The compile settings themselves are even more basic than default settings, and the CSS panel has been set to only use custom CSS, rather than automatically generating anything from any other settings.

400×535
[size=80]Screenshot of table preview mode in Kindle Previewer 3[/size]

The expected formatting is all in place, given the following CSS:

body * { color: red; } p { text-indent: 40px; margin: 0rem 0rem 0rem 0rem; } p.left-block-indent { text-indent: 0em; margin-left: 40px; } p.right-indent { text-indent: 0em; margin-right: 80px; }

Now of course this is Kindle Previewer, not post-KDP. But I would hope that whatever shows up in Amazon’s publication tool, used to simulate device output, is pretty much if not exactly what you get on the actual devices post-KDP upload.

As for the rest, it seems you’re thinking that Scrivener has an extensive conversion system built into it like Calibre does, to which it can be directly compared. If you want to see what Scrivener itself actually creates, before sending it to Kindle Previewer or KindleGen for the production of a .mobi file, then compile the provided sample project. I’ve enabled the Save source files in a folder with exported Kindle file setting, in the General Options tab, so that you can examine the raw source materials that goes into an ebook. These are the actual files Scrivener creates behind the scenes, in a hidden folder, which it then passes along to Kindle tools—the final result of which is what you get in the folder you selected. The source files are then by default deleted.

So importantly this gives you a step into the process. This is what Scrivener creates, from start to finish. In fact if you open that folder and drag and drop the .opf file into Kindle Previewer, you’ll get an identical .mobi file to the one that also compiled. It’s identical because both were created from the same source files, using the same conversion engine.

But at this point you should have several tools at hand to help decipher where the problem sits. With the source files you can double-check your HTML/CSS directly with a browser or web development tools. With Kindle Previewer you can simulate devices and see how well the conversion of that raw HTML/CSS went. Knowing where things fail can help pinpoint the problem, and if anything isn’t making sense about it still, I’d be happy to help, provided I have something more specific to work with.
simple_css_check.zip (69.2 KB)

4

Thank you for your attention to this. I’ll review your suggestions in detail and report back ASAP.

5

I can compile your sample project just fine, and it looks perfect in a browser with the source files, on Kindle Previewer, and on the Kindle iOS app sent using SendToKindle.

When I compile mine, it looks perfect in a browser with the source files and on Kindle Previewer, but does NOT look ok on the Kindle iOS app sent using SendToKindle (and I know for a fact it doesn’t work when live on the store). It ignores my one line of custom CSS which is img { display: inline; } and all of my indents are stripped out.

I have no idea where to go from here. I am frustrated and confused. Could I send you my project file to take a look at, or the compiled source files or mobi? What would help finally solve this issue that’s been plaguing me for seemingly forever?

6

I could take a look at a small sample (I’d really only need enough text to demonstrate a proper indent and image), or even the whole project; you can send it in a PM to me. Or if you prefer, you can send it to our support address, making sure to mention this thread URL so they know to flag me.

7

Just dropped you a PM. Thank you so so so so much.

8

Sorry for the delay in getting back with you. I’ve looked through the HTML/CSS for any red flags, and the code that Scrivener is producing looks good to me; there are no mistakes in the source like tabs for indents, etc. There are some technical differences between my simple demo and yours, but they are almost to the point that you could call them “cosmetic”. Mine doesn’t use direct formatting and uses a pure cascading approach, where paragraphs are simple

elements and nothing more, whereas yours uses word processing style serialised class names. But the ultimate effect should be pretty much the same in any reasonably well-behaved rendering engine. Whether paragraph indents come from p selectors or p.ps5 shouldn’t really matter.

That’s not to say it doesn’t matter, maybe it does to Amazon, but it shouldn’t.

That said, I came across this article on Vellum’s page, with tips and advice on what to expect, and what not to expect, when side-loading on Amazon software and hardware. They specifically mention that SendToKindle cannot be trusted to work correctly with iOS, and it should only be used for text proofing not layout and formatting. Only Kindle Previewer can display its files correctly, it seems, not Kindle (don’t ask me, I’m just relaying what Amazon themselves say, seems weird to me).

Now as for the image CSS, you stated that this gets ignored, but I see no reason for why that would be when running a test compile. Here is the calculated CSS using Firefox’s inspector:

As you can see, Scrivener’s default block setting is overridden by your custom line, which is what is currently taking effect. I only saw one case where this formatting would be applicable, at the very end of the book where there is a row of social media icons. This looks fine to me in Kindle Previewer. It is true, if I side-load the .mobi file directly to my iPad it renders as a “block” column, but I can’t really tell if that is because the inline CSS isn’t working (if not, then why would the block CSS work, keeping in mind that block image formatting is not a default in any rendering kit I’m aware of?) or because the image size CSS isn’t working, and so they are too large to display in a row. Whatever the case, as noted above, this isn’t expected to work at all anyway.

So as frustrating as it is to hear, I really don’t see what is being done wrong with the HTML here, and what you seem to be saying is: it works in Kindle Previewer, but when using Amazon’s tools to upload or send Amazon’s file format to Amazon reader software and hardware, it breaks. I’m not sure what you expect us to do about that. It’s baffling to me why it breaks, but it’s all a black box once it goes from source files to a binary book format.

I can think of a few constructive things to try however:

  • Instead of uploading .mobi, upload .epub, taking care to set the Optimize for Kindle conversion checkbox in compile settings. While this isn’t the recommended approach for KDP, and was built primarily to facilitate those aggregate services that only accept .epub or .docx files, it might work—it’s worth a try anyway. Maybe also worth trying a regular .epub as well (you may need to set Omit “landmark” guides in the ToC compile settings tab, if Amazon’s readers still display the landmark element as visible text).
  • Alternatively, since my sample seemed to make it through all phases of conversion, try to adopt an approach that is closer to how my sample works:

[*] Set the section layouts that output prose to use default paragraph formatting instead of custom formatting.

  • Ensure the default formatting is how you want it at the top of the CSS pane (it looks okay to me).
  • Disable the Create styles for paragraphs using custom formatting setting at the bottom of the CSS pane.

In my extremely cursory testing with your material, everything looks about the same when I do that, but the underlying HTML/CSS is cleaner, and so perhaps with that there is less to confuse Amazon with.[/*:m]

9

I’ve used this route in the past and it’s worked for me.

10

Amber, thank you for your help. At first glance, it looks like using your CSS code does, in fact, help for the text formatting. Unfortunately, the CSS for inline images doesn’t work, and nothing I do can force the images on the same line. Not the end of the world, but just frustrating that something that appears correct in the source files and in Kindle Previewer doesn’t work on a device or on the KDP platform. So I’ll take one out of two issues being resolved for now. Will report back with any new discoveries or concerns as I go deeper into this.

11

As mentioned before, I cannot really explain that. It is default behaviour for HTML rendering engines to display images on the same “line” (more accurately, as inline elements in a single box, just as letters are little boxes in a bigger box, but we can vaguely think of this in human-friendly terms as being “a line”, even though it wraps (by default!), which is where some confusion may be possible). As I speculated before—test your hypothesis with small images. From what I saw, you are using large high-resolution files that are too big to fit on a single, what we would refer to as a “line”, together in the first place. That is no doubt contaminating your results (which personally, I cannot reproduce with a test of 32 x 32 pixel icons).