Converting ePub to Kindle format for Amazon

[AlexBell]

Pardon me if I expose my ignorance yet again.

I do all my ebook design in ePub, and use calibre to convert ePub to mobi with the 'both' setting so that the resultant mobi file contains both mobi and azw3 versions. This seems to be quite acceptable to Amazon (or maybe they don't notice) since several ebooks I do for a small UK publisher have been accepted and sold by Amazon.

But the ebook I am designing now is over 6Mb as an ePub and there is more to be added. The 'mobi' file produced by calibre is over 8Mb. And the ebook has many complex parts which won't work on an old Kindle.

I could use calibre to convert from ePub to azw3, which produces a much smaller file. The azw3 ebook works on my upgraded Kindle Keyboard.

But will Amazon accept this format? If not, what's the best way of converting ePub to a format which Amazon will accept? I really don't want to have to learn how to produce complex mobi ebooks from scratch; I have enough trouble producing ePubs.

[eschwartz]

Amazon will only accept kindlegen output for MOBI/AZW3 (actually they accept old MOBI as well, for backwards compatibility I believe.)

You can also send them your finished EPUB.

[eschwartz]

How you build the EPUB has nothing to do with the coding you used, though. If it displays well with one, it is because of your code and will do so through the other ways as well.

[Doitsu]

According to Amazon, you can upload manuscript files up to 650MB. However, since Amazon will charge delivery costs ($0.15/MB), if the publisher chooses the 70% royalty option, you may want to keep the file size as small as possible or break up the book into several parts.

Even though many KDP authors/publishers had Calibre generated mobi files accepted by KDP, you may want to use Kindle Previewer/Kindlegen to be on the safe side.

[AlexBell]

Thanks to you both

@eschwartz: It looks as though Amazon hasn't noticed that the dozen or so ebooks I've done for this publisher were produced with calibre. Please don't tell them.
And there are things that azw3 files can do - like text flowing around an image - that old mobi can't do.

@Doitsu: So far as I can tell the process of using Kindlegen to make a mobi file is quite different from the process used to make an ePub file - so far as I know the HTML has to be one big HTML file for Kindlegen, but it is best practice to have one HTML file per chapter for ePub. The ebook I'm working on has around forty chapters or sections. It is this doing things differently that I want to avoid. I'd much rather do the ePub as usual then zap it with something to produce the azw3 level mobi.

[eschwartz]

Are you sending them .azw3 files, or .mobi? I have heard people successfully send them .mobi, but not that they successfully send .azw3

Kindlegen accepts three different types of input:

1. HTML
2. OPF (manifest containing references to all elements of the book)
3. EPUB (yeah, that kind )

So you could just convert the EPUB using Kindlegen instead of calibre.

The advantage is that it will contain dual MOBI/KF8 content, which gives a MOBI fallback for older devices but still lets new devices see AZW3.

[Doitsu]

Originally Posted by AlexBell

@Doitsu: So far as I can tell the process of using Kindlegen to make a mobi file is quite different from the process used to make an ePub file - so far as I know the HTML has to be one big HTML file for Kindlegen, but it is best practice to have one HTML file per chapter for ePub. The ebook I'm working on has around forty chapters or sections. It is this doing things differently that I want to avoid. I'd much rather do the ePub as usual then zap it with something to produce the azw3 level mobi.

Kindlegen can process unmodified epubs, and epubs that pass epubcheck will usually compile without errors. I.e. you don't have to change the structure of your epub at all, unless you've defined dropcaps, which need to be slighly adjusted for Kindle books.
However, if you use Kindlegen, you'll also need to define the beginning of the book (AKA SRL=Start Reading Location), the HTML TOC and the cover image or the title page with guide items. In Sigil, you'll need to manually define these items with Add Semantics > Text/Table Of Contents/Cover or Cover Image. (Calibre does this automatically.)

BTW, as you probably know, KindleGen will automatically generate hybrid .mobi files that contains both old and new formats. You can define fallbacks for the older format using media queries. You can for example replace dropcaps with large bold letters. For more information about this, see the Kindle Publishing Guidelines. However, these fallbacks are not required because Kindlegen will ignore unsupported elements by default.

[SBT]

To get a nice kindle ebook with a proper TOC and front page, have the following three elements in the <guide> section of the opf file:

<reference href="Text/Chapter-00001.html" title="Cover Page" type="cover"/>
<reference href="toc.html" title="Content" type="toc"/>
<reference href="Text/Section0004.html" title="Main Text" type="text"/>

To get the thumbnail cover to show properly, you apparently have to have in the metadata section:

<meta name="cover" content="cover-image.jpg"/>

My first attempt to make a nice-looking KF8 book is here. If I remember correctly, the files are identical for the epub and mobi versions, and I use @media tags to handle the differences between epub and mobi, and the differences between kf8 eink and kf8 fire (don't get me started on that issue...)
I prefer using

kgen content.opf

, but that's probably just because of a superstitious wish to operate as close to the source files as possible.

P.S. Don't trust the Kindle previewer too much. Though pretty good at recreating the device outputs, it doesn't recognize @media tags, and it does not permit the user to change line spacing and margins, changing which can have dramatic consequences for the more daring CSS expressions.

P.P.S: And remember: KF8 does not support page-break-inside:avoid, has a broken interpretation of relative widths, a broken implementation of float, no way of overriding user-set line-spacing. And in addition to different rendering for e-ink and Fire, there are also some subtle differences between Fire DX and Fire HDX.

[Doitsu]

Originally Posted by SBT

If I remember correctly, the files are identical for the epub and mobi versions [...]

I had a look at your Kindle KF8/AZW3 book and it looks great. However, the corresponding .ePub book that you uploaded to MR doesn't seem to contain Kindle media queries. Can you post the source files that you used for the Kindle book in this thread? (Since the file is rather large, an excerpt that demonstrates the specific Kindle media queries that you used will do.)

Originally Posted by SBT

[...]I use @media tags to handle the differences between epub and mobi, and the differences between kf8 eink and kf8 fire (don't get me started on that issue...)

What differences between the rendering engines of eInk Kindles and Kindle Fires required the use of media queries?

[SBT]

@Doitsu: Thanks for the compliment
My memory was slightly faulty; I had to use a different css file for the epub, as ADE utterly ignores a css file which includes @media tags. However, the kindle css file is still included in the epub file as OEBPS/Styles/book-kindle.css (along with a lot of cruft-files I've forgotten to clear out.)

The @media tags is used to deal with both the different aspect ratio and the different reference pixels on Kindle e-inks and Fires.

P.S. Did I mention that full-height floating images can cause lines of text to disappear? I had to add a kludge where I reduced the height of the image to a mite less than 100% and add a narrow white full-width image at the bottom.

[Doitsu]

Originally Posted by SBT

However, the kindle css file is still included in the epub file as OEBPS/Styles/book-kindle.css (along with a lot of cruft-files I've forgotten to clear out.)

Unfortunately, the epub version of "Håkon Håkonsen" that you've uploaded here, only contains two stylesheets: titlepage.css and book.css. Could you please upload book-kindle.css as well?

Originally Posted by SBT

The @media tags is used to deal with both the different aspect ratio and the different reference pixels on Kindle e-inks and Fires.

I remember seeing ebook designers mention issues with reference pixels, but unfortunately it's all Greek to me. Could you please provide a short summary of the differences between the displays of eInk Kindles and Kindle Fires insofar as they're relevant for ebook design?

[SBT]

Originally Posted by Doitsu

Unfortunately, the epub version of "Håkon Håkonsen" that you've uploaded here, only contains two stylesheets: titlepage.css and book.css. Could you please upload book-kindle.css as well?

Curiouser and curiouser... I downloaded it once more, and yet again my copy includes 6 different css files. No matter, I attach the kindle css file.

I remember seeing ebook designers mention issues with reference pixels, but unfortunately it's all Greek to me. Could you please provide a short summary of the differences between the displays of eInk Kindles and Kindle Fires insofar as they're relevant for ebook design?

I'll do better, and point you to this thread. DaleDe's reply was very enlightening; check out the links in his reply

I had no idea the shortcomings of KF8 were so many and so severe. I thought it was meant to be an improvement on ePub2, but that's definitely not the case.

[Doitsu]

Originally Posted by SBT

Curiouser and curiouser... I downloaded it once more, and yet again my copy includes 6 different css files. No matter, I attach the kindle css file.

The epub does indeed contain the additional stylesheets. However, since they're unmanifested, Sigil doesn't display them (and epubcheck will complain about them).

Originally Posted by SBT

I'll do better, and point you to this thread. DaleDe's reply was very enlightening; check out the links in his reply.

Thanks for the link to the reference pixel topic.

[Hitch]

Originally Posted by SBT

To get a nice kindle ebook with a proper TOC and front page, have the following three elements in the <guide> section of the opf file:

<reference href="Text/Chapter-00001.html" title="Cover Page" type="cover"/>
<reference href="toc.html" title="Content" type="toc"/>
<reference href="Text/Section0004.html" title="Main Text" type="text"/>

To get the thumbnail cover to show properly, you apparently have to have in the metadata section:

<meta name="cover" content="cover-image.jpg"/>

Please don't put a cover.html file in a MOBI. If you do that, your clients will end up--possibly--with the dreaded "double-cover" if they upload at Amazon. A Kindle book should be built, from an ePUB, (or HTML files, or, or, or) sans a cover.html file, but rather with the cover file identified through the metadata in the OPF, strictly as the image. The KG process will build the book and correctly place the cover, with the guide items intact.

My first attempt to make a nice-looking KF8 book is here. If I remember correctly, the files are identical for the epub and mobi versions, and I use @media tags to handle the differences between epub and mobi, and the differences between kf8 eink and kf8 fire (don't get me started on that issue...)
I prefer using

kgen content.opf

, but that's probably just because of a superstitious wish to operate as close to the source files as possible.

P.S. Don't trust the Kindle previewer too much. Though pretty good at recreating the device outputs, it doesn't recognize @media tags, and it does not permit the user to change line spacing and margins, changing which can have dramatic consequences for the more daring CSS expressions.

P.P.S: And remember: KF8 does not support page-break-inside:avoid, has a broken interpretation of relative widths, a broken implementation of float, no way of overriding user-set line-spacing. And in addition to different rendering for e-ink and Fire, there are also some subtle differences between Fire DX and Fire HDX.

Neither Kindlegen nor Previewer ignore media-queries. What media-queries are you trying to use that you think are being ignored by Previewer?

Users can't set line-spacing in KF8 except as allowed by some, not all devices. That's why it can't override it. There are some very NOT subtle differences between HDX and DX and the Fire. However, I have yet to find real differences between the Previewer and devices, other than the font limitations imposed by Previewer for the Fire.

@Alex:

When you say, "AZW3," you mean, KF8. If your files are being accepted at Amazon, it means that you are not using any of the KF8 capabilities, more or less. If you were using the KF8-type coding, then you'd be running into issues at Amazon. You cannot upload an AZW3 file at the KDP. You must upload a MOBI, or one of the other accepted formats.

Also, there is no reason on god's green earth to make a MOBI file out of one big HTML file, versus doing the same thing that you do for ePUB. We use our ePUB structure, in toto, for building MOBI files. For the same reasons, essentially, although we don't have the file-size limit in MOBI that we can run into in ePUB.

To make a file "work," that has varied bits--things that need to work one way for KF8, and another for e-ink--you're going to need to embrace media-queries, which are quite limited. It's a bit of an artform in and of itself, really--trying to get two very different-appearing results from what is a single source file (pre-KP/KG). If you're at that point, then Calibre isn't going to work for you any longer, most likely. I'm sorry, but you'll need to learn how to use media-queries in your CSS in order to get those things to function correctly across devices.

Hitch

[AlexBell]

Originally Posted by Doitsu

Kindlegen can process unmodified epubs, and epubs that pass epubcheck will usually compile without errors. I.e. you don't have to change the structure of your epub at all, unless you've defined dropcaps, which need to be slighly adjusted for Kindle books.
However, if you use Kindlegen, you'll also need to define the beginning of the book (AKA SRL=Start Reading Location), the HTML TOC and the cover image or the title page with guide items. In Sigil, you'll need to manually define these items with Add Semantics > Text/Table Of Contents/Cover or Cover Image. (Calibre does this automatically.)

BTW, as you probably know, KindleGen will automatically generate hybrid .mobi files that contains both old and new formats. You can define fallbacks for the older format using media queries. You can for example replace dropcaps with large bold letters. For more information about this, see the Kindle Publishing Guidelines. However, these fallbacks are not required because Kindlegen will ignore unsupported elements by default.

Thanks, that's helpful. But my main reason for starting this thread is that the ePub file is already 6Mb, and the calibre generated hybrid file is 8Mb. I'd like to know if there is a way to convert the ePub file into azw3 (or KF8 or whatever it's called) without the old mobi format.

But I think I need to do more research to get a better idea what I'm asking.