ePub adjustments for Mobi/KF8 conversion

[bphil00]

Hi,
I work on print books within inDesign. I'm now taking on the task of creating ebooks. I'm going from InDesign > ePub, then using Kindle Previewer to convert to Mobi/KF8.

It's my understanding that there are some common adjustments that should be made to the ePub before running thru Kindle Previewer. I have not had a lot of luck discovering what these adjustments might be, however.

Do any of you have a list of changes that you always make before converting to Kindle?

If it's actually a really long list of changes that need to be made, and you don't have time to list them all, can you list at least a few of the most important ones?

[dgatwood]

The closest I can come is a list of known issues/bugs/quirks (or two):

1. Start here and read down to where it starts talking about DRM.

2. Start here and read the remainder of that article.

This can involve a pretty long list of changes, depending on your starting point.

[Notjohn]

Originally Posted by bphil00

Do any of you have a list of changes that you always make before converting to Kindle?

Well, I work in the other direction, Amazon being my primary sales outlet. I build my epub first without an included cover and sometimes with links to the Amazon store. I then save that with a different title (bookKDP.epub becomes bookD2D.epub) and add the cover and if necessary alter any Amazon links.

At least with one book, published in 2012, I wound up with two covers, which is why I no longer include one in the Amazon edition. And the links of course are anathema to Amazon's rivals.

Apart from that, I make no changes. I upload the epub to the KDP, download the converted "mobi" file, and preview it on the (downloaded) Kindle Previewer. That has two advantages. One, KDP has a fine little spell checker, and I do occasionally find the odd typo. And two, I look upon all this as akin to Macbeth's three witches with their cauldron: I don't trust Amazon not to make changes in the conversion process, so that's what I want to preview.

Of course I don't use InDesign! I understand it creates its own particular brand of weird html/css.

[dgatwood]

Originally Posted by Notjohn

At least with one book, published in 2012, I wound up with two covers, which is why I no longer include one in the Amazon edition. And the links of course are anathema to Amazon's rivals.

Apple in particular.

Another approach is to start with a standard format like DocBook XML and build XSL files or translation tools to convert to EPUB in different ways, depending on whether you're building a MOBI file or releasing the EPUB. Of course, that requires a fair amount of programming skill and a lot of patience, but the result is highly consistent output for every book. They'll always be in sync if you change the original source content, and if you need to make a change to your markup to work around a bug in one particular reader, you can make the change in the script, and that change will be applied to the entire book without any risk of missing a spot.

[AlanHK]

I just found out the hard way that SVG graphics don't convert to Kindle.

At least, the pages that used them did not appear whether I converted using Calibre or Kindle Preview.

I had habitually used the code Sigil makes for covers to do this; the covers work because Kindle actually ignores the cover HTML and just gets the image to use for its cover.

[Doitsu]

Originally Posted by AlanHK

I just found out the hard way that SVG graphics don't convert to Kindle.

KindleGen doesn't support the SVG wrapper code used by Calibre and Sigil, however, if you mark the cover image in Sigil via Add Semantics > Cover Image, it'll be used by KindleGen (and Calibre).

Actual SVG image files are supported in AZW3 files. For an example, see the attached files.
More information about supported SVG tags and elements can be found in the Kindle Publishing Guidelines.

[Notjohn]

Originally Posted by Doitsu

KindleGen doesn't support the SVG wrapper code used by Calibre and Sigil, however, if you mark the cover image in Sigil via Add Semantics > Cover Image, it'll be used by KindleGen (and Calibre).

So you include a cover in your uploaded Kindle books? I stopped doing this after I found (on at least two occasions) that doing so caused me to have TWO covers in the published book.

