Converting ePub to Kindle format for Amazon

[eschwartz]

There is a way -- with calibre. It just won't be accepted at Amazon.

Which makes sense, since it wouldn't work on older devices, including the non-upgraded Kindle Keyboards -- and Amazon wants to make sure the book can be read on ANY of their devices.

It sounds like you are concerned about the cost for delivering the larger filesize. I don't claim to know anything about it, but I'd assume Amazon only charged delivery for the stripped version that they actually send, not the size of the dual-MOBI their tools create.

[Doitsu]

Originally Posted by AlexBell

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.

For testing purposes, you can use Kindleunpack to split the mobi file into azw3/KF8 and standard mobi files. However, AFAIK, KDP won't accept AZW3 file uploads.

BTW, if you generate a mobi file with Kindle Previewer you can click Compilation Details to display the kindlegen log. At the end, it'll indicate the size of the standard mobi and KF8 components.

For example:

Info(prcgen):I15000: Approximate Standard Mobi Deliverable file size: 0000534KB
Info(prcgen):I15001: Approximate KF8 Deliverable file size: 0000579KB

(The same information is also being displayed if you use Kindlegen directly.)

Originally Posted by eschwartz

It sounds like you are concerned about the cost for delivering the larger filesize. I don't claim to know anything about it, but I'd assume Amazon only charged delivery for the stripped version that they actually send, not the size of the dual-MOBI their tools create.

That is correct, Amazon will only charge delivery for the actual file size of the file that the buyer downloads.

[Hitch]

Originally Posted by Doitsu

For testing purposes, you can use Kindleunpack to split the mobi file into azw3/KF8 and standard mobi files. However, AFAIK, KDP won't accept AZW3 file uploads.

BTW, if you generate a mobi file with Kindle Previewer you can click Compilation Details to display the kindlegen log. At the end, it'll indicate the size of the standard mobi and KF8 components.

For example:

Info(prcgen):I15000: Approximate Standard Mobi Deliverable file size: 0000534KB
Info(prcgen):I15001: Approximate KF8 Deliverable file size: 0000579KB

(The same information is also being displayed if you use Kindlegen directly.)



That is correct, Amazon will only charge delivery for the actual file size of the file that the buyer downloads.

Just upload the mobi at your own Amazon test account. Put in the bare minimum to get through to the pricing page. On the 2nd page, beneath the pricing grid, they'll tell you the deliverable file size for which your client will be charged.

There's also 2 other alternatives: 1) make a .prc file--KF7 only--and that will solve part of your issue, (rename it to MOBI), and 2) tell your client to use the 35% royalty option (no delivery fee). Although frankly, 8MB is a fairly small file, even were that the final deliverable file size.

Hitch

[SBT]

@Hitch: Thanks for putting me straight on the issue of kindle covers.

Originally Posted by Hitch

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

I was imprecise. @media amzn-kf8/amzn-mobi is handled by the previewer. Any kind of device query is ignored, e.g. @media amzn-kf8 and (device-height:800px). It is handled correctly by (at least some) physical devices. Or is there some syntax mistake here?
BTW, is there any other way to distinguish between e-ink and Fire devices than querying device resolution?

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.

You are probably right about the reliability of the previewer; on second thoughts, apparent differences between the previewer and the device are probably due to different default font size and line spacing. But it's bad enough that the previewer cannot replicate that.

I've found slight differences in the interpretation of relative positioning for DX and HDX (and very big differences with positioning for e-ink). I would be very grateful for any heads-up about any other unpleasant surprises I might expect.

[Sigh]. The big selling point for a closed, proprietary format is that it is supposed to ensure a consistent, uniform user experience. [Mirthless chuckle]

-------EDIT-------
Gah. I meant subtle differerences between HD and HDX, not DX and HDX. Sorry. But I challenge anyone to try to comprehend KF8 without ending up with an addled mind...

[JSWolf]

Is there any way to get a KF8 eBook to open at the cover?

[SBT]

Originally Posted by JSWolf

Is there any way to get a KF8 eBook to open at the cover?

Doesn't seem doable without breaking Hitch' dictum about avoiding cover.html files. I had a go at

<reference href="Images/cover.jpg" title="Text" type="text"/>

in the guide section, but that made the previewer, not unexpectedly, a bit grumpy.

[SBT]

Update:
I cannot get the previewer to accept the @media [whatever] {} syntax inside a css context, only on devices. The previewer accepts <style ... media="amzn-kf8 and whatever"> though.
The previewer recognizes "amzn-kf8 and (width:758px)" as applying to the paperwhite, but not "(device-width:758px)". According to this blog, device-width etc will refer to the computer screen the previewer is run on.
I have not succeeded in finding a width value for the previewer fire emulation mode.