(I upload the epub to the KDP and let it convert there. I haven't tried feeding it to KindleGen or Kindle Previewer.)

[Doitsu]

Originally Posted by Notjohn

So you include a cover in your uploaded Kindle books?

ٍNo. I upload the cover to KDP separately, because that's apparently what KDP wants. For the PD books that I uploaded to Mobileread, I created a regular epub cover page with an SVG wrapper and compiled it with KindleGen. (Kindlegen will strip the HTML but keep the image, if it has been properly defined in the metadata section of the .opf file.)

[Notjohn]

Ah, got it! Thanks. I'd never thought of uploading a Kindle version anywhere other than Amazon.

[Hitch]

Originally Posted by Doitsu

ٍNo. I upload the cover to KDP separately, because that's apparently what KDP wants. For the PD books that I uploaded to Mobileread, I created a regular epub cover page with an SVG wrapper and compiled it with KindleGen. (Kindlegen will strip the HTML but keep the image, if it has been properly defined in the metadata section of the .opf file.)

All of our clients get their Mobis with covers. We haven't had an issue in years. The uploaded cover supplants the already-embedded cover in the pre-built mobi file without problems.

FWIW. Obviously, our clients prefer their books that way, as they are giving away review copies, gift copies, etc., and if the book were made sans cover, it wouldn't appear nearly as nicely on the various carousels, etc. ;-)

Hitch

[Notjohn]

It's with epubs that the included cover is problematical. I think it was you who first pointed this out to me. And I once or twice did indeed wind up with a double cover when the epub was converted on the KDP.

As you say, this will never happen with a mobi or html file. Indeed, I once had a very handsome frontispiece suppressed in the KDP conversion because the software naturally assumed that, being first in the file, it was a cover. I then learned to put the "frontispiece" AFTER the title page. (Quasi-frontispiece!)

[Hitch]

Originally Posted by Notjohn

It's with epubs that the included cover is problematical. I think it was you who first pointed this out to me. And I once or twice did indeed wind up with a double cover when the epub was converted on the KDP.

As you say, this will never happen with a mobi or html file. Indeed, I once had a very handsome frontispiece suppressed in the KDP conversion because the software naturally assumed that, being first in the file, it was a cover. I then learned to put the "frontispiece" AFTER the title page. (Quasi-frontispiece!)

There was indeed a time when this happened, but if the ePUB is properly coded, it's stopped occurring for the last few years, AFAIK. It does, BTW, also happen with improperly-made MOBIs, still.

Hitch

[Notjohn]

My last occasion for getting a double cover was February 2013. I'll try it again. It's only the work of a few minutes to add the cover -- Sigil is so great! -- but using the one epub for both purposes would make life easier.

Thanks!

[AThirstyMind]

I don't believe I've ever had a double cover and I've been making ebooks since 2011. But if you're using Sigil to edit your epub for uploading to Kindlegen/KindlePreviewer, it is important to get the Guide items correct (Add Semantics - cover image, title page, TOC, text). And I use a frontispiece often or an image as a title page... never had a problem. Just be sure you Add Semantics - Title Page for that with Sigil.

[AThirstyMind]

I've never gotten a double cover uploading an epub into KindlePreviewer for mobi conversion, but I have stumbled on another issue recently.

CSS errors, particularly those for Center and Flush. The following is a sample of the CSS entry of my normal paragraph style:

.msonormal {
display: block;
font-size: 1em;
text-indent: 0.25in;
margin: 0 0 0.0001pt

Then the styles that have gone off during conversion:

.center {
display: block;
font-size: 1em;
text-align: center;
margin: 0 0 0.0001pt

.flush {
display: block;
font-size: 1em;
text-indent: 0;
margin: 0 0 0.0001pt

plus other styles in the Center and Flush categories with a margin of 0 0 0.0001pt (except for the MsoNormal style)

These styles have a slightly wider bottom margin, perhaps about 1/10th wider than a normal paragraph (single space) I can't figure out what I'm doing wrong. I have a book published in March of 2014 and updated in June of that year... The same styles used but no problems with spacing. The 2nd book was published in October of 2014 and updated in December 2014. The problems are there. And the new book published in June 2015 also has the spacing problems, so something happened between June of 2014 and December of 2014 that I wasn't aware of.

Help!!!